Spark技术解析及其在百度最大单集群1300台的应用实践

问题导读
1、如何理解Spark技术的运用？
2、百度开放云BMR有哪些技术运用？
3、如何看待Enhanced in-memory columnar storage？




摘要：
2015年1月10日，一场基于Spark的高性能应用实践盛宴由Databricks软件工程师连城、百度高级工程师甄鹏、百度架构师孙垚光、百度美国研发中心高级架构师刘少山四位专家联手打造。

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

2015年1月10日，Databricks软件工程师连城、百度高级工程师甄鹏、百度架构师孙垚光、百度美国研发中心高级架构师刘少山四位专家联手为我们打造了一场基于Spark的高性能应用盛宴。其中，Databircks是Spark的创建公司，而百度则是国内规模最大的Spark集群的运营者（基于出稿前，国内各大Spark用户公布的数据）——实际生产环境，最大单集群规模1300台（包含数万核心和上百TB内存），公司内部同时还运行着大量的小型Spark集群。

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 SQL可以将不同数据源的数据抽象为关系表格，并实现多数据源互操作。


目前，在External data source API上已经实现了JSON、Avro、CSV等简单格式的外部数据源支持，Parquet和ORC等更加适合数据仓库的高级文件格式的支持也正在开发 中，Spark SQL 1.2中已经搭载了一套新的Parquet数据源实现。除此之外，利用External data source API还可以实现Spark与HBase、JDBC等外部系统的高效对接。

连城表示，在1.2版本之前，开发者已经可以通过扩展RDD的方式支持各种外部数据源。因此，对比更原生的支持一些外部数据源，External data source API的意义更在于针对相应数据源进行的特殊优化，主要包括Column pruning（列剪枝）和Predicate pushdown两个方面：

Column pruning。在列剪枝中，Column pruning可以完全忽视无需处理的字段，从而显著地减少IO。


Predicate pushdown。将SQL查询中的部分过滤条件下推到更加靠近数据源的位置，利用Parquet、ORC等智能格式写入时记录的统计信息（比如最大值、最小值等）来跳过必 然不存在目标数据的数据段，从而节省磁盘IO。

使用External data source API之前


使用External data source API之后


搭载了如Parquet和ORC这样的智能格式
连城表示，在Spark 1.2版本中，External data source API只提供了查询支持，尚未提供数据写入支持。在后续版本中还将提供带分片剪枝的分片支持和数据写入支持。今后也期望将Spark SQL的Hive支持迁移到data source API上。

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（实现更快的表格扫描），同时配合内存表的统计数据，可以对大小表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模式，并有多种套餐可选。


完善的报表服务，全方位监控

在安全上，用户拥有虚拟的独立网络，在同一用户全部集群可互联的同时，BMR用户间网络被完全隔离。同时，BMR还支持动态扩容，节点规模可弹性伸缩。除此之外，在实现Spark全组件支持的同时，BMR可无缝对接百度的对象存储BOS服务，借力百度多年的存储研发经验，保证数据存储的高可靠性。

厉害呀 顶顶顶顶顶

这是哪里转来的啊

厉害！