簡介： 數禾科技從成立伊始就組建了大資料團隊並搭建了大資料平臺。並在ECS上搭建了自己的Cloudera Hadoop叢集。但隨著公司網際網路金融業務的快速擴張發展，大資料團隊承擔的責任也越來越重，實時數倉需求，日誌分析需求，即席查詢需求，資料分析需求等，每個業務提出的需求都極大的考驗這個Cloudera Hadoop叢集的能力。為了減輕Cloudera叢集的壓力，我們結合自身業務情況，在阿里雲上落地一個適合數禾當前現實狀況的資料湖。

1.數禾科技

數禾科技成立於2015年8月，是分眾傳媒、紅杉資本、新浪等聯合投資的C輪金融科技公司。公司的願景是做陪伴使用者一生的智慧金融家，秉承開放，挑戰，專業，創新的價值觀，讓人人享有金融服務最優解。 公司的主要產品是還唄和拿鐵智投，主要提供信貸，理財，電商等服務，已經擁有8000萬註冊使用者。作為國內金融科技代表性企業，數禾科技率先將大資料和AI技術引入智慧獲客、智慧風控、智慧運營、智慧客服等多個方面。截至目前，數禾科技已與包括銀行、信貸、持牌消金、基金和保險等在內的100餘家金融機構展開合作。

2.雲上自建CDH

數禾科技從成立伊始就組建了大資料團隊並在某雲廠商上搭建了大資料平臺。我們在某雲廠商上購買了EC2例項，並在EC2例項上搭建了自己的Cloudera Hadoop叢集。早期，這個Cloudera Hadoop叢集只是來做T+1離線數倉，半夜等到業務日切結束後，我們用Sqoop元件抽取業務資料庫的全量或增量資料到Hadoop叢集，用離線數倉Hive做一系列ETL清洗後，把結果資料生成郵件傳送給領導做下一步決策，或推送到資料庫供Tableau報表展示，或插入到業務資料庫讓業務系統來呼叫。但是隨著公司網際網路金融業務的快速擴張發展，大資料團隊承擔的責任也越來越重，實時數倉需求，日誌分析需求，即席查詢需求，資料分析需求等，每個業務提出的需求都極大的考驗這個Cloudera Hadoop叢集的能力。為了滿足實時數倉需求，我們在Cloudera叢集上安裝了Hbase元件；為了滿足日誌分析的需求，我們在Cloudera叢集上安裝了Flume、Kafka元件；為了滿足即席查詢的需求，我們在Cloudera叢集上安裝了Presto元件；為了滿足資料分析的需求，我們在Cloudera叢集上安裝了Jupyter元件，每新增一個業務需求就是對原有系統穩定性的巨大挑戰。

Cloudera叢集

除了業務需求的不斷增多，公司的組織架構越來越複雜，人員越來越多，各類資料總量的指數級上升，Cloudera叢集的各種弊端已經顯現，且逐漸不能承受這些挑戰。

擴充套件性差

叢集規模擴容需要在Cloudera Manager上操作，需要運維人員掌握一定的技能，且存在一定操作風險。另外，如果有突發情況或臨時需求需要大規模擴容時，需要先購買大量的EC2機器然後經過一系列複雜操作加入叢集，事後又需要一系列複雜操作釋放這些機器，且這些線上操作對叢集的線上業務穩定造成很大困擾。

費用很高

儲存費用方面，剛開始我們沒有預料到日後資料量的飛速發展，我們在Cloudera叢集的HDFS儲存使用了三個副本，且EC2機器配置了SSD磁碟，再加上每週的資料備份也佔用了大量磁碟資源，磁碟費用一直居高不下；計算費用方面，晚上任務多計算資源不夠，白天任務少計算資源多餘，這種資源需求差帶來費用的浪費。

叢集更新困難

我們使用的是Cloudera5.5.1的版本，幾年下來為了叢集的穩定執行一直不敢更新，而搭建新版本Cloudera叢集做叢集遷移又涉及到大量的人力物力，所以這個老版本一直在服役。因為叢集相容阻礙了我們使用新的開源元件，或者需要花很大的精力去做開源元件的重構，阻礙了新技術的引進。

維護門檻高

搭建一套Cloudera叢集並進行後續維護對運維人員的技術要求較高，而解決實際問題需要更高的技術要求。另外Cloudera Manager不開源和Cloudera社群不夠活躍也對叢集運維造成一定的困擾。

叢集容災差

