转载

【PPT】Databricks、Cloudera、阿里、腾讯等Spark实践PPT集萃

在2015 中国Spark技术峰会上，十余位专家分享了Spark的最新实践，而现在就从PPT方面带大家做一个简单的回顾。

一、Databricks工程师连城：Spark SQL结构化数据分析(PPT下载)

【PPT】Databricks、Cloudera、阿里、腾讯等Spark实践PPT集萃

Databricks工程师连城

连城详细解读了“Spark SQL结构化数据分析”。他介绍了Spark1.3版本中的很多新特性。重点介绍了DataFrame。其从SchemaRDD演变而来，提供了更加高层抽象的API，在形态上与R和Python很类似。Spark DataFrame vs.RDD，有些类似于动态语言和静态语言的区别，在很多场景下，DataFrame优势比较明显。1.3版中，Spark进一步完善了外部数据源API，并可智能进行优化。通过轻巧的抽象，DataFrame支持各类数据源，如支持Hive，S3、Hadoop HDFS、Parquet、MySQL、HBase、dBase等，所以很容易在其基础进行各类数据分析。Spark Core比Hadoop代码量精简很多，Spark SQL的代码更加精简，所以可读性增强很多。

二、英特尔大数据技术中心研发经理黄洁：Spark优化及实践经验分享(PPT下载)

英特尔大数据技术中心研发经理黄洁

黄洁就Spark的内存管理、IO提升和计算优化3个方面进行了详细讲解。通过黄洁分享过程中的互动调查发现，现场数百人中有接近80%的来宾表示已经或准备使用Spark。而在这80%的来宾中，有10%的朋友期望使用Spark做高级的机器学习和图分析，10%的朋友期望做复杂的交互式OLAP/BI，10%的朋友希望做实时的流计算。对于Spark，黄洁表示，它将成为大数据的一个重要角色，同时，也将成为下一代IA大数据主要平台。

三、Cloudera高级架构师田凤占：Spark 驱动智能大数据分析应用(PPT下载)

Cloudera高级架构师田凤占

田凤占的演讲主题是Spark驱动智能大数据分析应用，对于Spark，他认为Spark将取代MapReduce成为通用的Hadoop计算框架，这主要因为：在与Hadoop社区良好集成的同时，Spark当下已经得到更广泛社区和提供商的支持;卓越的数据科学和机器学习等。演讲期间，田博士还通过多个公司的具体用例来展现Spark的价值：Conviva通过实时分析流量规律以及更精细的流量控制，优化终端用户的在线视频体验，对于Conviva，Spark的主要价值在于快速原型开发、共享的离线和在线计算业务逻辑、开源的机器学习算法;雅虎通过Spark加速广告投放的模型训练管道，特征提取提高3X，用协同过滤进行内容推荐，对于他们来说Spark的主要价值在于降低数据管道的延迟、迭代式机器学习、高效的P2P广播。

四、IBM中国研究院高级研究员陈冠诚：基于OpenStack、Docker和Spark打造SuperVessel大数据公有云 (PPT下载)

IBM中国研究院高级研究员陈冠诚

陈冠诚介绍，SuperVessel是一个构建于OpenStack及Power7/Power8的公有云，提供Spark as Service、Docker Service以及CogniNve CompuNng Service等服务。对于为何选择Docker和Spark技术打造SuperVessel公有云，他也给与了解释。选择OpenStack的原因有两点:1. 社区活跃者、社区贡献者等超越其他竞争对手;2. 支持Docker。选择Docker有三点原因：1. 资源占用率远小于KVM，2. 启动非常快，3. 可以逐步构建、恢复和复用容器;选择Spark基于以下四点原因：1. 快，2.统一，3.生态系统发展很快，4.porting to Power。最后总结时，他表示Spark+OpenStack+Docker在OpenPower服务器上能够很好地运行，Docker化服务能够让Devops更加简单，他也强调注意监测everything。

五、腾讯高级工程师王联辉：腾讯在Spark上的应用与实践优化(PPT下载)

腾讯高级工程师王联辉

