解读 2016 之大数据篇：跨越巅峰，迈向成熟

即将过去的 2016 年，大数据技术在持续火热发展的同时，也在各细分领域取得了不同的创新。回顾大数据的 2016，我们都得到了什么？2017 年，会是大数据技术与人工智能融合迸发的时代吗？

大数据管理日趋重要

随着大数据在不同的领域越来越多的应用场景的发现，如何对数据资产进行管理就变得越来越重要。由此也产生了很多的创业公司和开源项目。

WhereHows

WhereHows 是 LinkedIn 在 2016 年开源的一套数据目录发现和数据世系管理的平台。可以当作企业的中心元数据管理系统，对接不同的数据存储和数据处理系统，从而能够全面的管理企业数据目录、数据结构以及数据世系。

Alation

Alation 是一套企业级的数据管理和数据发现的平台，与 WhereHows 不同的是 Alation 并不是一个开源的平台，而是一套商用的平台。除了基础的数据管理、数据发现，这个平台还支持多角色的协作，因为对于数据相关的工作，更好的协作才能提高生产的效率。Alation 公司是成立于 2012 年的一家创业公司，2015 年获得了 900 万美金的 A 轮融资。

大数据应用平台化

随着大数据处理技术的进一步发展，如何整合大数据不同的底层大数据处理技术，将数据集管理、数据加工流水线、数据应用管理融合在一个统一的平台无疑能够大大降低大数据从数据引入到数据变成有价值的产品的复杂度。

CDAP

CDAP 是 CASK 公司开源的大数据应用平台。通过将数据接入、数据管理、数据处理流水线和数据应用开发管理集成在一个统一的平台，CDAP 可以使得企业象开发普通的应用一样开发大数据的应用产品，降低开发的复杂度。如果做一个类比，CDAP 的整体思路类似于在 J2EE 时代的 WebLogic，是一个针对数据应用的中间件平台产品。

StreamSets

StreamSets 是一个侧重数据集成、数据加工流程构建的平台，也是一个开源的产品。通过 StreamSets，用户可以方便的接入不同的数据源，并且完成数据加工流程的构建。SteamSets 有可视化的数据流构建工具，并且能够对运行态的数据应用进行监控。相对于 CDAP，StreamSets 更侧重于数据的接入和数据流的构建、监控和管理。

大数据流式处理成为趋势

在 2016 年，大数据流式处理技术取得了飞速的发展，并且逐渐的变成了大数据处理的新的趋势。在这个大数据流式处理大潮中，几个关键的开源项目逐渐的取得了更多人的注意。

Flink

Apache Flink 并不是一个新的开源项目，但是随着大数据流式处理的日益重要，Flink 因为其对流式处理的支持能力，得到了越来越多的人的重视。在 2016 年，几乎所有的大数据技术大会上，都能够看到 Flink 的身影。

在 Flink 的设计理念中，数据流是一等公民，而批量操作仅仅是流式处理的一种特殊形式。Flink 的开发接口的设计和 Spark 非常的相像，支持 Java,Scala 等编程语言，并且也有支持 SQL 的 Table API，因此有非常好的易用性。另外 Flink 支持将已经存在的 MapReduce 任务直接运行在 Flink 的运行环境上。

同 Spark 一样，Flink 也是期望基于它的核心打造一个大数据的生态系统，它的核心是支持流式的 DataStream API 和支持批量计算的 DataSet API。在上层则是应用层的 API，包括：

CEP