資料容災，HDFS儲存三副本無法跨可用區。服務容災，服務節點無法跨可用區部署。可用區故障會影響整個叢集的穩定。

3.雲上混合架構

為了減輕Cloudera叢集的壓力，我們想到把一部分業務遷移到雲廠商上產品，逐漸形成了雲上混合架構。

根據業務和功能不同，搭建了若干雲上EMR叢集

這些雲上EMR叢集共享儲存和元資料。但是由於EMR Hive版本和Cloudera Hive版本不相容，導致元資料無法統一，最終形成了Cloudera Hive和EMR Hive兩套元資料。這些EMR叢集減輕了Cloudera叢集的壓力

為了減輕Cloudera的壓力我們設計EMR Hive混合架構Chive

Chive架構就是把EMR Hive的元資料接入Cloudera Hive，相當於使用Cloudera HDFS的儲存，但是用了EMR的計算資源。Hive混合架構也大大減輕了Cloudera叢集的壓力

冷熱資料分離

Cloudera叢集上的熱資料儲存在HDFS上，而冷資料透過Cloudera Hive建外表的方式放到S3桶上，在S3上設定生命週期定期把資料放入冷儲存。

雲上混合架構

有了雲上混合架構實踐，實際已經有一個大資料資料湖的雛形，我們想趁著某雲廠商遷移到阿里雲之際，在阿里雲上落地一個適合數禾當前現實狀況的資料湖。

4. 阿里雲第一代資料湖4.1 什麼是資料湖

資料湖是一個集中式儲存庫，允許您以任意規模儲存所有結構化和非結構化資料。你可以按原樣儲存資料，而無需先對資料進行結構化處理，然後運用不同型別的引擎進行分析，包括大資料處理、視覺化、實時分析、機器學習等，以指導做出更好的決策。資料湖與資料倉庫相比

特性 資料倉庫 資料湖 資料 來自事務系統、運營資料庫和業務線應用程式的關係資料 來自 IoT 裝置、網站、移動應用程式、社交媒體和 企業應用程式的非關係和關係資料 Schema 設計在資料倉庫實施之前（寫入型 Schema） 寫入在分析時（讀取型 Schema） 價效比 更快查詢結果會帶來較高儲存成本 更快查詢結果只需較低儲存成本 資料質量 可作為重要事實依據的高度監管資料 任何可以或無法進行監管的資料（例如原始資料） 使用者 業務分析師 資料科學家、資料開發人員和業務分析師（使用監 管資料） 分析 批處理報告、BI 和視覺化 機器學習、預測分析、資料發現和分析

資料湖解決方案的基本要素

安全地儲存和編目資料

資料湖允許您儲存關係資料和非關係資料。它們還使您能夠透過對資料進行爬網、編目和建立索引來了解湖中的資料。最後，必須保護資料以確保您的資料資產受到保護。

分析

資料湖允許組織中的各種角色（如資料科學家、資料開發人員和業務分析師）透過各自選擇的分析工具和框架來訪問資料。這包括 Apache Hadoop、Presto 和 Apache Spark 等開源框架，以及資料倉庫和商業智慧供應商提供的商業產品。資料湖允許您執行分析，而無需將資料移至單獨的分析系統。

機器學習

資料湖將允許組織生成不同型別的見解，包括報告歷史資料以及進行機器學習（構建模型以預測可能的結果），並建議一系列規定的行動以實現最佳結果。我們根據資料湖的定義和基本要素，在阿里雲上落地適合數禾當前現實狀況的第一代資料湖方案。

4.2 阿里雲資料湖設計4.2.1 阿里雲資料湖整體架構

阿里雲資料湖整體架構

專有網路VPC（Virtual Private Cloud）是使用者基於阿里雲建立的自定義私有網路, 不同的專有網路之間二層邏輯隔離，使用者可以在自己建立的專有網路內建立和管理雲產品例項，比如ECS、負載均衡、RDS等。我們把公司的業務放到兩個VPC下，業務VPC和大資料VPC。抽數EMR從業務VPC的RDS、OSS、KAFKA中抽取資料落到資料湖OSS中形成ODS層的資料，核心數倉EMR T+1對ODS層資料做ETL生成CDM數倉層和ADS集市層的資料供其他大資料EMR和業務EMR使用。下面分章節介紹我們在阿里雲資料湖落地中的解決方案和實踐。

4.2.2 統一儲存和元資料管理

