120      阿裏雲  技術社區[雲棲]

大數據生態圈&Docker發展概況：最新動態及國內情況

目錄：

【大數據生態圈】

• Hadoop
  Hadoop 3.0.0 Alpha版本發布

• Druid
  Druid 0.9.2版本發布

• Kudu
  Apache Kudu 1.1.0正式發布

• HAWQ
  HAWQ 2.1.0.0企業版正式發布

【Docker發展概況】

• 官方版本發布情況

• 國內情況

• 落地情況

• 感謝名單

大數據生態圈

一、Hadoop

Hadoop 3.0.0 Alpha版本發布

由於Hadoop 2.0是基於JDK 1.7開發的，而JDK 1.7在2015年4月已停止更新，所以Hadoop社區於2016年9月3日發布了全新的基於JDK 1.8的Hadoop 3.0.0 alpha版本。

目前Hadoop 3.0.0僅提供Alpha測試版本，整個係統的穩定性沒有保障，所以不推薦在正式的開發係統中使用該版本。

相比於Hadoop2.7.0，3.0.0版本更新的主要變更的官方鏈接：

https://hadoop.apache.org/docs/r3.0.0-alpha1/index.html

全部變更的官方連接：

https://hadoop.apache.org/docs/r3.0.0-alpha1/hadoop-project-dist/hadoop-common/release/3.0.0-alpha1/RELEASENOTES.3.0.0-alpha1.html

我們針對主要的功能點版本進行了翻譯，如下：

1、Java的最低版本要求從Java 7改成了Java 8

3.0以後所有的Hadoop JARs都是基於Java 8進行編譯的，所有還在使用Java 7或者是更低版本的用戶，應該升級到Java 8。

2、HDFS支持糾刪碼（Erasure Coding、EC）

Erasure coding糾刪碼技術簡稱EC，是一種數據保護技術。最早用於通信行業中數據傳輸中的數據恢複，是一種編碼容錯技術。他通過在原始數據中加入新的校驗數據，使得各個部分的數據產生關聯性。在一定範圍的數據出錯情況下，通過糾刪碼技術都可以進行恢複。

與副本技術相比，糾刪碼是一種能夠顯著的節約空間的用於存儲持久化數據的方法。進行數據存儲的時候，標準編碼（比如Reed-Solomon (10,4)）有著1.4倍的空間開銷，而如果使用HDFS的副本模式已經數據存儲的時候，有著3倍的空間開銷。由於糾刪碼在進行重建和遠程讀的時候會有額外的開銷，所以它一般情況下，被用於存儲冷的，不經常被訪問的數據。用戶在使用糾刪碼這一功能的時候應該要考慮CPU以及網絡的額外開銷。

關於HDFS的糾刪碼的更多細節，可以訪問官方文檔或者Jira：

https://hadoop.apache.org/docs/r3.0.0-alpha1/hadoop-project-dist/hadoop-hdfs/HDFSErasureCoding.html

https://issues.apache.org/jira/browse/HDFS-7285

國內也有相關的技術博客文章：

https://www.iteblog.com/archives/1684

3、YARN 時間軸服務V.2

在Hadoop2.4版本之前對任務執行的監控隻開發了針對MR的Job History Server，它可以提供給用戶用戶查詢已經運行完成的作業的信息，但是後來，隨著在YARN上麵集成的越來越多的計算框架，比如spark、Tez，也有必要為基於這些計算引擎的技術開發相應的作業任務監控工具，所以Hadoop的開發人員就考慮開發一款更加通用的Job History Server，即YARN Timeline Server。

3.0版本引入了YARN Timeline Service: v.2，主要用與解決兩大挑戰：

• 提高時間軸服務的穩定性和可拓展性。

• 增強流式和聚合的可用性

更多關於YARN Timeline Service: v.2 可以訪問官方文檔

https://hadoop.apache.org/docs/r3.0.0-alpha1/hadoop-yarn/hadoop-yarn-site/TimelineServiceV2.html

4、Shell腳本重寫

The Hadoop shell scripts have been rewritten to fix many long-standing bugs and include some new features. While an eye has been kept towards compatibility, some changes may break existing installations.

為了修複一些長時間存在的BUG並添加一些新的功能，Hadoop的shell腳本在3.0版本被重新進行了改寫。其中絕大部分的腳本能夠保證一定的兼容性，但是有些變化還是會是現有的一些配置出現問題。

