2016年終盤點大數(shù)據(jù)篇：跨越巔峰，邁向成熟

大數(shù)據(jù)技術(shù)在2016年繼續(xù)取得高速的發(fā)展，并且在大數(shù)據(jù)相關(guān)的每個細(xì)分的環(huán)節(jié)，都有不同的創(chuàng)新的點。讓我們來看看這一年，大數(shù)據(jù)技術(shù)的一些重要進(jìn)展和趨勢。

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

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

WhereHows

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

Alation

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

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

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

CDAP

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

StreamSets

StreamSets是一個側(cè)重數(shù)據(jù)集成、數(shù)據(jù)加工流程構(gòu)建的平臺，也是一個開源的產(chǎn)品。通過StreamSets，用戶可以方便的接入不同的數(shù)據(jù)源，并且完成數(shù)據(jù)加工流程的構(gòu)建。SteamSets有可視化的數(shù)據(jù)流構(gòu)建工具，并且能夠?qū)\行態(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ù)處理的新的趨勢。在這個大數(shù)據(jù)流式處理大潮中，幾個關(guān)鍵的開源項目逐漸的取得了更多人的注意。

Flink

Apache Flink并不是一個新的開源項目，但是隨著大數(shù)據(jù)流式處理的日益重要，Flink因為其對流式處理的支持能力，得到了越來越多的人的重視。在2016年，幾乎所有的大數(shù)據(jù)技術(shù)大會上，都能夠看到Flink的身影。在Flink的設(shè)計理念中，數(shù)據(jù)流是一等公民，而批量操作僅僅是流式處理的一種特殊形式。Flink的開發(fā)接口的設(shè)計和Spark非常的相像，支持Java,Scala等編程語言，并且也有支持SQL的Table API，因此有非常好的易用性。另外Flink支持將已經(jīng)存在的MapReduce任務(wù)直接運行在Flink的運行環(huán)境上。

同Spark一樣，Flink也是期望基于它的核心打造一個大數(shù)據(jù)的生態(tài)系統(tǒng)，它的核心是支持流式的DataStream API和支持批量計算的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í)算法的實現(xiàn)，比如SVM,KNN,ALS等等。

Gelly

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

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

Beam

提到流式處理，不得不提的一個項目是Apache Beam。這是一個仍舊在孵化器中的項目，但是其出發(fā)點和背景使得我們不在早期就對它保持持續(xù)的關(guān)注。Beam本身不是一個流式處理平臺，而是一個統(tǒng)一的編程框架。在大數(shù)據(jù)處理和計算平臺百花齊放的今天，開發(fā)者不得不面對Spark, Flink, Storm, Apex等等不同的計算框架，而這些計算框架各自有不同的開發(fā)API，如何能夠屏蔽底層的差異，使得上層有一個統(tǒng)一的表達(dá)，對于大數(shù)據(jù)應(yīng)用開發(fā)者來講就變得非常有意義了。TalkingData在構(gòu)造自己的Data Cloud的時候就面臨這個問題，而這個時候我們發(fā)現(xiàn)Beam就給了我們這個答案。Beam系出名門，是由Google開源出來的，并且得到了Spark, Flink等等社區(qū)的大力的支持。在Beam中，主要包含兩個關(guān)鍵的部分：

Beam SDK

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

Beam Pipeline Runner

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

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

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

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

Hadoop

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

Erasure Coding的支持

這個特性真是千呼萬喚始出來。在當(dāng)前這個時代，Hadoop在一個大數(shù)據(jù)平臺中最核心的部分就是HDFS。而HDFS為了保證數(shù)據(jù)的可靠性，一直采用的是多副本的方式來存儲數(shù)據(jù)。但是這幾年數(shù)據(jù)規(guī)模的增加遠(yuǎn)遠(yuǎn)大于人的想象，而這些產(chǎn)生的數(shù)據(jù)，必然會存在冷熱數(shù)據(jù)的區(qū)分。無論冷熱，數(shù)據(jù)對于一個公司都是核心的資產(chǎn)，誰都不希望數(shù)據(jù)丟失?？墒菍τ诶鋽?shù)據(jù)，如果采用多副本方式，會浪費大量的存儲空間。通過Erasure Coding，則可以大大的降低數(shù)據(jù)存儲空間的占用。對于冷數(shù)據(jù)，可以采用EC來保存，這樣能夠降低存儲數(shù)據(jù)的花銷，而需要時，還可以通過CPU計算來讀取這些數(shù)據(jù)。

Yarn Timeline Service V.2

在Hadoop 3.0中，引入了Yarn時間軸服務(wù)v.2版本，用于應(yīng)對兩大挑戰(zhàn)：1）改善時間軸服務(wù)的可伸縮性和可靠性。2）通過引入流和聚合增強可用性

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

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

支持超過兩個NameNode

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

跨Datanode的balancer

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

Spark

在2016年，Spark迎來了最近兩年的一個最大的版本的發(fā)布，Spark 2.0的發(fā)布。從年初開始，Spark就在對Spark 2.0進(jìn)行預(yù)熱，可是Spark 2.0的發(fā)布并不如預(yù)期來的順利。5月份Spark 2.0 Preview Release發(fā)布，時隔兩個月到2016年7月份，Spark 2.0的正式版本發(fā)布。不過Spark 2.0的正式版本也并沒有完全達(dá)到預(yù)期，仍舊有很多的bug，而結(jié)構(gòu)化流式仍舊處于實驗性階段，一直到十一月發(fā)布的2.0.2，還是2.0的bug fix。在這一年中，Spark主要的發(fā)展如下：

提升性能

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

易用性

最初的一批Spark用戶都需要花費一定的時間去理解Spark的RDD模型，對應(yīng)的去了解Spark的開發(fā)的方法。雖然Spark應(yīng)用開發(fā)起來簡潔，但是相對普通程序員來講，還是有一定的門檻。隨著Spark的日益普及，降低開發(fā)難度，提高易用性變成了Spark社區(qū)的很重要的事情。摒棄掉Shark，引入自己的SQL引擎，借鑒其他的數(shù)據(jù)平臺抽象出DataFrame進(jìn)而抽象出DataSet，Spark無疑變得對于普通程序員越來越友好，對于新晉Spark開發(fā)者來講，會SQL就可以非常方便的開發(fā)大數(shù)據(jù)應(yīng)用了。

流處理

在前面我們提到了大數(shù)據(jù)流式處理是新的趨勢，Spark無疑也感受到了這個趨勢，并且期望能夠跟隨著這個趨勢演進(jìn)。Spark從一產(chǎn)生就生成自己是將流式和批式處理統(tǒng)一的一個計算框架，可是RDD的特點決定了Spark的流式只是微批次，而不是純粹的流式。而新的時代的挑戰(zhàn)者Flink則稱流式是第一等公民，并且在不同的benchmark上與Spark Streaming進(jìn)行比對。由于基礎(chǔ)設(shè)計的不同，Spark Streaming在延遲方面被Flink乃至Apex一直吊打，痛定思痛，Spark社區(qū)決定引入結(jié)構(gòu)化流式處理來應(yīng)對。這也是Spark 2.0當(dāng)中非常核心的一塊兒增強，比較遺憾的是，Spark的結(jié)構(gòu)化流式在2016年發(fā)布到現(xiàn)在，仍舊是一個實驗性的特性，讓我們期待它盡快的成熟。

Druid

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

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

展望2017

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

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

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

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