統一儲存是指把儲存設定在OSS物件儲存上作為資料湖，若干EMR叢集統一使用這個資料湖。阿里雲物件儲存OSS（Object Storage Service）是阿里雲提供的海量、安全、低成本、高持久的雲端儲存服務。其資料設計永續性不低於12個9。OSS具有與平臺無關的RESTful API介面，可以在任何應用、任何時間、任何地點儲存和訪問任意型別的資料。也可以使用阿里雲提供API、SDK介面或者OSS遷移工具輕鬆地將海量資料移入或移出阿里雲OSS。資料儲存到阿里雲OSS以後，可以選擇標準儲存（Standard）作為主要儲存方式，也可以選擇成本更低、儲存期限更長的低頻訪問儲存（Infrequent Access）、歸檔儲存（Archive）、冷歸檔儲存（Cold Archive）作為不經常訪問資料的儲存方式。基於OSS的這些特性很適合做資料湖的儲存。統一元資料是指，使用資料湖的若干EMR中的元件統一使用一套元資料，比如Hive，Ranger，Hue等。我們把這些EMR元資料統一放在外接的RDS例項上，阿里雲關係型資料庫RDS（Relational Database Service）是一種穩定可靠、可彈性伸縮的線上資料庫服務。基於阿里雲分散式檔案系統和SSD盤高效能儲存，我們可以快速搭建穩定可靠的資料庫服務，相比自建資料庫有便宜易用，具有靈活計費、按需變配、即開即用、高效能、高可用架構、多種容災方案、高安全性等特點。也很適合做統一元資料儲存。

4.2.3 多EMR多OSS桶設計

利用統一OSS儲存和統一元資料的架構，我們設計了多EMR多OSS桶的框架

資料湖上多EMR多OSS桶設計

抽數EMR T+1抽取業務RDS到資料湖，核心數倉EMR在分層數倉中進行一系列ETL操作生成CDM公共維度層資料，業務EMR基於CDM公共維度層資料進行ETL操作生成ADS集市層資料，EMR presto對CDM和ADS的資料進行即席查詢。一個業務EMR主要提供即席查詢服務和DAG排程任務服務，使用者只能把自己的即席查詢和排程任務提交到他所在部門的EMR，且我們可以設定YARN佇列資源把兩種任務所佔資源進行隔離。

業務EMR提供服務

4.2.4 分散式排程系統設計

Airflow是一個可程式設計，排程和監控的工作流平臺，基於有向無環圖DAG Airflow可以定義一組有依賴的任務，並按照依賴依次執行。Airflow提供了豐富的命令列工具用於系統管控，而其Web管理介面同樣也可以方便的管控排程任務，並且對任務執行狀態進行實時監控，方便了系統的運維和管理。Airflow 系統在執行時有許多守護程序，它們提供了 Airflow 的全部功能。守護程序包括 Web伺服器-WebServer、排程程式-Scheduler、執行單元-Worker、訊息佇列監控工具-Flower等。這些守護程序彼此之間是獨立的，他們並不相互依賴，也不相互感知，每個守護程序在執行時只處理分配到自己身上的任務。基於Airflow的這種特性我們搭建了基於資料湖的Airflow叢集高可用的分散式排程體系。

資料湖上Airflow分散式排程體系

為了在EMR上便捷執行任務，我們把Airflow Worker部署在EMR的Gateway上，因為Gateway上有所有EMR當前部署元件的客戶端命令和配置。我們也可以透過增加單個Worker節點的守護程序數來垂直擴充套件Worker能力提高叢集任務併發度，也可以新增更多 Gateway（一個Gateway部署一個Worker）來水平擴充套件Worker能力提高叢集任務併發度。現實中我們為了提高任務併發度且減低單個Gateway的壓力，為高併發提交作業的核心數倉叢集和抽數叢集配置了兩個Gateway和Airflow Worker。後續我們還準備為Airflow Master部署兩個節點，解決Master節點單點故障的問題。

4.2.5 使用者許可權系統設計

使用者許可權系統一直是架構設計的核心。我們設計了基於資料湖上三層使用者許可權體系，第一層RAM訪問控制，第二層EMR執行引擎訪問許可權，第三層大資料互動式分析訪問許可權。

資料湖上三層使用者許可權體系

