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

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

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

?WhereHows

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

?Alation

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

▊大數(shù)據(jù)應用平臺化

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

?CDAP

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

?StreamSets

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

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

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

?Flink

ApacheFlink并不是一個新的開源項目，但是隨著大數(shù)據(jù)流式處理的日益重要，F(xiàn)link因為其對流式處理的支持能力，得到了越來越多的人的重視。在2016年，幾乎所有的大數(shù)據(jù)技術大會上，都能夠看到Flink的身影。

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

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

CEP

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

FlinkML

在Flink上提供了機器學習算法庫，類似于Spark的MLLib。當前的Flink1.1版本的機器學習算法庫包含了一些主流的機器學習算法的實現(xiàn)，比如SVM,KNN,ALS等等。

Gelly

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

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

?Beam

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

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

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

BeamSDK

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

BeamPipelineRunner

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

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

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

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

?Hadoop

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

ErasureCoding的支持

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

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

YarnTimelineServiceV.2

在Hadoop3.0中，引入了Yarn時間軸服務v.2版本，用于應對兩大挑戰(zhàn)：

改善時間軸服務的可伸縮性和可靠性。

通過引入流和聚合增強可用性

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

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

支持超過兩個NameNode

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

跨Datanode的balancer

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

?Spark

在2016年，Spark迎來了最近兩年的一個最大的版本的發(fā)布，Spark2.0的發(fā)布。從年初開始，Spark就在對Spark2.0進行預熱，可是Spark2.0的發(fā)布并不如預期來的順利。5月份Spark2.0PreviewRelease發(fā)布，時隔兩個月到2016年7月份，Spark2.0的正式版本發(fā)布。

不過Spark2.0的正式版本也并沒有完全達到預期，仍舊有很多的bug，而結構化流式仍舊處于實驗性階段，一直到十一月發(fā)布的2.0.2，還是2.0的bugfix。在這一年中，Spark主要的發(fā)展如下：

提升性能

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

易用性

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

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

流處理

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

由于基礎設計的不同，SparkStreaming在延遲方面被Flink乃至Apex一直吊打，痛定思痛，Spark社區(qū)決定引入結構化流式處理來應對。這也是Spark2.0當中非常核心的一塊兒增強，比較遺憾的是，Spark的結構化流式在2016年發(fā)布到現(xiàn)在，仍舊是一個實驗性的特性，讓我們期待它盡快的成熟。

?Druid

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

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

▊展望2017：

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

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

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

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

更多資訊請關注工業(yè)以太網(wǎng)頻道