原視頻鏈接：https://www.slidestalk.com/AliSpark/EMapReduce191196?video
編輯：楊仲鮑，北京海致星圖科技有限公司服務端開發工程師 ，大數據愛好者，Spark 中文社區志願者
首先介紹一下阿里雲飛天大數據平臺(簡稱飛天平臺)，飛天平臺由AI-PAI（機器學習和深度學習的平臺）和大數據平臺組成。 除 EMR 之外，還有像 MaxCompute，DataHub，實時計算，圖計算等不同的計算引擎
如上圖所示，橙色部分為阿里雲自研的計算引擎/平臺，灰色部分為對接開源生態的一個計算引擎/平臺。EMR為飛天平臺內開源的重要組成部分。
今天主做三個部分的介紹
1.數據湖介紹
2.EMR數據湖方案
3.客戶實踐案例
數據湖
數據湖在15年被提出，最近兩三年變的異常火爆，在Gartner的魔力象限中數據湖屬於非常有投資和探索價值的技術。
那數據湖是什麼呢？之前我們使用數據倉庫來管理結構化數據，在Hadoop興起後，大量的非結構化、結構化數據被統一存儲到HDFS上，但隨著數據的積累可能會出現部分數據在採集時並沒有合適的應用場景，所以我們可能會對其先進行存儲，等到業務有需要了，我們再去進一步的進行開發和挖掘。
在數據量不斷增長的情況下，我們可以用像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 入門訓練營火熱報名中，點擊文末閱讀原文搶入營名額！
報名鏈接：