第一層訪問控制（RAM）是阿里雲提供的管理使用者身份與資源訪問許可權的服務。RAM允許在一個阿里雲賬號下建立並管理多個身份，並允許給單個身份或一組身份分配不同的許可權，從而實現不同使用者擁有不同資源訪問許可權的目的。我們給每個EMR綁定了一個ECS應用角色，而每個ECS應用角色只能訪問資料湖裡相應的OSS桶。第二層EMR執行引擎訪問許可權，包括HiveServer2，Presto，Spark等執行引擎。首先我們需要了解，認證(Authentication)是指驗證使用者所用的身份是否是對的，授權(Authorization)是指驗證使用者所用身份操作是否有許可權。HiveServer2支援多種使用者認證方式：NONE、NOSASL、KERBEROS、LDAP、PAM、CUSTOM等。而許可權認證可以使用HIVE自帶的許可權體系、RANGER、SENTRY等開源元件。使用Presto的Hive Connector，Presto和Hive可以共用同套使用者許可權體系。而經過阿里雲EMR大資料團隊的支援，Spark客戶端也可以支援這套使用者許可權體系。最終我們使用EMR Openldap儲存使用者和使用者組資訊，EMR Ranger提供集中式的許可權管理框架。而EMR Openldap的使用者和組資訊會和公司的AD進行同步，AD中新進員工或者離職員工資訊都會T+1方式同步到EMR Openldap。

OpenLdap和Ranger使用者許可權管理體系

第三層大資料互動式分析訪問許可權。我們自建了一套類HUE的統一用數大資料互動式分析查詢系統，透過限制互動式分析查詢系統的EMR訪問入口，使用者只能訪問本部門的EMR。透過這三層使用者許可權系統，可基本覆蓋全場景使用者取數需求。

4.2.6 EMR彈性伸縮設計

EMR的彈性伸縮功能可以根據業務需求和策略設定伸縮策略。彈性伸縮開啟並配置完成後，當業務需求增長時EMR會自動為您增加Task節點以保證計算能力，當業務需求下降時EMR會自動減少Task節點以節約成本。在我們的資料湖上跑了大量的EMR叢集，正是由於EMR彈性伸縮的特性，我們能在滿足業務需求情況下節省成本和提高執行效率，這也是大資料上雲相比傳統IDC自建大資料叢集最重要的優勢之一。我們設定了若干彈性伸縮規則如下，主要遵循彈性擴容要比彈性縮容的閾值門檻低的原則。

4.2.7 負載均衡管理

EMR叢集是無狀態，可隨時新建和銷燬。但是不能因為EMR叢集的新建和銷燬影響對外提供的服務介面穩定，於是我們設計了資料湖上EMR叢集的統一服務介面層。HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支援虛擬主機，它是免費、快速並且可靠的一種解決方案。我們採用HAProxy的四層網路層負載均衡，也就是TCP和UDP的負載均衡來提供統一服務。在實現上，我們主要用HAProxy代理各個EMR的HiveServer2介面，ResouceManger介面，HiveMetaStore介面，Presto Http介面等，且讓HAProxy支援 Include 載入多個模組配置檔案的方式便於維護和重啟。

4.2.8 OSS桶生命週期管理

數倉ODS層的資料和其他數倉層的資料相比具有不可再生的特性（業務RDS庫的資料會定期做刪除，數倉承擔了資料備份的功能），我們把ODS層的資料放在多版本桶上，能夠同樣實現Cloudera Hadoop定期打Snapshot快照做定期資料備份，所以我們需要設定ODS桶資料的生命週期一來保障ODS層資料的安全，二來保持資料量的穩定增長。

ODS多版本桶的生命週期設定

Hadoop HDFS檔案系統會有一個垃圾箱回收機制，便於將刪除的資料回收到垃圾桶裡面去，避免某些誤操作刪除一些重要檔案。回收到垃圾桶裡裡面的資料資料，都可以進行恢復。HDFS為每一個使用者建立一個回收站，目錄為/user/使用者名稱/.Trash/被使用者刪除的檔案或目錄，在系統回收站中都有一個週期(fs.trash.interval)，週期過後HDFS會自動將這些資料徹底刪除。而如果是資料湖架構，回收站目錄將被設定在OSS桶上，HDFS不會對這些垃圾檔案定期刪除，於是我們需要設定OSS檔案生命週期（刪除3天前的資料）來定期刪除這些垃圾檔案。

垃圾箱的生命週期設定

4.2.9 日誌管理

日誌服務（Log Service，簡稱 SLS）是針對日誌類資料一站式服務，使用者無需開發就能快捷完成資料採集、消費、投遞以及查詢分析等功能，幫助提升運維、運營效率，建立 DT 時代海量日誌處理能力。鑑於EMR元件日誌的週期性刪除，我們必須把EMR上元件的歷史日誌統一收集在一個地方以便於後續的排查問題，SLS正適合資料湖上多EMR日誌收集這一場景。我們根據EMR元件常用日誌收集了