相關不兼容的變更我們可以查看：

https://issues.apache.org/jira/browse/HADOOP-9902

如果你想了解3.0版本中腳本的更多細節我們可以訪問Unux Shell用戶指導及API手冊：

https://hadoop.apache.org/docs/r3.0.0-alpha1/hadoop-project-dist/hadoop-common/UnixShellGuide.html

https://hadoop.apache.org/docs/r3.0.0-alpha1/hadoop-project-dist/hadoop-common/UnixShellAPI.html

5、MapReduce任務級別的本地優化

MapReduce 添加了C/C++輸出到collector的本地實現(包括了Spill，Sort，和Ifile等），通過作業級別的的參數調整就能夠切換到該實現上對於shuffle密集型的作業來說，可以提高30%以上的性能。

更多細節可以查看：

https://issues.apache.org/jira/browse/MAPREDUCE-2841

6、支持兩個以上的Namenode

早期版本的HDFS Namenode的高可用提供了一個active狀態的Namenode和一個standby狀態的Namenode，他們之間通過3個JournalNode應用edit的方式進行同步。在這種架構下，允許兩個節點中的任意一個節點失效。有的時候，我們的係統可能需要更要的容錯性，這個時候我們就需要3.0的多Namenode的新特性了。它可以允許用戶配置多個standby Namenode，如果說，配置說三個Namenode，5個JournalNode，這樣這個係統就允許壞兩個Namenode了，進一步提高了係統的冗餘性。

如何進行配置多個Namenode請查看如下文檔：

https://hadoop.apache.org/docs/r3.0.0-alpha1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html

7、多個服務的默認端口的變化

在此之前，很多Hadoop的默認端口都是屬於linux的臨時端口範圍（32768-61000）這意味著我們的服務在啟動的時候由於端口已經被其他的服務所占用導致啟動的失敗。現在這些可能會引起衝突的端口都已經做了變更，不再是在臨時端口範圍內了，這些端口的變化會影響Namenode、SecondaryNamenode、DataNode和KMS。這些變化，在Jira中都有說明，詳見：

https://issues.apache.org/jira/browse/HDFS-9427

https://issues.apache.org/jira/browse/HADOOP-12811

8、支持Microsoft Azure Data Lake filesystem連接器

現在Hadoop支持Microsoft Azure Data Lake filesystem，並可替代作為Hadoop默認的文件係統。

9、Intra-DataNode均衡器

一個datanode可以管理多個磁盤，正常寫入，各個磁盤會被均勻寫滿。然後，後期當重新添加或者替換磁盤的時候，就會導致DataNode內部的數據存儲嚴重傾斜。這種情況下，HDFS的balancer是無法進行處理的。這種情況下，通過調用dfs diskbalancer CLI，可以實現 Intra-DataNode 的動態balance。

更多細節詳見：

https://hadoop.apache.org/docs/r3.0.0-alpha1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html

10、重寫守護進程及任務的堆管理

https://issues.apache.org/jira/browse/HADOOP-10950

介紹了配置守護進程Heap大小的新的方法，現在已經可以實現基於主機內存的動態調節，同時HADOOP_HEAPSIZE此參數已經被棄用。

https://issues.apache.org/jira/browse/MAPREDUCE-5785

介紹如何去配置了Map以及Reduce task的heap大小。現在所需的堆大小不在需要通過任務配置或者Java選項來實現，已經指定的配置選項不受變更的影響。

二、Druid

Druid 0.9.2版本發布

Druid是一款開源的分布式分析型數據存儲係統，它最大的賣點是實時OLAP，導入即可查詢，OLAP查詢亞秒級響應，數據量可以擴展到PB級，其高並發以及高可用等特性適合構建麵向用戶的數據分析產品。

2016年12月1日，Druid發布了0.9.2版本。在這一版本中包含了來自30多位Contributor貢獻的100多項性能提升、穩定性提升以及Bug修複。主要的新功能包括新的Group By查詢引擎，數據攝入階段可以關閉Roll-up，支持對Long類型字段的過濾，Long類型字段的新編碼方式，HyperUnique和DataSketches的性能提升，基於Caffeine的查詢緩存實現，可配置緩存策略的Lookup擴展，支持ORC格式數據的攝入以及增加了標準差和方差的Aggregator(聚合函數)等。

1、新的Group By查詢引擎

Druid為了提升性能以及優化內存管理，徹底重寫了Group By查詢引擎。在官方測試數據源上進行基準測試，有2~5倍的性能提升。新的查詢引擎依然支持嚴格限製內存使用大小，同時增加了在內存耗盡時溢寫到磁盤的選項，這樣避免對結果集大小的限製以及潛在的內存溢出異常發生。新引擎模式默認是不開啟的，你可以通過修改查詢上下文中的相應參數開啟，在Druid的未來發行版本中將默認采用新的查詢引擎。其實現細節，詳見https://druid.io/docs/0.9.2/querying/groupbyquery.html#implementation-details。

2、禁用Roll-up的選項

從一開始，Druid在數據攝入階段以及查詢階段，區分維度和度量值。Druid是唯一僅有的數據庫，支持在數據攝入階段進行聚合，我們把這一行為叫做“Roll-up”。Roll-up可以顯著地提升查詢性能，但會失去查詢原始數據的能力。 禁用Roll-up以後，會將原始數據攝入，但不會影響查詢階段的聚合。Roll-up默認依然是開啟的，具體配置詳見“https://druid.io/docs/0.9.2/ingestion/index.html ”。

3、對整數類型列的篩選能力

Druid新增了對整數類型列的複雜篩選能力，整數類型列包括long類型的度量值以及特殊的__time(時間)列。以它為基礎，將開創一係列新功能：

• 對時間列的篩選聚合，它對於實現對比兩個時間段的查詢非常有幫助，例如使用DataSketches實現用戶留存。

• 針對整數類型列進行篩選，特別是禁用Roll-up以後。

4、Long類型字段的新編碼方式

直到現在，Druid中Long類型字段，包括Long類型度量值以及特殊的__time列，都是采用64bit 8字節 longs存儲，然後使用LZ4按塊壓縮。Druid0.9.2增加了新的編碼方式，它會在很多場景下，減少文件大小以及提升性能。它有如下Long類型編碼方式：

• auto，會在掃描一遍數據以後，得到其基數以及最大值，選擇table或者Delta編碼方式，使得存儲使用小於64bit存儲每一行。

• longs，默認的策略，總是使用64bit存儲每一行。

新增加了“none”的壓縮策略，類似原來的“uncompressed”，摒棄了原來塊存儲的方式，提升了隨機查找的性能。

默認仍然采用“longs”編碼方式+“lz4”壓縮方式。在官方測試中，產生有效收益的兩個選項是 "auto" + "lz4"(通常文件大小會小於longs+lz4)和 "auto" + "none"（通常會比longs+lz4塊，但文件大小影響各不相同）。

5、Sketch性能提升

DataSketch性能最多提升80%，HyperUnique性能提升19%~30%。
 

三、Kudu

Apache Kudu 1.1.0正式發布

Kudu是Cloudera開源的新型列式存儲係統，是Apache Hadoop生態圈的新成員之一（incubating），專門為了對快速變化的數據進行快速的分析，是對HDFS與HBase的補充 。 

新功能和改進：

1. Python客戶端已經與C ++和Java客戶端具有同等特性。

2. 列表謂詞。

3. Java客戶端現在具有客戶端跟蹤功能。

4. Kudu現在發布用於使用Scala 2.11編譯的Spark 2.0的jar文件。

5. Kudu采用Raft算法實現預選舉，在我們的測試中這個功能大大提高了穩定性。

更多內容可以參考鏈接：

https://kudu.apache.org/2016/11/15/weekly-update.html

四、HAWQ

Apache HAWQ是基於HDFS存儲上的MPP引擎，兼備MPP並行數據庫的查詢處理優勢和HDFS存儲的可擴展性優勢。此外，HAWQ還提供了Madlib數據挖掘工具，提供了對R，Python，Perl的腳本嵌入，使得用戶可以方便地開發兼容第三方語言和SQL的軟件。

HAWQ  2.1.0.0企業版正式發布

2016年12月，基於Apache HAWQ 2.0 的Pivotal HDB 2.1.0.0企業版正式發布，功能包括：

1、資源管理及彈性查詢執行

可動態從YARN申請資源並在負載下降時動態歸還。支持查詢級別的資源管理，可使用多級資源管理隊列分配用戶以及查詢使用資源。自動對資源進行隔離及強製。

基於virtual segment實現彈性查詢執行。基於查詢的代價動態分配virtual segment，使其運行在集群部分節點。解決了經典MPP引擎缺點，提高擴展性和查詢並行度。

徹底解耦了計算和存儲，Segment節點和Master節點。這意味著在集群節點大小變化的時候表不需要重新分布，從而HAWQ可以實現秒級擴容。

新調度器可以動態組合不同節點上的查詢執行進程來動態調度和管理查詢的執行。

2、存儲相關

優化了AO以及Parquet表存儲格式，使得一個大文件可以被多個Scanner進程以快級別分割來讀。使得HAWQ可以達到優化的查詢並行度。

將一個表的所有數據文件存放在HDFS的一個目錄中，方便了HAWQ與外部係統的數據交換，比如外部係統可以把數據文件放到該表對應HDFS目錄中，實現數據加載。

HAWQ需要HDFS文件塊位置信息來實現派遣計算到數據的調度。HDFS在RPC的處理速度上在高並發時往往響應較慢。元數據緩存提升了數據局部性匹配方法的效率。

實現與HCatalog集成。基於PXF對Hive表的訪問不需要先創建外部表；支持將Hive中ORC存儲格式文件作為外部表進行查詢，同時在外部表處理中支持謂詞下推和投影下推。

HAWQ Register 能夠直接將HDFS文件注冊到HAWQ內部表。可被用於：直接注冊Hadoop生態係統其他模塊生成的parquet存儲格式文件； HAWQ集群的遷移。

3、其他功能改進及增強

新版gporca查詢優化器包括了許多新功能和大量的錯誤修正。

基於心跳和動態探測的容錯服務，可動態檢測到新加節點並且移除失效節點。

用戶可以通過一個新的命令“hawq”來完成幾乎所有的管理操作，該命令整合了所有的其它子命令。

4、其他模塊集成與支持

HDP 2.4.x的版本升級到2.5.0，包括Apache Hadoop從2.7.1 到 2.7.3 升級。

Ambari 2.2.2版本插件現在支持HAWQ 2.0的配置和部署。

HAWQ/PXF插件現在支持自動的Kerberos安全配置。

Docker發展概況

一、官方版本發布情況

Docker從2013年開源。2015年是Docker開源項目突飛勐進的一年，這段時間Docker官方先後發布了V1.5、V1.6、V1.7、V1.8、V1.9等5個大版本以及7個修訂版本。

2016年Docker發展同樣迅速，截止2016年12月7日Docker官方共發布了V1.10、V1.11、V1.12、V1.13等4個大版本以及8個修訂版本。

重大變化主要是V1.12版本，原Swarm項目改為SwarmKit並內置到了Docker引擎中。

詳情：https://github.com/docker/docker/releases

二、國內情況

Docker容器技術目前在國內還屬於早期階段。

• 第一：技術太新，技術人員需要一個接受的過程；

• 第二：容器技術和虛擬化技術不一樣，和企業業務結合還需要進一步磨合。

阿裏雲和Docker官方合作，Docker公司選擇aliyun平台作為Docker Hub在中國運營的基礎服務，且阿裏獲得Docker DataCenter的運營權。

由工信部、中國信息通信研究院聯合成立的雲計算開源產業聯盟（OSCAR），在12月2日，發布了國內第一個“容器技術應用場景”規範，且該規範已立項為中國通信標準協會研究課題。

三、落地情況

國內的企業也有實際落地使用，互聯網居多。代表性的列舉幾個：

• 互聯網行業：京東、微博、知乎、豆瓣、PPTV；etc。

• 汽車行業：長安汽車、上海汽車；etc。

• 金融保險：永隆銀行、中英人壽、廣發證券；etc。

• 其他：…

感謝名單

感謝本期提供寶貴信息和建議的專家朋友，排名不分先後。

原文發布時間為：2016-12-23

本文來自雲棲社區合作夥伴DBAplus

最後更新：2017-05-13 08:42:04

  上一篇：  NoSQL & NewSQL家族：後起之秀及RethinkDB的告別

  下一篇：  達夢、GBase、星瑞格，你用了哪個？