原視頻連接：https://www.slidestalk.com/AliSpark/EMapReduce191196?video數據庫
編輯：楊仲鮑，北京海致星圖科技有限公司服務端開發工程師 ，大數據愛好者，Spark 中文社區志願者服務器
首先介紹一下阿里雲飛天大數據平臺(簡稱飛天平臺)，飛天平臺由AI-PAI（機器學習和深度學習的平臺）和大數據平臺組成。 除 EMR 以外，還有像 MaxCompute，DataHub，實時計算，圖計算等不一樣的計算引擎微信
如上圖所示，橙色部分爲阿里雲自研的計算引擎/平臺，灰色部分爲對接開源生態的一個計算引擎/平臺。EMR爲飛天平臺內開源的重要組成部分。架構
今天主作三個部分的介紹
1.數據湖介紹app
2.EMR數據湖方案運維
3.客戶實踐案例機器學習
數據湖
數據湖在15年被提出，最近兩三年變的異常火爆，在Gartner的魔力象限中數據湖屬於很是有投資和探索價值的技術。分佈式
那數據湖是什麼呢？以前咱們使用數據倉庫來管理結構化數據，在Hadoop興起後，大量的非結構化、結構化數據被統一存儲到HDFS上，但隨着數據的積累可能會出現部分數據在採集時並無合適的應用場景，因此咱們可能會對其先進行存儲，等到業務有須要了，咱們再去進一步的進行開發和挖掘。ide
在數據量不斷增加的狀況下，咱們能夠用像OSS ，HDFS等對象存儲來作統一式的存儲。同時咱們可能會面不一樣計算場景的選擇，好比說Ad hoc查詢，離線計算，實時計算，以及機器學習，深度學習的場景。 在不一樣的計算場景下，還須要面臨不一樣引擎的選擇，在不一樣的場景下要統一監控、受權、審計、帳號體系一系列的工做。工具
第一部分是數據獲取(圖中最左邊的框框)，主要用於採集關係型數據庫。日誌用戶點擊流到統一的存儲裏去，使用不一樣的計算服務對數據進行加工和計算，同時把計算結果應用於AI分析平臺進行機器學習或深度學習，最終將結果用於業務，使用搜索、源數據管理等能力使數據達到增值的效果。數據除計算和存儲外，還須要一系列的管控和審計的手段。
大數據技術誕生已有10 多年了，最開始你們就在本身的IDC上搭建開源軟件。隨着業務的不斷增加，數據快速的積累，業務波動很是快，可能一會兒就出現了爆發性的業務。
線下IDC採購週期很是長，很難以知足計算資源隨着業務快速增加的需求，同時業務存在高峯低谷的，白天業務的計算任務可能比較少(大部分爲Ad hoc查詢)，到了晚上可能就要擴容出一些資源進行離線報表計算。這種狀況在IDC模式就出現了算力匹配難的局面。
大概在五六年前，就已經有大量的企業開始遷移上雲，在業務數據不斷增加的時候，企業能夠快速添加實例，經過雲供應鏈的能力知足業務增加需求。若是在雲上自建Hadoop集羣或者EMR也會存在一些問題，由於本質上都是用hdfs，隨着數據的增加存儲成本會線性的增加。同時在雲上使用本地盤時，其運維流程很是複雜的。
對於大規模集羣(幾百臺幾千臺的集羣)，壞盤是一個常規事件，如何去處理這種常規事件，也是一個很是有挑戰的事情，所以逐漸演化成了圍繞OSS爲核心的這種數據湖架構。藉助OSS的分層存儲的能力，能夠實現不一樣的數據，有不一樣的存儲方式和消耗成本。同時咱們知道HDFS的NameNode在HA場景下的運維是一個很是複雜的事情，當集羣規模突破100臺以後，怎麼去把NameNode搞得比較穩定就成爲了很是有挑戰的事情，可能要投入大量的精力人力去維護。維護HA架構多是一個長期來看都無法根治的難題，那麼使用OSS就是另一種選擇，經過使用雲服務的存儲架構來規避在HDFS架構上無解的問題。
用EMR去構建企業級數據湖服務
EMR的定位是利用阿里雲的生態，100%開源，同時向企業提供穩定高可靠的開源大數據服務的產品。EMR在16年6月份上線，不斷迭代到EMR4.4，基於EMR，用戶能夠選擇使用數10 餘款的 ECS實例，實現分鐘級建立彈性伸縮的集羣。
EMR支持阿里雲的OSS，其自主研發的Jindo FS對OSS性能進行大幅度的提高；同時EMR也集成了阿里雲生態，DataWorks，PAI均可以在EMR上進行無縫的銜接。同時對於存儲類的產品(如日誌服務、MaxCompute等）均可以使用 EMR 來做爲計算引擎來計算裏邊存儲的數據。EMR全部的組件都是Apache開源版本，隨着社區的版本不斷的升級迭代演進，EMR團隊會對像Spark、Hadoop、Kafka等組件在應用性和性能上作一系列的優化和提高。
EMR採用半托管架構，在這種架構下，用戶使用時能夠得到與線下IDC使用很是相似的體驗，用戶能夠實際登錄到集羣中的ECS服務節點上，去部署管理本身的ECS服務器，同時提供一系列的企業級特性，包括像APM的對主機做業服務層面的告警和診斷，也支持MIT，Kerberos, RAM，HAS做爲鑑權平臺，而且使用Ranger做爲統一的權限管理平臺。
下圖展現了EMR 的整個開源大數據的生態，其中包含了一些軟件以及硬件。
這裏分了幾個層面。
如JindoFS是在存儲層(OSS)之上。JindoFS是EMR團隊自研的一套組件，該組件主要用來對OSS數據的讀取計算作加速。通過實際的對比測試，JindoFS的性能是要遠優於線下的HDFS服務。
Delta Lake是 databricks開源的數據湖的技術計算引擎和平臺。EMR團隊圍繞Delta Lake在Presto,Kudu和Hive的對接上作了一系列優化，同時在性能上也比開源版本有了顯著提高。值得一說的還有EMR的Flink，EMR上採用Flink是Ververica的企業版本，其在性能、管理性、易維護性上有更好的表現。
EMR主要分4種節點類型(Master,Core,Task,Gateway)。
Master節點主要部署一些像NameNode，ResourceManager， Hbase的Hmaster等服務，這些服務能夠實現集中統一的集羣管理，在建立生產集羣時打開HA選項，會自動建立一個高可用集羣。
Core節點主要部署了Yarn的NodeManager和HDFS的 DataNode。 從這個角度來講，它既能作計算，又能作存儲。對於數據可靠性來講，考慮到節點上存儲的數據，該節點沒法進行彈性伸縮和競價實例。
Task節點僅僅部署了NodeManager，在數據湖場景下可進行彈性伸縮。當用戶的數據所有在對象存儲中統一存儲時，用戶就可使用TASK節點的彈性伸縮能力快速的響應業務變化，實現計算資源的彈性擴縮容。同時可採用ECS搶佔式實例來下降成本。Task節點也支持GPU實例，在不少機器學習或者深度學習的場景下，場景計算週期是很是短(幾天或者幾周才計算一次)，但由於GPU實例價格昂貴，採用手動擴縮容的實例能夠極大的下降去成本。
Gateway節點主要用於部署Spark,Hive,Flink等各類客戶端組件，這樣不一樣的部門就可使用不一樣的Client或者客戶端的配置，實現徹底的隔離，同時避免用戶頻繁去登到集羣上進行操做。
JindoFS
HDFS誕生已經有10餘年的歷史了，其社區配套功能相對來講比較成熟和完善。可是咱們也看到它在使用上也存在的不足，如HA的架構過於複雜(若是要實現HA，須要部署JournalNode，ZKFC)，並且當集羣規模很是大時，須要考慮HDFS的Federation。當經營規模大了以後，DataNode-Decomission的週期也會很是長，主機故障或者磁盤故障須要下線節點的時候，週期長達1~2天，甚至須要專門安排人員去管理DataNode-Decomission，重啓一個NameNode可能都要花費半天的時間。
OSS優點是什麼？OSS就是阿里雲上服務化的對象存儲，它的管理和運維成本很是的低，同時有多種不一樣類型的數據分層存儲形式(如標準型、低頻型、歸檔型)。OSS經過這種方式有效的下降用戶使用成本，不須要用戶關注NameNode和Federation(由於是服務化的)，而且數據可靠性很是好(提供了11個9的數據可靠性)。因此能看到大量的客戶在使用OSS來構建企業數據湖，OSS的典型特色就是開放性好，基本上全部雲產品都會支持OSS做爲背後的存儲。
同時 OSS也存在問題，在最開始對象存儲誕生時主要是用於配合業務系統在大數據場景下進行數據存儲。由於OSS是爲通用場景而設計，因此在面向大數據計算引擎(Spark，Flink)作適配的時候會面臨性能問題。當進行rename操做的時，實際上執行的是move操做，並且是真的進行文件拷貝，不像Linux文件系統那樣夠很快的完成rename操做， list操做時也會請求全部的object，數量過多時速度極慢；一致性(最終一致性的週期)也會相對比較長一些。 當進行讀寫的時候，有可能會出現數據不一致的問題。
EMR自研的JindoFS立足於開源生態，基本上全部計算引擎均可以使用JindoFS來實現對OSS的讀取計算和查詢的操做。JindoFS一方面能發揮OSS的優點：海量數據(EB級別)存儲，同時又能發揮靈活的特性：當你使用 OSS語義的時候，基本全部的計算引擎(如其餘的計算類產品或者 BI報表工具)均可以很快獲取數據，是一個通用的接口。
JindoFS在雲上也被大規模使用，在處理HDFS 和OSS的數據的時候，可以規避文件去作rename、list等操做時的性能問題。
Jindo FS的架構以下圖所示，主服務爲Namespace Service，從服務爲Storage Service。主服務能夠部署在一個或者多個節點上，從服務會在每一個節點上都進行部署，Client服務則會在每臺EMR機器上都進行部署。當進行數據讀寫時，會先經過從服務向主服務發出請求，獲取文件的位置，若是本地不存在，則會從OSS上獲取，同時會Cache到本地 。JindoFS實現了HA架構，其 HA也是在線的，本地經過RocksDB實現，遠端經過OTS實現。因此說Jindo FS既兼顧性能，又實現了高可靠。JindoFS也能夠經過Ranger進行權限管理和設計。使用JindoFS SDK能夠很方便的把線下HDFS數據遷移到OSS進行歸檔或者使用。
JindoFS支持Block和Cache模式。Block模式下使用JindoFS，它的源數據會放在本地的RocksDB和遠端的OTS上，再也不是使用OSS通用的源數據，當數據量比較大(幾百T以上)，Block模式性能表現會更好，但通用性會相對差一些，用戶只能經過JindoFS的源數據去獲取文件的塊的位置和和詳細信息。同時JindoFS的Block模式也支持用戶去指定哪些是熱數據、冷數據、溫數據，JindoFS能有效的下降運維複雜度。
Cache模式使用本地存儲，語義也使用OSS自己的語義如oss://bucket/path。使用Cache模式的好處是通用性很是好，不光在EMR上能夠用，在其餘的計算引擎均可以使用 OSS的語義。它的不足之處在於性能，當你的數據量級很是大的時候，性能相對Block模式較差。
以上兩種模式都應基於自身業務的判斷,來進行需選擇性使用。
彈性伸縮
EMR能夠根據時間和集羣的負載(Yarn的指標收集，用戶能夠手動指定)作彈性伸縮。同時在作彈性伸縮的時候，能夠選擇多種識別類型，避免由於有特定識別類型因庫存緣由形成做業失敗，也可使用搶佔式實例來下降成本。
EMR的數據湖方案
以下圖所示，這是一個離線計算架構，數據能夠經過Kafka,日誌服務、數據集成（DataWorks裏面數據集成)或者閃電立方（阿里雲離線遷移產品）等多種方式同步數據到對象存儲中，在EMR直接讀取和計算，在工做流調度上可使用DataWorks或者Airflow，最上方數據應用包括像數據報表、數據大屏、API等等。
該離線架構優點在於能支撐一個很大規模(EB級別)的數據存儲，OSS可以無縫對接到EMR中的大數據計算引擎，同時保證優秀的性能。
結合 OSS的能力，咱們能夠實現高性能讀取。在管控層面的權限管理，可經過Ranger對全部開源組件實現統一的權限管理。
下圖是使用EMR作Ad hoc的場景，該場景有實時計算的數據流入。實時計算經過JindoFS作加速以後，再經過像Presto，Impala等開源的計算引擎對接像 BI報表，數據大屏這種實時展現。 該場景咱們多見於像實時數倉業務。
EMR新功能和特性
客戶案例
從IDC遷移上雲的典型案例
客戶數據規模爲 PB級別。上雲後發現真正的熱數據大概佔總數據的百分之十幾，經過對象存儲的分層存儲，有效下降了成本。當集羣規模較大時，Master壓力會比較大，該用戶的Master數量較多，EMR會根據集羣規模和負載的判斷，動態擴縮Master，同時也能夠自定義Master數量來作計算和集羣的部署。另外該客戶使用了彈性伸縮的能力，有一個相對獨立的Spark集羣來服務AI、ETL，該Spark集羣是一個彈性伸縮的集羣。在大數據開發這一塊，客戶使用了DataWorks來進行大數據開發。
數據高計算性能，權限管理能力，增長企業效能
多計算的集羣，集羣數量較多，同時客戶把集羣權限管理，源數據管理統一抽象作了集中管理，像Hive Meta，JindoFS Meta爲多個集羣共享的源數據。日間集羣數量和集羣節點數較少，可是夜間業務高峯須要進行擴容來知足晚上業務高峯時的計算能力，在工做流調度這塊使用了Airflow來作工做流調度。
有更多相關想法歡迎加入釘釘羣繼續討論。
相關閱讀推薦：
JindoFS - 分層存儲
關於雲原生分佈式計算和存儲引擎JindoFS，看這一篇就夠了
E- MapReduce 入門訓練營火熱報名中，點擊文末閱讀原文搶入營名額！
報名連接：
https://developer.aliyun.com/learning/trainingcamp/emr/1
本文分享自微信公衆號 - Apache Spark技術交流社區（E-MapReduce_Spark）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。