4.2.10 終端許可權管理

開發人員需要有特定EMR例項的登入許可權，以便於開發操作。

終端許可權管理

終端登入方式如上，透過公司堡壘機，登入大資料VPC下一臺特定linux跳板機，從而去登入EMR的例項，不同角色的操作人員有特定的登入許可權。其中大資料運維可以用統一金鑰對以root賬號登入EMR HADOOP叢集任意一個例項，然後切換到hadoop賬號後，登入EMR叢集中任意一個例項。

4.2.11 元件UI管理

如上所示knox的地址不太容易記憶，我們採用了雲解析DNS的產品。雲解析DNS（Alibaba Cloud DNS）是一種安全、快速、穩定、可擴充套件的權威DNS服務，雲解析DNS為企業和開發者將易於管理識別的域名轉換為計算機用於互連通訊的數字IP地址，從而將使用者的訪問路由到相應的網站或應用伺服器。我們使用別名記錄，將容易記憶的域名指向knox域名很好的解決了這個問題。

4.2.12 監控告警管理

EMR-APM大盤提供EMR叢集使用者，特別是叢集運維人員使用的包含監控叢集、監控服務、監控作業整體執行狀況、排查和解決叢集作業問題的一套完整工具的產品。常用有YARN-HOME圖表，可以看到歷史彈性伸縮例項的情況

EMR APM大盤中YARN-HOME圖表

YARN-QUEUE圖表，可以看到歷史每個佇列的資源使用情況和任務執行情況

EMR APM大盤中YARN-QUEUE圖表

EMR APM大盤中YARN-QUEUE圖表

雲監控（CloudMonitor）是一項針對阿里雲資源和網際網路應用進行監控的服務。雲監控服務可用於收集阿里雲資源或使用者自定義的監控指標，探測服務可用性，以及針對指標設定警報。使您全面瞭解阿里雲上的資源使用情況、業務的執行狀況和健康度，並及時收到異常報警做出響應，保證應用程式順暢執行。我們採用讓資料湖上的多個EMR核心元件告警資訊接入雲監控，讓雲監控統一電話，釘釘，郵件告警給相關責任人。

4.2.13 即席查詢設計

即席查詢能力是資料湖對外輸出能力的考驗。我們自研了統一用數大資料互動式查詢系統，支援HiveServer2和Presto兩種執行引擎。透過限制統一用數的查詢入口，使用者只能提交即席查詢作業在自己部門所在的EMR上。 而Presto所佔用的計算資源會和Hadoop所佔用的YARN計算資源相互影響，我們獨立搭建了一套EMR Presto叢集，單獨為統一用數提供Presto即席查詢服務。

資料湖上即席查詢設計

統一用數在滿足使用者即席查詢基本需求的基礎上，我們還做了很多個性化的需求。

公司工單審批系統接入元件服務狀態監測提醒HiveSQL語法和PrestoSQL語法互轉元資料展示，包括樣本資料展示，血緣關係展示，排程資訊展示，統計資訊等4.2.14 叢集安全組設計

ECS例項的安全組是一種虛擬防火牆，具備狀態檢測和資料包過濾能力，用於在雲端劃分安全域。安全組是一個邏輯上的分組，由同一地域內具有相同安全保護需求並相互信任的例項組成。在資料湖上的所有EMR必須繫結特定的安全組來為外界提供服務。我們為大資料叢集不同例項組分配了不同的安全組。

4.2.15 資料脫敏設計

敏感資料主要包括客戶資料、技術資料、個人資訊等高價值資料，這些資料以不同形式存在於大資料數倉中，敏感資料的洩露會給企業帶來嚴重的經濟和品牌損失。EMR Ranger支援對Hive資料的脫敏處理（Data Masking），對Select的返回結果進行脫敏處理，對使用者遮蔽敏感資訊。但是EMR Ranger該功能只針對HiveServer2的場景，不適用於Presto的場景。

資料湖的敏感欄位掃描按照預設的敏感欄位規則進行掃描，分小時級別的增量掃描和天級別的全量掃描。掃描結果透過Ranger Mask Restful API寫入Ranger的元資料庫，當用戶的即席查詢透過HiveServer2並命中敏感欄位時，該敏感欄位只有預設的前面幾個字元是正常顯示，後面字元全部用x來脫敏處理。

ranger脫敏效果

