即將過去的2016年，大數(shù)據(jù)技術(shù)在持續(xù)火熱發(fā)展的同時(shí)，也在各細(xì)分領(lǐng)域取得了不同的創(chuàng)新。回顧大數(shù)據(jù)的2016，我們都得到了什么?2017年，會(huì)是大數(shù)據(jù)技術(shù)與人工智能融合迸發(fā)的時(shí)代嗎?

　　大數(shù)據(jù)管理日趨重要

隨著大數(shù)據(jù)在不同的領(lǐng)域越來越多的應(yīng)用場景的發(fā)現(xiàn)，如何對數(shù)據(jù)資產(chǎn)進(jìn)行管理就變得越來越重要。由此也產(chǎn)生了很多的創(chuàng)業(yè)公司和開源項(xiàng)目。

WhereHows

WhereHows是LinkedIn在2016年開源的一套數(shù)據(jù)目錄發(fā)現(xiàn)和數(shù)據(jù)世系管理的平臺(tái)。可以當(dāng)作企業(yè)的中心元數(shù)據(jù)管理系統(tǒng)，對接不同的數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)處理系統(tǒng)，從而能夠全面的管理企業(yè)數(shù)據(jù)目錄、數(shù)據(jù)結(jié)構(gòu)以及數(shù)據(jù)世系。

Alation

Alation是一套企業(yè)級的數(shù)據(jù)管理和數(shù)據(jù)發(fā)現(xiàn)的平臺(tái)，與WhereHows不同的是Alation并不是一個(gè)開源的平臺(tái)，而是一套商用的平臺(tái)。除了基礎(chǔ)的數(shù)據(jù)管理、數(shù)據(jù)發(fā)現(xiàn)，這個(gè)平臺(tái)還支持多角色的協(xié)作，因?yàn)閷τ跀?shù)據(jù)相關(guān)的工作，更好的協(xié)作才能提高生產(chǎn)的效率。Alation公司是成立于2012年的一家創(chuàng)業(yè)公司，2015年獲得了900萬美金的A輪融資。

大數(shù)據(jù)應(yīng)用平臺(tái)化

隨著大數(shù)據(jù)處理技術(shù)的進(jìn)一步發(fā)展，如何整合大數(shù)據(jù)不同的底層大數(shù)據(jù)處理技術(shù)，將數(shù)據(jù)集管理、數(shù)據(jù)加工流水線、數(shù)據(jù)應(yīng)用管理融合在一個(gè)統(tǒng)一的平臺(tái)無疑能夠大大降低大數(shù)據(jù)從數(shù)據(jù)引入到數(shù)據(jù)變成有價(jià)值的產(chǎn)品的復(fù)雜度。

CDAP

CDAP是CASK公司開源的大數(shù)據(jù)應(yīng)用平臺(tái)。通過將數(shù)據(jù)接入、數(shù)據(jù)管理、數(shù)據(jù)處理流水線和數(shù)據(jù)應(yīng)用開發(fā)管理集成在一個(gè)統(tǒng)一的平臺(tái)，CDAP可以使得企業(yè)象開發(fā)普通的應(yīng)用一樣開發(fā)大數(shù)據(jù)的應(yīng)用產(chǎn)品，降低開發(fā)的復(fù)雜度。如果做一個(gè)類比，CDAP的整體思路類似于在J2EE時(shí)代的WebLogic，是一個(gè)針對數(shù)據(jù)應(yīng)用的中間件平臺(tái)產(chǎn)品。

StreamSets

StreamSets是一個(gè)側(cè)重?cái)?shù)據(jù)集成、數(shù)據(jù)加工流程構(gòu)建的平臺(tái)，也是一個(gè)開源的產(chǎn)品。通過StreamSets，用戶可以方便的接入不同的數(shù)據(jù)源，并且完成數(shù)據(jù)加工流程的構(gòu)建。SteamSets有可視化的數(shù)據(jù)流構(gòu)建工具，并且能夠?qū)\(yùn)行態(tài)的數(shù)據(jù)應(yīng)用進(jìn)行監(jiān)控。相對于CDAP，StreamSets更側(cè)重于數(shù)據(jù)的接入和數(shù)據(jù)流的構(gòu)建、監(jiān)控和管理。

