Spark技术解析及在百度开放云BMR应用实践

2014年，Spark开源生态系统得到了大幅增长，已成为大数据领域最人气的开源项目之一，活跃在Hortonworks、IBM、 Cloudera、MapR和Pivotal等众多知名大数据公司，更拥有Spark SQL、Spark Streaming、MLlib、GraphX等多个相关项目。同时值得一提的是，Spark贡献者中有一半左右的中国人。

短短四年时间，Spark不仅发展为Apache基金会的顶级开源项目，更通过其高性能内存计算及其丰富的生态快速赢得几乎所有大数据处理用户。 2015年1月10日，一场基于Spark的高性能应用实践盛宴由Databricks软件工程师连城、百度高级工程师甄鹏、百度架构师孙垚光、百度美国 研发中心高级架构师刘少山四位专家联手打造。

Databricks软件工程师连城——Spark SQL 1.2的提升和新特性

谈及Spark SQL 1.2的提升和新特性，连城主要总结了4个方面——External data source API（外部数据源API）、列式内存存储加强（Enhanced in-memory columnar storage）、Parquet支持加强（Enhanced Parquet support）和Hive支持加强（Enhanced Hive support）。

External data source API

连城表示，因为在处理很多外部数据源中出现的扩展问题，Spark在1.2版本发布了External data source API。通过External data source API，Spark将不同的外部数据源抽象成一个关系表格，从而实现更贴近无缝的操作。

External data source API在支持了多种如JSON、Avro、CSV等简单格式的同时，还实现了Parquet、ORC等的智能支持；同时，通过这个API，开发者还可以使用JDBC将HBase这样的外部系统对接到Spark中。

连城表示，在1.2版本之前，开发者其实已经实现了各种各样外部数据源的支持，因此，对比更原生的支持一些外部数据源，External data source API的意义更在于针对相应数据源进行的特殊优化，主要包括Column pruning（列剪枝）和Pushing predicates to datasources（将predicates贴近数据源）两个方面：

Column pruning。 主要包括纵横的两种剪枝。在列剪枝中，Column pruning可以完全忽视无需处理的字段，从而显著地减少IO。同时，在某些条件查询中，基于Parquet、ORC等智能格式写入时记录的统计信息 （比如最大值、最小值等），扫描可以跳过大段的数据，从而省略了大量的磁盘扫描负载。

Pushing predicates to datasources。 在更复杂的SQL查询中，让过滤条件维度尽可能的接近数据源，从而减少磁盘和网络IO，最终提高整体端到端的性能。

使用External data source API之前

使用External data source API之后

搭载了如Parquet和ORC这样的智能格式

连城表示，在Spark 1.2版本中，External data source API并没有实现预期中的功能，在Roadmap中，First class分片支持（First class partitioning support with partition pruning）、Data sink（insertion）API、将Hive作为外部数据源等。

Enhanced in-memory columnar storage

连城表示，不管Shark，还是Spark，内存缓存表的支持都是非常重要的一个特性。他表示，虽然在1.1和之前版本中的列式内存表的性能已然 不错，但是还会出现一些问题：第一，大数据量下缓存超大体积表时（虽然不推荐，但不缺现实用例），会出现OOM等问题；第二，在列式存储中，像 Parquet、ORC这种收集统计信息然后通过这些信息做partition skipping等操作在之前版本中并没有完全实现。这些问题在1.2版本中都得到了解决，本节，连城主要介绍了语义统一、缓存实体化、基于缓存共享的查 询计划、Cache大表时的OOM问题、表格统计（Table statistics）等方面。

缓存实体化。 SQLContext.cacheTable(“tbl”)默认使用eager模式，缓存实体化将自动进行，不会再等到表被使用或触发时，避免手动做 “SELECT COUNT(*) FROM src;”。同时，新增了“CACHE [LAZY] TABLE tbl [AS SELECT …]”这样的DML。

语义统一。 早期时候，SchemaRDD.cache()和SQLContext.cacheTable(“tbl”)这两个语义是不同的。其 中，SQLContext.cacheTable会去建立一些列式存储格式相关优化，而SchemaRDD.cache()却以一行一个对象的模式进行。 在1.2版本中，这两个操作已被统一，同时各种cache操作都将得到一个统一的内存表。

基于缓存共享的查询计划。 两个得到相同结果的cache语句将共享同一份缓存数据。

避免Cache大表时的OOM问题。 优化内存表的建立和访问，减少开销，进一步提升性能；在缓存大表时，引入batched column buffer builder，将每一列切成多个batch，从而避免了OOM。

表格统计。 Table statistics，类似Parquet、ORC使用的技术，在1.2版本中主要实现了Predicate pushdown（实现更快的表格扫描）和Auto broadcast join（实现更快的表格join）。

最后，连城还详细介绍了一些关于加强Parquet和Hive支持的实现，以及Spark未来的一些工作。

百度基础架构部高级工程师甄鹏——Spark在百度开放云BMR中的实战分享

百度分布式计算团队从2011年开始持续关注Spark，并于2014年将Spark正式引入百度分布式计算生态系统中，在国内率先面向开发者及 企业用户推出了支持Spark并兼容开源接口的大数据处理产品BMR（Baidu MapReduce）。在甄鹏的分享中，我们主要了解了百度Spark 应用现状、百度开放云BMR和Spark On BMR三个方面的内容。

Spark在百度

甄鹏表示，当前百度的Spark集群由上千台物理主机（数万Cores，上百TBMemory）组成，日提交App在数百，已应用于凤巢、大搜索、直达号、百度大数据等业务。之以选择Spark，甄鹏总结了三个原因：快速高效、API 友好易用和组件丰富。

快速高效。 首先，Spark使用了线程池模式，任务调度效率很高；其次，Spark可以最大限度地利用内存，多轮迭代任务执行效率高。

API友好易用。 这主要基于两个方面：第一，Spark支持多门编程语言，可以满足不同语言背景的人使用；第二，Spark的表达能力非常丰富，并且封装了大量常用操作。

组件丰富。 Spark生态圈当下已比较完善，在官方组件涵盖SQL、图计算、机器学习和实时计算的同时，还有着很多第三方开发的优秀组件，足以应对日常的数据处理需求。

百度开放云BMR

在BMR介绍中，甄鹏表示，虽然BMR被称为Baidu MapReduce，但是这个名称已经不能完全表示出这个平台：BMR是百度开放云的数据分析服务产品，基于百度多年大数据处理分析经验，面向企业和开发 者提供按需部署的Hadoop&Spark集群计算服务，让客户具备海量数据分析和挖掘能力，从而提升业务竞争力。

如图所示，BMR基于BCC（百度云服务器），建立在HDFS和BOS（百度对象存储）分布式存储之上，其处理引擎包含了MapReduce和 Spark，同时还使用了HBase数据库。在此之上，系统集成了Pig、Hive、SQL、Streaming、GraphX、MLLib等专有服务。 在系统的最上层，BMR提供了一个基于Web的控制台，以及一个API形式的SDK。

在图片的最右边，Scheduler在BMR中起到了管理作用，使用它开发者可以编写比较复杂的作业流。

Spark On BMR

类似于通常的云服务，BMR中的Spark同样随用随起，集群空闲即销毁，帮助用户节省预算。此外，集群创建可以在3到5分钟内完成，包含了完整的Spark+HDFS+YARN堆栈。同时，BMR也提供Long Running模式，并有多种套餐可选。