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

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

隨著大數(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是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是一個側(cè)重?cái)?shù)據(jù)集成,、數(shù)據(jù)加工流程構(gòu)建的平臺，也是一個開源的產(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)控和管理。

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

Apache Flink并不是一個新的開源項(xiàng)目,，但是隨著大數(shù)據(jù)流式處理的日益重要,，F(xiàn)link因?yàn)槠鋵α魇教幚淼闹С帜芰Γ玫搅嗽絹碓蕉嗟娜说闹匾?。?016年,，幾乎所有的大數(shù)據(jù)技術(shù)大會上，都能夠看到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也是期望基于它的核心打造一個大數(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ù)時代，通過圖算法和圖分析能夠在很多業(yè)務(wù)場景產(chǎn)生巨大的應(yīng)用價值,，比如在金融領(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ū),。而TalkingData也在對Flink進(jìn)行嘗試,，相信在Flink社區(qū)，會有越來越多的中國人的身影和貢獻(xiàn),。

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

在大數(shù)據(jù)處理和計(jì)算平臺百花齊放的今天,，開發(fā)者不得不面對Spark, Flink, Storm, Apex等等不同的計(jì)算框架，而這些計(jì)算框架各自有不同的開發(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會有不同的語言的實(shí)現(xiàn),，目前提供Java，python的SDK正在開發(fā)過程中,，相信未來會有更的的不同的語言的SDK會發(fā)布出來,。

Beam Pipeline Runner

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

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

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

近兩年Spark的火爆使得Hadoop猶如昨日黃花,，其實(shí)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ù),，如果采用多副本方式,，會浪費(fèi)大量的存儲空間。通過Erasure Coding,，則可以大大的降低數(shù)據(jù)存儲空間的占用,。對于冷數(shù)據(jù)，可以采用EC來保存,，這樣能夠降低存儲數(shù)據(jù)的花銷,，而需要時，還可以通過CPU計(jì)算來讀取這些數(shù)據(jù),。

Yarn Timeline Service V.2

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

1. 改善時間軸服務(wù)的可伸縮性和可靠性,。

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

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

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

支持超過兩個NameNode

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

跨Datanode的balancer

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

在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)化流式仍舊處于實(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)一定的時間去理解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)一的一個計(jì)算框架,，可是RDD的特點(diǎn)決定了Spark的流式只是微批次，而不是純粹的流式,。而新的時代的挑戰(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)在,，仍舊是一個實(shí)驗(yàn)性的特性,，讓我們期待它盡快的成熟。

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

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

回顧完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年變得更為普及。

今日薦文

點(diǎn)擊下方圖片即可閱讀

盤點(diǎn)：2016年互聯(lián)網(wǎng)界發(fā)生的十大事件

---