4.2.16 YARN佇列設計

一個業務EMR主要提供即席查詢服務和DAG排程任務服務，使用者只能把自己的即席查詢和排程任務提交到他所在部門的EMR，且我們可以設定YARN佇列資源把兩種任務所佔資源進行隔離。

4.3 資料湖EMR治理

EMR治理在資料湖治理中具有舉足輕重的作用，EMR治理包括穩定性治理，安全性治理，執行效率治理和成本治理等。

4.3.1 調整EMR預伸縮時間

數倉半夜的T+1任務有時效性要求，我們需要在0點數倉作業開始執行時提前準備好充足的計算資源。由於EMR當前彈性伸縮架構限制，優雅下線會導致縮容和擴容不能並行。

在不影響0點數倉作業的情況下，儘可能推遲預擴容時間定時排程執行EMR OpenAPI，臨時縮短優雅下線引數可以時預擴容時間從22：00延遲到23：30。檢視任務執行監控，儘可能提前恢復彈性伸縮時間檢視EMR APM大盤監控，觀察任務執行時間，提前調整彈性伸縮下限恢復彈性伸縮從10：00提前到6：00。最佳化前後，22：00-10：00平均線上節點從52臺縮減到44臺。4.3.2 更改EMR彈性伸縮策略 彈性伸縮功能可以根據業務需求和策略設定伸縮策略。彈性伸縮開啟並配置完成後，當業務需求增長時EMR會自動增加Task節點以保證計算能力，當業務需求下降時EMR會自動減少Task節點以節約成本。Task節點的付費方式有包年包月，按量例項和競價例項。在全彈性伸縮情況下我們應該儘可能使用競價例項，可以參考阿里雲《EMR彈性低成本離線大資料分析最佳實踐》競價例項優先，按量例項兜底此方案兼顧了叢集計算能力，成本和彈性伸縮的穩定性，儘可能多用競價例項，只有在可用區ECS庫存匱乏的情況下才使用按量例項。彈性伸縮配置可用區遷移不同的可用區庫存不一樣，我們應該儘可能把EMR叢集部署或遷移到庫存充裕的可用區，這樣才能儘可能使用競價例項降低成本彈性策略調整夜間和白天的任務性質不一樣，比如夜間以排程任務為主，使用的是dw佇列，而白天以即席查詢為主，使用的是default佇列。我們可以用排程定時重新整理佇列資源，有效的利用佇列資源從而避免佇列資源浪費。經過上述一系列最佳化後，EMR叢集費用減少1/54.3.3 最佳化EMR雲盤空間 EMR的彈性例項可以使用雲盤，雲盤包括高效雲盤，SSD和ESSDESSD雲盤：基於新一代分散式塊儲存架構的超高效能雲盤產品，結合25GE網路和RDMA技術，單盤可提供高達100萬的隨機讀寫能力和更低的單路時延能力。建議在大型OLTP資料庫、NoSQL資料庫和ELK分散式日誌等場景中使用。SSD雲盤：具備穩定的高隨機讀寫效能、高可靠性的高效能雲盤產品。建議在I/O密集型應用、中小型關係資料庫和NoSQL資料庫等場景中使用。高效雲盤：具備高性價比、中等隨機讀寫效能、高可靠性的雲盤產品。建議在開發與測試業務和系統盤等場景中使用。當前處於價效比考慮我們選擇了ESSD雲盤。並根據檢視彈性節點每日雲盤監控，合理確定彈性伸縮例項資料盤數量和容量。4.3.4 EMR機器組的選擇 在一個業務EMR上，主要提供即席查詢服務和DAG排程任務服務。彈性伸縮比較適合DAG排程任務的場景，而不適合即席查詢的場景，因為即席查詢具有查詢時間短頻次高的特點。基於以上因素考慮，我們往往會預留固定數量的TASK例項，而這些例項使用先付費比較合適。於是我們設定了兩個TASK機器組，先付費TASK機器組和後付費TASK機器組，先付費TASK機器組主要滿足即席查詢的需求，而後付費彈性TASK機器組滿足DAG排程任務的需求4.3.5 EMR成本控制