大數(shù)據(jù)流式處理成為趨勢

在2016年，大數(shù)據(jù)流式處理技術(shù)取得了飛速的發(fā)展，并且逐漸的變成了大數(shù)據(jù)處理的新的趨勢。在這個(gè)大數(shù)據(jù)流式處理大潮中，幾個(gè)關(guān)鍵的開源項(xiàng)目逐漸的取得了更多人的注意。

Flink

Apache Flink并不是一個(gè)新的開源項(xiàng)目，但是隨著大數(shù)據(jù)流式處理的日益重要，F(xiàn)link因?yàn)槠鋵α魇教幚淼闹С帜芰Γ玫搅嗽絹碓蕉嗟娜说闹匾暋Ｔ?016年，幾乎所有的大數(shù)據(jù)技術(shù)大會(huì)上，都能夠看到Flink的身影。

在Flink的設(shè)計(jì)理念中，數(shù)據(jù)流是一等公民，而批量操作僅僅是流式處理的一種特殊形式。Flink的開發(fā)接口的設(shè)計(jì)和Spark非常的相像，支持Java,Scala等編程語言，并且也有支持SQL的Table API，因此有非常好的易用性。另外Flink支持將已經(jīng)存在的MapReduce任務(wù)直接運(yùn)行在Flink的運(yùn)行環(huán)境上。

同Spark一樣，F(xiàn)link也是期望基于它的核心打造一個(gè)大數(shù)據(jù)的生態(tài)系統(tǒng)，它的核心是支持流式的DataStream API和支持批量計(jì)算的DataSet API。在上層則是應(yīng)用層的API，包括：

CEP

在Flink上提供了支持CEP(復(fù)雜事件處理)的庫，從而使用者可以非常方便的構(gòu)造基于CEP的應(yīng)用。

FlinkML

在Flink上提供了機(jī)器學(xué)習(xí)算法庫，類似于Spark的MLLib。當(dāng)前的Flink 1.1版本的機(jī)器學(xué)習(xí)算法庫包含了一些主流的機(jī)器學(xué)習(xí)算法的實(shí)現(xiàn)，比如SVM,KNN,ALS等等。

Gelly

Gelly是在Flink上支持圖計(jì)算的API庫，類似于Spark上的GraphX。在大數(shù)據(jù)時(shí)代，通過圖算法和圖分析能夠在很多業(yè)務(wù)場景產(chǎn)生巨大的應(yīng)用價(jià)值，比如在金融領(lǐng)域用圖發(fā)現(xiàn)羊毛黨。我相信Flink正式看中了這一點(diǎn)，在自己的核心之上，發(fā)展出來進(jìn)行圖計(jì)算的Gelly。

2016年Flink在國內(nèi)也逐漸的引起了大數(shù)據(jù)同仁們的重視，阿里巴巴針對Flink對Yarn支持的不足做了很多的優(yōu)化和修改，開發(fā)了Blink，并且積極的與Flink社區(qū)進(jìn)行溝通，希望能夠?qū)⒁恍┖诵牡男薷膍erge回社區(qū)。

Beam

提到流式處理，不得不提的一個(gè)項(xiàng)目是Apache Beam。這是一個(gè)仍舊在孵化器中的項(xiàng)目，但是其出發(fā)點(diǎn)和背景使得我們不在早期就對它保持持續(xù)的關(guān)注。Beam本身不是一個(gè)流式處理平臺(tái)，而是一個(gè)統(tǒng)一的編程框架。