在 Flink 上提供了支持 CEP(复杂事件处理）的库，从而使用者可以非常方便的构造基于 CEP 的应用。

FlinkML

在 Flink 上提供了机器学习算法库，类似于 Spark 的 MLLib。当前的 Flink 1.1 版本的机器学习算法库包含了一些主流的机器学习算法的实现，比如 SVM,KNN,ALS 等等。

Gelly

Gelly 是在 Flink 上支持图计算的 API 库，类似于 Spark 上的 GraphX。在大数据时代，通过图算法和图分析能够在很多业务场景产生巨大的应用价值，比如在金融领域用图发现羊毛党。我相信 Flink 正式看中了这一点，在自己的核心之上，发展出来进行图计算的 Gelly。

2016 年 Flink 在国内也逐渐的引起了大数据同仁们的重视，阿里巴巴针对 Flink 对 Yarn 支持的不足做了很多的优化和修改，开发了 Blink，并且积极的与 Flink 社区进行沟通，希望能够将一些核心的修改 merge 回社区。而 TalkingData 也在对 Flink 进行尝试，相信在 Flink 社区，会有越来越多的中国人的身影和贡献。

Beam

提到流式处理，不得不提的一个项目是 Apache Beam。这是一个仍旧在孵化器中的项目，但是其出发点和背景使得我们不在早期就对它保持持续的关注。Beam 本身不是一个流式处理平台，而是一个统一的编程框架。

在大数据处理和计算平台百花齐放的今天，开发者不得不面对 Spark, Flink, Storm, Apex 等等不同的计算框架，而这些计算框架各自有不同的开发 API，如何能够屏蔽底层的差异，使得上层有一个统一的表达，对于大数据应用开发者来讲就变得非常有意义了。

TalkingData 在构造自己的 Data Cloud 的时候就面临这个问题，而这个时候我们发现 Beam 就给了我们这个答案。Beam 系出名门，是由 Google 开源出来的，并且得到了 Spark, Flink 等等社区的大力的支持。在 Beam 中，主要包含两个关键的部分：

Beam SDK

Beam SDK 提供一个统一的编程接口给到上层应用的开发者，开发者不需要了解底层的具体的大数据平台的开发接口是什么，直接通过 Beam SDK 的接口，就可以开发数据处理的加工流程。Beam SDK 会有不同的语言的实现，目前提供 Java，python 的 SDK 正在开发过程中，相信未来会有更的的不同的语言的 SDK 会发布出来。

Beam Pipeline Runner

Beam Pipeline Runner 是将用户开发的 pipeline 翻译成底层的数据平台支持的运行时环境的一层。针对不同的大数据平台，会有不同的 Runner。目前 Flink, Spark, Apex 以及 google 的 Cloud DataFlow 都有支持 Beam 的 Runner。

在 Strata+Hadoop 纽约的大会上，通过与 Beam 团队的沟通我了解到，尽管 Beam 现在仍旧是在孵化器中，但是已经足够的成熟和稳定，Spotify 公司就在用 Beam 构造自己的大数据 pipeline。

大数据分析和计算技术方兴未艾

提到大数据技术，最基础和核心的仍旧是大数据的分析和计算。在 2016 年，大数据分析和计算技术仍旧在飞速的发展，无论老势力 Hadoop 还是当红小生 Spark，乃至新兴中间力量 Druid，都在 2016 年继续自己的快速的发展和迭代。

Hadoop

近两年 Spark 的火爆使得 Hadoop 犹如昨日黄花，其实 Hadoop 并没有停止自己的发展的脚步。在 2016 年，Hadoop 3.0 的 alpha1 版本终于面世。而伴随着 Hadoop 3.0 正式版本发布的日益临近，Hadoop 3.0 能够给我们带来些什么呢？

Erasure Coding 的支持

这个特性真是千呼万唤始出来。在当前这个时代，Hadoop 在一个大数据平台中最核心的部分就是 HDFS。而 HDFS 为了保证数据的可靠性，一直采用的是多副本的方式来存储数据。但是这几年数据规模的增加远远大于人的想象，而这些产生的数据，必然会存在冷热数据的区分。

无论冷热，数据对于一个公司都是核心的资产，谁都不希望数据丢失。可是对于冷数据，如果采用多副本方式，会浪费大量的存储空间。通过 Erasure Coding，则可以大大的降低数据存储空间的占用。对于冷数据，可以采用 EC 来保存，这样能够降低存储数据的花销，而需要时，还可以通过 CPU 计算来读取这些数据。

Yarn Timeline Service V.2

在 Hadoop 3.0 中，引入了 Yarn 时间轴服务 v.2 版本，用于应对两大挑战：

1. 改善时间轴服务的可伸缩性和可靠性。
2. 通过引入流和聚合增强可用性

MapReduce 任务本地优化

通过 map 输出本地收集的支持，可以大幅优化一些对 shuffle 比较敏感的任务的性能，能够有超过 30% 的性能的提升。

支持超过两个 NameNode

在以前的版本中，NameNode 只能有两个来实现高可靠性，其中一个 namenode 是活跃的，另外一个则是 standby。但是有些场景需要更高的可靠性，在 Hadoop 3.0 中可以配置超过一个的 Standby 的 name node, 从而保证更高的可靠性。

跨 Datanode 的 balancer

在旧的版本中，一个 datanode 管理一个物理机上的所有的磁盘，正常情况下是平均分配的写入，但是如果有磁盘的增减，就会造成数据的倾斜。在 Hadoop 3.0 上引入了新的跨 DataNode 的 balancer，可以更好的解决磁盘数据倾斜的问题。

Spark

在 2016 年，Spark 迎来了最近两年的一个最大的版本的发布，Spark 2.0 的发布。从年初开始，Spark 就在对 Spark 2.0 进行预热，可是 Spark 2.0 的发布并不如预期来的顺利。5 月份 Spark 2.0 Preview Release 发布，时隔两个月到 2016 年 7 月份，Spark 2.0 的正式版本发布。

不过 Spark 2.0 的正式版本也并没有完全达到预期，仍旧有很多的 bug，而结构化流式仍旧处于实验性阶段，一直到十一月发布的 2.0.2，还是 2.0 的 bug fix。在这一年中，Spark 主要的发展如下：

提升性能

从钨丝计划开始，Spark 就开始进行架构性的调整。无论开始的堆外内存的管理，到后边 2.0 逐渐引入的本地代码生成，都是希望能够使得自己能够变得更快。而很多 Spark 的用户也正式因为 Spark 的速度优势，逐渐从传统的 MapReduce 切换到了 Spark。

易用性

最初的一批 Spark 用户都需要花费一定的时间去理解 Spark 的 RDD 模型，对应的去了解 Spark 的开发的方法。虽然 Spark 应用开发起来简洁，但是相对普通程序员来讲，还是有一定的门槛。

随着 Spark 的日益普及，降低开发难度，提高易用性变成了 Spark 社区的很重要的事情。摒弃掉 Shark，引入自己的 SQL 引擎，借鉴其他的数据平台抽象出 DataFrame 进而抽象出 DataSet，Spark 无疑变得对于普通程序员越来越友好，对于新晋 Spark 开发者来讲，会 SQL 就可以非常方便的开发大数据应用了。

流处理

在前面我们提到了大数据流式处理是新的趋势，Spark 无疑也感受到了这个趋势，并且期望能够跟随着这个趋势演进。Spark 从一产生就生成自己是将流式和批式处理统一的一个计算框架，可是 RDD 的特点决定了 Spark 的流式只是微批次，而不是纯粹的流式。而新的时代的挑战者 Flink 则称流式是第一等公民，并且在不同的 benchmark 上与 Spark Streaming 进行比对。

由于基础设计的不同，Spark Streaming 在延迟方面被 Flink 乃至 Apex 一直吊打，痛定思痛，Spark 社区决定引入结构化流式处理来应对。这也是 Spark 2.0 当中非常核心的一块儿增强，比较遗憾的是，Spark 的结构化流式在 2016 年发布到现在，仍旧是一个实验性的特性，让我们期待它尽快的成熟。

Druid

Druid 作为一个大数据的 OLAP 系统在 2016 年取得了巨大的成功，尤其在中国。在中国有越来越多的互联网公司采用 Druid 来构造自己的大数据分析平台，而 Druid 社区在中国也变得非常的活跃。几次 Druid Meetup 都取得了非常大的成功，Druid 的核心研发，华人工程师杨仿今也开始独立创业，并且获得了资本的青睐。

2015 年的时候当时在国内还只有很少的公司在采用 Druid。在 2016 年，阿里巴巴、迅雷、小米等等公司都开始采用 Druid 来构建自己的大数据平台。阿里巴巴基于 Druid 做了非常深度的定制开发来支撑自己的业务，而 TalkingData 也针对 Druid 在多维度精准排重统计的不足，将自己的 AtomCube 与 Druid 以插件的方式做了集成，使得 Druid 作为一个大数据的 OLAP 平台，具有了更强的能力。有理由相信，随着 Druid 在中国这个全球数据规模最大的市场的不同应用场景的落地，这个开源项目必定会产生越来越大的影响力。

展望 2017

回顾完 2016 年，让我们再对 2017 年做个展望，看看 2017 年在大数据领域会发生些什么：

• 流式数据处理成为主流，会有越来越多的企业采用流式数据来支撑自己分析、预测，从而能够更快速的做出决策；
• 人工智能和大数据技术融合，大数据技术的发展驱动了 2016 年人工智能的火热，而将人工智能与大数据处理相融合，构造智慧的大数据平台将会是一个新的趋势。人的智慧和机器的智能相互配合，可以大大的降低大数据处理的开销，从而显著提高大数据的投入产出比；
• 数据资产管理受到越来越多企业的重视，随着大数据加工和处理技术的日趋成熟，如何管理企业的数据资产变得越来越重要。相信会有越来越多的企业将会成立专门的大数据部门，来管理企业的数据资产，而对应的数据管理技术产品将会在 2017 年变得更为普及。

作者介绍

阎志涛，现任 TalkingData 研发副总裁，本科毕业于北京大学大气物理专业，硕士毕业于华北计算计算技术研究所，研究方向为分布式计算系统。在加入 TalkingData 之前，历任 IBM CDL 资深架构师，Oracle 亚太区首席中间件技术顾问，BEA 亚太区首席中间件技术顾问等职务。超过 15 年的 IT 领域从业经验，一直从事大规模分布式计算系统、中间件、BI 等相关工作。

感谢杜小芳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。