簡介： 數禾科技從成立伊始就組建了大數據團隊并搭建了大數據平臺。并在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 和可視化	機器學習、預測分析、數據發現和分析

數據湖解決方案的基本要素

• 數據移動

數據湖允許您導入任何數量的實時獲得的數據。您可以從多個來源收集數據，并以其原始形式將其移入到數據湖中。此過程允許您擴展到任何規模的數據，同時節省定義數據結構、Schema 和轉換的時間。

• 安全地存儲和編目數據

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

• 分析

數據湖允許組織中的各種角色（如數據科學家、數據開發人員和業務分析師）通過各自選擇的分析工具和框架來訪問數據。這包括 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/5

  4.3.3 優化EMR云盤空間

  EMR的彈性實例可以使用云盤，云盤包括高效云盤，SSD和ESSD

• ESSD云盤：基于新一代分布式塊存儲架構的超高性能云盤產品，結合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.3數倉桶和集市桶治理

數據湖架構下EMR的HDFS回收站目錄被設置在OSS桶上，HDFS不會對這些垃圾文件定期刪除，于是我們需要設置HDFS垃圾箱的生命周期來定期刪除垃圾箱內的這些垃圾文件。

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層數據進行即席查詢分析或者調度使用。

作者：程俊杰

原文鏈接

本文為阿里云原創內容，未經允許不得轉載

?

總結

以上是生活随笔為你收集整理的数禾云上数据湖最佳实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。