1、RDD即弹性分布式数据集，通过RDD可以执行各种算子实现数据处理和计算。比如用Spark做统计词频，即拿到一串文字进行WordCount，可以把这个文字数据load到RDD之后，调用map、reducebyKey 算子，最后执行count动作触发真正的计算。
2、宽依赖和窄依赖。工厂里面有很多流水线，一款产品上游有一个人操作，下游有人进行第二个操作，窄依赖和这个很类似，下游依赖上游。而所谓宽依赖类似于有多条流水线，A流水线的一个操作是需要依赖一条流水线B，才可以继续执行，要求两条流水线之间要做材料运输，做协调，但效率低。
从上图可以看到，如果B只依赖A则是一种窄依赖。像图中这种reduceByKey的操作，就是刚刚举例的宽依赖，类似于多条流水线之间某一些操作相互依赖，如：F对E、B的依赖。宽依赖最大的问题是会导致洗牌过程。
Spark Streaming介绍
流式计算，即数据生成后，实时对数据进行处理。Spark 是一个批处理框架，那它如何实现流式处理？Spark 是把数据裁成一段一段的处理,即一个数据流离散化成许多个连续批次，然后Spark对每个批次进行处理。
个推为什么选择Spark？
1、Spark 比较适合迭代计算，解决我们团队在之前使用hadoop mapreduce迭代数据计算这一块的瓶颈。
2、Spark是一个技术栈，但可以做很多类型的数据处理：批处理，SQL，流式处理以及ML等，基本满足我们团队当时的诉求。
3、它的API抽象层次非常高，通过使用map、reduce、groupby等多种算子可快速实现数据处理，极大降低开发成本，并且灵活。另外Spark框架对于多语言支持也是非常好，很多负责数据挖掘算法同学对于python 熟悉，而工程开发的同学熟悉java， 多语言支持可以把开发和分析的同学快速地引入过来。
4、在2014年的时候，我们用hadoop Yarn，而Spark可以在Yarn部署起来，使用Spark大大降低了切换成本，并且可以把之前的hadoop资源利用起来。
5、Spark在社区很火，找资料非常方便。
个推数据处理架构
上图是一个典型的lambda架构。主要分三层。上面蓝色的框，是做离线批量处理，下面一层是实时数据处理这一块，中间这一层是对于结果数据做一些存储和检索。
有两种方式导入数据到HDFS，一部分数据从业务平台日志收集写入到 Kafka，然后直接Linkedin Camus（我们做过扩展） 准实时地传输到 HDFS，另外部分数通过运维那边的脚本定时导入到 HDFS 上。
离线处理部分我们还是使用两个方式（Hadoop MR 和 Spark）。原有的hadoop MR没有放弃掉， 因为原来很多的工程已经是用MR做的了，非常稳定，没有必要推倒重来，只有部分迭代任务使用Spark 重新实现。另外Hive是直接可以跟Spark做结合，Spark Sql中就可以使用Hive的命令。
个推Spark集群的部署状况
个推最开始用Spark是1.3.1版本，用的是刀片服务器,就是刀框里面可以塞 16 个刀片服务器，单个内存大小192G， CPU 核数是24 核的。在Spark官方也推荐用万兆网卡，大内存设备。我们权衡了需求和成本后，选择了就用刀片机器来搭建 Spark集群。刀框有个好处就是通过背板把刀片机器连接起来，传输速度快，相对成本小。部署模式上采用的是 Spark on Yarn，实现资源复用。
Spark 在个推业务上的具体使用现状
1、个推做用户画像、模型迭代以及一些推荐的时候直接用了MLLib，MLLib集成了很多算法，非常方便。
2、个推有一个BI工具箱，让一些运营人员提取数据，我们是用Spark SQL+Parquet格式宽表实现，Parquet是列式存储格式，使用它你不用加载整个表，只会去加载关心那些字段，大大减少IO消耗。
3、实时统计分析这块：例如个推有款产品叫个图，就是使用Spark streaming 来实时统计。
4、复杂的 ETL 任务我们也使用 Spark。例如：我们个推推送报表这一块，每天需要做很多维度的推送报表统计。使用 Spark 通过 cache 中间结果缓存，然后再统计其他维度，大大地减少了 I/O 消耗，显著地提升了统计处理速度。
个推Spark实践案例分享
上图是个推热力图的处理架构。左边这一侧利用业务平台得到设备的实时位置数据，通过Spark Streaming以及计算得到每一个geohash格子上的人数，然后统计结果实时传输给业务服务层，在push到客户端地图上面去渲染，最终形成一个实时热力图。Spark Streaming 主要用于数据实时统计处理上。
个推教你绕过开发那些坑
1、数据处理经常出现数据倾斜，导致负载不均衡的问题，需要做统计分析找到倾斜数据特征，定散列策略。
2、使用Parquet列式存储，减少IO，提高Spark SQL效率。
3、实时处理方面：一方面要注意数据源（Kafka）topic需要多个partition，并且数据要散列均匀，使得Spark Streaming的Recevier能够多个并行，并且均衡地消费数据 。使用Spark Streaming，要多通过Spark History 排查DStream的操作中哪些处理慢，然后进行优化。另外一方面我们自己还做了实时处理的监控系统，用来监控处理情况如流 入、流出数据速度等。通过监控系统报警,能够方便地运维Spark Streaming 实时处理程序。这个小监控系统主要用了 influxdb+grafana 等实现。
4、我们测试网经常出现找不到第三方jar的情况，如果是用CDH的同学一般会遇到，就是在CDH 5.4开始，CDH的技术支持人员说他们去掉了hbase等一些jar，他们认那些jar已经不需要耦合在自己的classpath中，这个情况可以通过spark.executor.extraClassPath方式添加进来。
5、一些新入门的人会遇到搞不清transform和action，没有明白transform是lazy的，需要action触发，并且两个action前后调用效果可能不一样。
6、大家使用过程当中，对需要重复使用的RDD，一定要做cache，性能提升会很明显。
以上内容根据个推讲师袁凯在11月28号Segmentfault北京D-Day沙龙的分享整理，希望给广大开发者一些启示。小伙伴们记得将get到的干货顺手分享给身边的同学们哦~
原文地址：http://blog.51cto.com/13031991/2108090