在我們公司的產品消費分佈中，ECS雲伺服器佔總費用的很大比例，而EMR彈性例項又佔ECS雲伺服器中大多數，所以我們需要關注EMR的費用賬單來有效的控制成本。我們可以使用詳單訂閱服務，呼叫SubscribeBillToOSS匯出阿里雲OSS訂閱賬單詳單資料到大資料Hive表，經過一系列ETL計算出每日每個EMR的費用報表。EMR的費用主要包括包年包月例項費用，按量例項費用，競價例項費用，雲盤費用和預留券抵扣費用。阿里雲提供了給資源打TAG的方式實現分賬，具體實現上，我們透過給EMR叢集打TAG的方式實現多業務叢集之間的分賬管理。可以參考[《單賬戶下企業分賬最佳實踐》]（https://bp.aliyun.com/detail/168)。透過報表我們發現EMR-A 30臺機器費用和EMR-B 50臺機器的費用不成比例，透過分析費用組成我們發現EMR-A處於資源匱乏可用區，用了大量的按量例項和預留例項券，而EMR-B處於資源富餘可用區，用了大量的競價例項，按量例項+預留券費用是遠高於競價例項的。另外我們還計算了EMR中每個SQL的費用來督促業務最佳化大SQL和下線無用SQL。我們拉取ResourceManger裡的MemorySeconds指標，計算公式為SQL費用=MemorySeconds Of SQL/Total MemorySeconds Of EMR*EMR總費用。

4.3.6 購買RI預留抵扣券

預留例項券是一種抵扣券，可以抵扣按量付費例項（不含搶佔式例項）的賬單，也能夠預留例項資源。相比包年包月例項，預留例項券與按量付費例項這種組合模式可以兼顧靈活性和成本。預留例項券支援地域和可用區。地域級預留例項券支援在指定地域中可以跨可用區匹配按量付費例項。可用區級預留例項券只可匹配同一可用區中的按量付費例項。預留例項券支援三種付款型別：全預付、部分預付和0預付。不同付款型別對應不同計費標準。由於我們使用了競價例項優先，按量例項兜底的彈性策略，我們購買了一部分跨可用區0預付的預留例項券用來抵扣彈性伸縮的按量例項。下圖是預留例項券每個賬期的使用情況。

可以看到，有兩款ECS規格的預留例項券的使用率分別是0和百分之六十二點五，沒有達到預期的百分之百。其原因是後期資源從按量切換到搶佔式例項，而預留例項券是不支援搶佔式例項的。整體上使用預留例項券之後，相比較按量付費成本節省了百分之四十左右。更多詳情可以參考《RI和SCU全鏈路使用實踐》。

彈性保障

彈性保障為靈活付費的日常彈性資源需求提供百分百的資源確定性保障。透過彈性保障，只需要支付一筆較低的保障費用，即可換取固定週期（支援1個月~5年）的資源確定性保障。購買彈性保障時設定可用區、例項規格等屬性，系統會以私有池的方式預留屬性相匹配的資源。在建立按量付費例項時選擇使用私有池的容量，即可保證百分百建立成功。我們知道雙十一前後一段時間阿里雲會出現資源緊張的情況，而公司的一些T+1任務屬於極度重要任務，為了低成本保障雙十一期間EMR彈性資源，我們為資料湖上一些重要的EMR綁定了彈性保障私有池來保障這些重要EMR上的彈性資源在此期間一定能夠得到。

4.4 資料湖OSS治理

上面介紹了資料湖上執行引擎EMR的治理，下面我們介紹資料湖的儲存介質OSS的治理。

4.4.1 數倉ODS多版本桶治理

版本控制是針對OSS儲存空間（Bucket）級別的資料保護功能。開啟版本控制後，針對資料的覆蓋和刪除操作將會以歷史版本的形式儲存下來。您在錯誤覆蓋或者刪除物件（Object）後，能夠將Bucket中儲存的Object恢復至任意時刻的歷史版本。我們在自建Cloudera Hadoop中為了保障資料的安全使用了HDFS Snapshot的功能。在資料湖架構中，我們使用OSS自帶的版本控制功能來保障資料湖上資料的安全。OSS支援設定生命週期（Lifecycle）規則，自動刪除過期的檔案和碎片，或將到期的檔案轉儲為低頻或歸檔儲存型別，從而節省儲存費用。我們也需要設定多版本桶的生命週期來節約成本，保留當前版本且自動刪除3天后的歷史版本。

4.4.2 數倉日誌桶治理

從下圖中可以看到9月28日之前標準儲存線性增長，9月28日設定了冷儲存生命週期，冷儲存線性增長，標準儲存基本不變，而標準型單價0.12元/GB/月，歸檔型單價0.033元/GB/月，330T資料轉成冷儲存節約百分之七十二點五費用。

4.4.4 監控桶內物件

