即將過去的2016年，大數據技術在持續火熱發展的同時，也在各細分領域取得了不同的創新?；仡櫞髷祿?016，我們都得到了什么?2017年，會是大數據技術與人工智能融合迸發的時代嗎?

[[180114]]

大數據管理日趨重要

隨著大數據在不同的領域越來越多的應用場景的發現，如何對數據資產進行管理就變得越來越重要。由此也產生了很多的創業公司和開源項目。

WhereHows

WhereHows是LinkedIn在2016年開源的一套數據目錄發現和數據世系管理的平臺?？梢援斪髌髽I的中心元數據管理系統，對接不同的數據存儲和數據處理系統，從而能夠全面的管理企業數據目錄、數據結構以及數據世系。

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回社區。

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做了非常深度的定制開發來支撐自己的業務，而我們也針對Druid在多維度精準排重統計的不足，將自己的AtomCube與Druid以插件的方式做了集成，使得Druid作為一個大數據的OLAP平臺，具有了更強的能力。有理由相信，隨著Druid在中國這個全球數據規模最大的市場的不同應用場景的落地，這個開源項目必定會產生越來越大的影響力。

展望2017

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

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

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

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