在大數(shù)據(jù)處理和計(jì)算平臺(tái)百花齊放的今天，開發(fā)者不得不面對Spark, Flink, Storm, Apex等等不同的計(jì)算框架，而這些計(jì)算框架各自有不同的開發(fā)API，如何能夠屏蔽底層的差異，使得上層有一個(gè)統(tǒng)一的表達(dá)，對于大數(shù)據(jù)應(yīng)用開發(fā)者來講就變得非常有意義了。

TalkingData在構(gòu)造自己的Data Cloud的時(shí)候就面臨這個(gè)問題，而這個(gè)時(shí)候我們發(fā)現(xiàn)Beam就給了我們這個(gè)答案。Beam系出名門，是由Google開源出來的，并且得到了Spark, Flink等等社區(qū)的大力的支持。在Beam中，主要包含兩個(gè)關(guān)鍵的部分：

Beam SDK

Beam SDK提供一個(gè)統(tǒng)一的編程接口給到上層應(yīng)用的開發(fā)者，開發(fā)者不需要了解底層的具體的大數(shù)據(jù)平臺(tái)的開發(fā)接口是什么，直接通過Beam SDK的接口，就可以開發(fā)數(shù)據(jù)處理的加工流程。Beam SDK會(huì)有不同的語言的實(shí)現(xiàn)，目前提供Java，python的SDK正在開發(fā)過程中，相信未來會(huì)有更的的不同的語言的SDK會(huì)發(fā)布出來。

Beam Pipeline Runner

Beam Pipeline Runner是將用戶開發(fā)的pipeline翻譯成底層的數(shù)據(jù)平臺(tái)支持的運(yùn)行時(shí)環(huán)境的一層。針對不同的大數(shù)據(jù)平臺(tái)，會(huì)有不同的Runner。目前Flink, Spark, Apex以及google的 Cloud DataFlow都有支持Beam的Runner。

在Strata+Hadoop紐約的大會(huì)上，通過與Beam團(tuán)隊(duì)的溝通我了解到，盡管Beam現(xiàn)在仍舊是在孵化器中，但是已經(jīng)足夠的成熟和穩(wěn)定，Spotify公司就在用Beam構(gòu)造自己的大數(shù)據(jù)pipeline。

大數(shù)據(jù)分析和計(jì)算技術(shù)方興未艾

提到大數(shù)據(jù)技術(shù)，最基礎(chǔ)和核心的仍舊是大數(shù)據(jù)的分析和計(jì)算。在2016年，大數(shù)據(jù)分析和計(jì)算技術(shù)仍舊在飛速的發(fā)展，無論老勢力Hadoop還是當(dāng)紅小生Spark，乃至新興中間力量Druid，都在2016年繼續(xù)自己的快速的發(fā)展和迭代。

Hadoop

近兩年Spark的火爆使得Hadoop猶如昨日黃花，其實(shí)Hadoop并沒有停止自己的發(fā)展的腳步。在2016年，Hadoop 3.0的alpha1版本終于面世。而伴隨著Hadoop 3.0正式版本發(fā)布的日益臨近，Hadoop 3.0能夠給我們帶來些什么呢?

Erasure Coding的支持

這個(gè)特性真是千呼萬喚始出來。在當(dāng)前這個(gè)時(shí)代，Hadoop在一個(gè)大數(shù)據(jù)平臺(tái)中最核心的部分就是HDFS。而HDFS為了保證數(shù)據(jù)的可靠性，一直采用的是多副本的方式來存儲(chǔ)數(shù)據(jù)。但是這幾年數(shù)據(jù)規(guī)模的增加遠(yuǎn)遠(yuǎn)大于人的想象，而這些產(chǎn)生的數(shù)據(jù)，必然會(huì)存在冷熱數(shù)據(jù)的區(qū)分。

無論冷熱，數(shù)據(jù)對于一個(gè)公司都是核心的資產(chǎn)，誰都不希望數(shù)據(jù)丟失。可是對于冷數(shù)據(jù)，如果采用多副本方式，會(huì)浪費(fèi)大量的存儲(chǔ)空間。通過Erasure Coding，則可以大大的降低數(shù)據(jù)存儲(chǔ)空間的占用。對于冷數(shù)據(jù)，可以采用EC來保存，這樣能夠降低存儲(chǔ)數(shù)據(jù)的花銷，而需要時(shí)，還可以通過CPU計(jì)算來讀取這些數(shù)據(jù)。