物件儲存OSS支援儲存空間清單功能，可定期將Bucket內檔案（Object）的資訊匯出到指定Bucket，幫助瞭解Object的狀態，簡化並加速工作流和大資料作業任務等。Bucket清單功能以周為單位將Bucket內的Object進行掃描，掃描完成後會生成CSV格式的清單報告，並存儲到指定的Bucket內。在清單報告中可以有選擇地匯出指定物件的元資料資訊，如檔案大小、加密狀態等。我們透過設定儲存空間清單匯出CSV格式的檔案放入Hive表中，定期出報表來監控桶內物件的變化情況，找出異常增長情況並加以治理。

5. 阿里雲第二代資料湖

第一代資料湖的執行引擎是EMR儲存介質是OSS，當我們公司引入Dataphin資料中臺時，他的執行引擎和儲存是Maxcompute，和我們當前的數倉執行引擎EMR是兩套異構的執行引擎，帶來的問題如下

儲存冗餘EMR的儲存資源放在OSS物件儲存上，MaxCompute的儲存資源放在盤古上，造成儲存資源的冗餘。元資料不統一EMR的元資料統一放在外接的RDS資料庫上，MaxCompute的元資料放在MC元資料庫裡，兩者元資料不統一造成無法共享。使用者許可權不統一EMR的使用者許可權體系是用openldap和ranger構建，而MaxCompute的使用者許可權體系是用MaxCompute自帶的使用者許可權體系。湖倉計算不能自由流動根據任務的性質和任務計費規則，高吞吐高複雜度低併發的任務適合在EMR中跑，而低吞吐低複雜度高併發的任務適合在MaxCompute中跑；另外我們可以把雙十一的計算資源放在MaxCompute上，解決EMR資源不足的問題。而當前情況不能自由選擇執行引擎阿里雲提供了兩套湖倉一體方案，其中基於HDFS儲存的方案，透過建立外部專案將Hive元資料對映到MaxCompute（相關最佳實踐可以參考 https://bp.aliyun.com/detail/169 ）。我們採用另外一種基於資料湖構建DLF（DataLake Formation）實現湖倉一體的資料湖方案。將我們EMR的元資料和MaxCompute元資料遷移到DLF，底層使用OSS作統一儲存，打通EMR構建的資料湖和MaxCompute構建的資料倉庫兩套體系，讓資料和計算在湖和倉之間自由流動，真正實現湖倉一體。即湖倉一體的資料湖本質：統一的儲存，統一的元資料和自由接入執行引擎。 5.1 阿里雲資料湖構建 阿里雲資料湖構建（Data Lake Formation，DLF）是一款全託管的快速幫助使用者構建雲上資料湖的服務，產品提供了雲上資料湖統一的許可權管理、資料湖元資料管理和元資料自動抽取能力。統一資料湖儲存阿里雲資料湖構建使用阿里雲物件儲存（Object Storage Service，OSS）作為雲上資料湖的統一儲存，在雲上可以使用多種計算引擎面向不同的大資料計算場景，開源大資料E-MapReduce，實時計算，MaxCompute互動式分析（Hologres），機器學習PAI等，但您可以使用統一的資料湖儲存方案避免資料同步產生的複雜度和運維成本。多樣化入湖模板阿里雲資料湖構建可以將多種資料來源資料抽取到資料湖中，目前支援的包括關係型資料庫(MySQL)、阿里雲日誌服務（SLS）、阿里雲表格儲存（OTS）、阿里雲物件服務（OSS）和Kafka等，使用者可以指定儲存格式，提高計算和儲存效率。資料湖元資料管理使用者可以定義資料湖元資料的格式，進行集中和統一管理，保證資料質量。 5.2 阿里雲資料湖解決方案 我們主要使用阿里雲資料湖構建產品的統一元資料管理功能和統一使用者許可權管理功能。如圖架構EMR和MaxCompute共享資料湖DLF的元資料，使用者許可權和許可權管理功能。 基於DLF的資料湖系統架構 資料湖的資料流圖如下資料流圖EMR ETLX把業務RDS和業務OSS的資料抽取到資料湖中，即ODS層資料落資料湖。Dataphin資料中臺對資料湖的資料進行維度建模（建模中間表包括事實邏輯表和維度邏輯表用MaxCompute內表，不落入資料湖），最後維度建模結果產生在CDM層或者ADS層資料湖上。EMR或其他執行引擎對資料湖上的ADS層資料進行即席查詢分析或者排程使用。

作者：程俊傑