大数据管理日趋重要

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

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版本，用于应对两大挑战：

改善时间轴服务的可伸缩性和可靠性。

通过引入流和聚合增强可用性

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年变得更为普及。