王联辉深入分享了“腾讯在Spark上的应用与实践优化”。2015年年初，腾讯TDW(Tencent Distributed Data Warehouse)的Spark集群已经达到如下规模：Gaia集群结点数，8000+;HDFS的存储空间，150PB+;每天新增数据，1PB+;每天任务数，1M+;每天计算量，10PB+。王联辉表示，腾讯已经从2013年的Spark 0.6版本开始，用到了当时的Spark1.2版本。典型应用在三个方面：预测用户的广告点击概率;计算二个好友间的共同好友数;用于ETL的SparkSQL和DAG任务。优化方面，腾讯做的比较深入。如应用程序开发中的使用经验;对于ETL作业使用动态资源扩缩容特性;Redcue阶段在Map阶段未全部完成前执行;基于数据的大小预测Stage的Partition数;为SparkSQL的每个Session分配一个Driver;Count(distinct)的优化;基于排序的GroupBy/Join。

六、阿里巴巴淘宝技术部高级技术专家黄明：基于Spark Streaming和GraphX的动态图计算(PPT下载)

阿里巴巴淘宝技术部高级技术专家黄明

黄明分享的主题是“图流合壁: 基于Spark Streaming和GraphX的动态图计算 ”，他首先对GraphX和Streaming + MLlib的发展进行了介绍，但是在淘宝实践的过程中，他们也遇到了新的问题和挑战。在流图合璧的优点上他总结了两点：模型细腻化，相比于使用普通的算子，可以通过强大的算子，获得更好的准确度和效果;性能优化，利用图算子，可以避免进行RDD的耗时操作。在流图合璧的注意点中，他重点强调了下面几点：资源保障：针对超长的Streaming任务，合理配置Core和Worker，Memory，必须保证大多数情况不会出现严重的延迟;波动和尖刺：线上真实环境中，每周期的数据量会有波动的现象;当数据源切换后，进行数据补全时同样会产生尖刺;先根据前N周期运行时的每周期输入数据量和每周期处理时间，计算出系统处理能力的阈值，接下来的周期根据该阈值进行错峰处理。假死：图中传递的消息可能会过多以至于作业假死，需要限制消息的规模;数据堆积：当一个周期的输入数据，超出系统处理能力，就会顺延接下来周期的数据处理，数据会产生堆积;创建数据缓冲池实现错峰，根据每个周期的输入数据量预估处理时间，若预估处理时间大于时间阈值，将多余部分放入缓冲池，若预估时间小于时间阈值，则从缓冲池中释放出相应比例的数据。

七、亚信科技大数据平台研发部门经理田毅：Spark平台在电信运营商的应用实践(PPT下载)

亚信科技大数据平台研发部门经理田毅

田毅重点分享了多个项目的实践。比如基于Spark改造用户标签分析查询平台。最初通信数据和上网数据，通过数据库，TCL脚本，SQL实现探索、监控和分析。其存在很多问题：标签数量越来越大，数据库负载过高，扩展成本高;标签表的列数随着标签数量增加不断增多，部分现场达到2000+，只能通过分表方式解决，查询时需要Join操作;标签与指标的计算无法摆脱SQL的约束，无法快速集成机器学习的算法。第一次改造是将Spark SQL+HDFS代替SQL。好处很明显：使用SparkSQL+Parquet的方案，有效保证了查询效率;原有系统基本不用太大改造;查询系统具备平行扩展能力。但也有一些新的问题产生，如增加了从数据库倒出数据，加载到HDFS的额外步骤;增加了从文本数据转化为Parquet格式的额外步骤。第二次改造将原有数据库换成了HDFS，将TCL脚本换为SparkSQL。不仅整个系统的扩展性进一步增强，而且两套SparkSQL可以根据各自忙闲时的不同，共享整个系统的计算资源。等到Spark 1.3.0发布后，External Datasource API进一步增强;DataFrame提供了丰富多样的数据源支持;DataFrame提供了一整套用于操纵数据的DSL。这些帮助项目彻底摆脱了标签分析算法对于SQL的依赖，前端也可以通过ExtDatasource按需抽取数据，降低了ETL对系统的依赖。而且基于DF的处理程序代码量仅有原程序的1/10，可读性大大提高。同样深入地项目分析还有基于Spark Streaming改造内容识别平台等。