Yarn Timeline Service V.2

在Hadoop 3.0中，引入了Yarn時(shí)間軸服務(wù)v.2版本，用于應(yīng)對兩大挑戰(zhàn)：

改善時(shí)間軸服務(wù)的可伸縮性和可靠性。

通過引入流和聚合增強(qiáng)可用性

MapReduce任務(wù)本地優(yōu)化

通過map輸出本地收集的支持，可以大幅優(yōu)化一些對shuffle比較敏感的任務(wù)的性能，能夠有超過30%的性能的提升。

支持超過兩個(gè)NameNode

在以前的版本中，NameNode只能有兩個(gè)來實(shí)現(xiàn)高可靠性，其中一個(gè)namenode是活躍的，另外一個(gè)則是standby。但是有些場景需要更高的可靠性，在Hadoop 3.0中可以配置超過一個(gè)的Standby的name node,從而保證更高的可靠性。

跨Datanode的balancer

在舊的版本中，一個(gè)datanode管理一個(gè)物理機(jī)上的所有的磁盤，正常情況下是平均分配的寫入，但是如果有磁盤的增減，就會(huì)造成數(shù)據(jù)的傾斜。在Hadoop 3.0上引入了新的跨DataNode的balancer，可以更好的解決磁盤數(shù)據(jù)傾斜的問題。

Spark

在2016年，Spark迎來了最近兩年的一個(gè)最大的版本的發(fā)布，Spark 2.0的發(fā)布。從年初開始，Spark就在對Spark 2.0進(jìn)行預(yù)熱，可是Spark 2.0的發(fā)布并不如預(yù)期來的順利。5月份Spark 2.0 Preview Release發(fā)布，時(shí)隔兩個(gè)月到2016年7月份，Spark 2.0的正式版本發(fā)布。

不過Spark 2.0的正式版本也并沒有完全達(dá)到預(yù)期，仍舊有很多的bug，而結(jié)構(gòu)化流式仍舊處于實(shí)驗(yàn)性階段，一直到十一月發(fā)布的2.0.2，還是2.0的bug fix。在這一年中，Spark主要的發(fā)展如下：

提升性能

從鎢絲計(jì)劃開始，Spark就開始進(jìn)行架構(gòu)性的調(diào)整。無論開始的堆外內(nèi)存的管理，到后邊2.0逐漸引入的本地代碼生成，都是希望能夠使得自己能夠變得更快。而很多Spark的用戶也正式因?yàn)镾park的速度優(yōu)勢，逐漸從傳統(tǒng)的MapReduce切換到了Spark。

易用性

最初的一批Spark用戶都需要花費(fèi)一定的時(shí)間去理解Spark的RDD模型，對應(yīng)的去了解Spark的開發(fā)的方法。雖然Spark應(yīng)用開發(fā)起來簡潔，但是相對普通程序員來講，還是有一定的門檻。

隨著Spark的日益普及，降低開發(fā)難度，提高易用性變成了Spark社區(qū)的很重要的事情。摒棄掉Shark，引入自己的SQL引擎，借鑒其他的數(shù)據(jù)平臺(tái)抽象出DataFrame進(jìn)而抽象出DataSet，Spark無疑變得對于普通程序員越來越友好，對于新晉Spark開發(fā)者來講，會(huì)SQL就可以非常方便的開發(fā)大數(shù)據(jù)應(yīng)用了。

流處理

