作者:程俊傑,目前在數禾科技大資料部擔任大資料架構師的職位,負責阿裡雲平台産品的架構開發和維護,曾在1号店、拍拍貸、2345從事大資料平台架構方面的工作。
目錄
1. 數禾科技
2. 雲上自建CDH
3. 雲上混合架構
4. 阿裡雲第一代資料湖
4.1. 什麼是資料湖
4.2. 阿裡雲資料湖設計
4.2.1. 阿裡雲資料湖整體架構
4.2.2. 統一存儲和中繼資料管理
4.2.3. 多EMR多OSS桶設計
4.2.4. 分布式排程系統設計
4.2.5. 使用者權限系統設計
4.2.6. EMR彈性伸縮設計
4.2.7. 負載均衡管理
4.2.8. OSS桶生命周期管理
4.2.9. 日志管理
4.2.10. 終端權限管理
4.2.11. 元件UI管理
4.2.12. 監控告警管理
4.2.13. 即席查詢設計
4.2.14. 叢集安全組設計
4.2.15. 資料脫敏設計
4.2.16. YARN隊列設計
4.3. 資料湖EMR治理
4.3.1. 調整EMR預伸縮時間
4.3.2. 更改EMR彈性伸縮政策
4.3.3. 優化EMR雲盤空間
4.3.4. EMR機器組的選擇
4.3.5. EMR成本控制
4.3.6. 購買RI預留抵扣券
4.3.7. 彈性保障
4.4. 資料湖OSS治理
4.4.1. 數倉ODS多版本桶治理
4.4.2. 數倉日志桶治理
4.4.3. 數倉桶和集市桶治理
4.4.4. 監控桶内對象
5. 阿裡雲第二代資料湖
5.1. 阿裡雲資料湖建構
5.2. 阿裡雲資料湖解決方案
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核心元件告警資訊接入雲監控,讓雲監控統一電話,釘釘,郵件告警給相關責任人。
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隊列設計
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層資料進行即席查詢分析或者排程使用。
歡迎試用
對資料湖建構感興趣客戶的都可以測試,測試加入釘釘群(如下),并在群内@揚流