在前面我們提到了大數(shù)據(jù)流式處理是新的趨勢，Spark無疑也感受到了這個(gè)趨勢，并且期望能夠跟隨著這個(gè)趨勢演進(jìn)。Spark從一產(chǎn)生就生成自己是將流式和批式處理統(tǒng)一的一個(gè)計(jì)算框架，可是RDD的特點(diǎn)決定了Spark的流式只是微批次，而不是純粹的流式。而新的時(shí)代的挑戰(zhàn)者Flink則稱流式是第一等公民，并且在不同的benchmark上與Spark Streaming進(jìn)行比對。

由于基礎(chǔ)設(shè)計(jì)的不同，Spark Streaming在延遲方面被Flink乃至Apex一直吊打，痛定思痛，Spark社區(qū)決定引入結(jié)構(gòu)化流式處理來應(yīng)對。這也是Spark 2.0當(dāng)中非常核心的一塊兒增強(qiáng)，比較遺憾的是，Spark的結(jié)構(gòu)化流式在2016年發(fā)布到現(xiàn)在，仍舊是一個(gè)實(shí)驗(yàn)性的特性，讓我們期待它盡快的成熟。

Druid

Druid作為一個(gè)大數(shù)據(jù)的OLAP系統(tǒng)在2016年取得了巨大的成功，尤其在中國。在中國有越來越多的互聯(lián)網(wǎng)公司采用Druid來構(gòu)造自己的大數(shù)據(jù)分析平臺(tái)，而Druid社區(qū)在中國也變得非常的活躍。幾次Druid Meetup都取得了非常大的成功，Druid的核心研發(fā)，華人工程師楊仿今也開始獨(dú)立創(chuàng)業(yè)，并且獲得了資本的青睞。

2015年的時(shí)候當(dāng)時(shí)在國內(nèi)還只有很少的公司在采用Druid。在2016年，阿里巴巴、迅雷、小米等等公司都開始采用Druid來構(gòu)建自己的大數(shù)據(jù)平臺(tái)。阿里巴巴基于Druid做了非常深度的定制開發(fā)來支撐自己的業(yè)務(wù)，而我們也針對Druid在多維度精準(zhǔn)排重統(tǒng)計(jì)的不足，將自己的AtomCube與Druid以插件的方式做了集成，使得Druid作為一個(gè)大數(shù)據(jù)的OLAP平臺(tái)，具有了更強(qiáng)的能力。有理由相信，隨著Druid在中國這個(gè)全球數(shù)據(jù)規(guī)模最大的市場的不同應(yīng)用場景的落地，這個(gè)開源項(xiàng)目必定會(huì)產(chǎn)生越來越大的影響力。

展望2017

回顧完2016年，讓我們再對2017年做個(gè)展望，看看2017年在大數(shù)據(jù)領(lǐng)域會(huì)發(fā)生些什么：

流式數(shù)據(jù)處理成為主流，會(huì)有越來越多的企業(yè)采用流式數(shù)據(jù)來支撐自己分析、預(yù)測，從而能夠更快速的做出決策;

人工智能和大數(shù)據(jù)技術(shù)融合，大數(shù)據(jù)技術(shù)的發(fā)展驅(qū)動(dòng)了2016年人工智能的火熱，而將人工智能與大數(shù)據(jù)處理相融合，構(gòu)造智慧的大數(shù)據(jù)平臺(tái)將會(huì)是一個(gè)新的趨勢。人的智慧和機(jī)器的智能相互配合，可以大大的降低大數(shù)據(jù)處理的開銷，從而顯著提高大數(shù)據(jù)的投入產(chǎn)出比;

數(shù)據(jù)資產(chǎn)管理受到越來越多企業(yè)的重視，隨著大數(shù)據(jù)加工和處理技術(shù)的日趨成熟，如何管理企業(yè)的數(shù)據(jù)資產(chǎn)變得越來越重要。相信會(huì)有越來越多的企業(yè)將會(huì)成立專門的大數(shù)據(jù)部門，來管理企業(yè)的數(shù)據(jù)資產(chǎn)，而對應(yīng)的數(shù)據(jù)管理技術(shù)產(chǎn)品將會(huì)在2017年變得更為普及。