簡介: 上海數禾信息科技大數據平臺負責人 程俊杰:MaxCompute+DLF+EMR的湖倉一體架構實現了統一元數據管理 ,統一存儲管理,統一權限管理 ,真正實現湖倉計算的自由流動,為企業業務高速發展助力。
程俊杰 上海數禾信息科技大數據平臺負責人
通過本次分享,與大家介紹湖倉一體在上海數禾信息科技有限公司演進的四個階段,包括每個階段大數據平臺的架構以及演進的原因。并著重介紹基于MaxCompute+Data Lake Formation+E-MapReduce的湖倉一體架構,其中包括基于湖倉一體的大數據平臺架構,實現此架構面臨的挑戰以及落地后帶來的收益。最后介紹湖倉一體的未來規劃。希望可以借此分享幫助其他企業的大數據平臺快速成長,同時為企業的高速發展助力。
一、公司業務
上海數禾信息科技有限公司,簡稱數禾科技,成立于2015年,目前C輪融資,主要產品有“還唄”和“拿鐵智投”。
目前注冊用戶1億多,業務涵蓋信貸,理財和電商。產品包括智能營銷,智能風控,智能運營,智能客服。和100多家金融機構進行合作,包括銀行、消金、信托、基金、保險。
數禾科技的使命是讓人人享有金融服務最優解,公司的愿景是做陪伴用戶一生的智能金融家。
二、湖倉一體架構的演進
· 湖倉一體架構演進的時間軸
數禾科技大數據平臺的湖倉一體架構演進分為下面四個階段:
2015-2018.11,云上自建CDH集群。
在公司成立之初,數禾在云上購買了云服務器,并在上面搭建了CDH集群,數倉主要使用Hive,一開始數據量不大,選擇了本地SSD磁盤,HDFS存儲選擇了三副本存儲。
2018.12-2020.8,CDH+EMR混合云架構。
由于數禾業務的飛速發展,在計算上,為了擴展CDH集群的計算能力,修改了EMR Hive的源代碼,使不同版本的EMR Hive和CDH Hive共享CDH Hive元數據,實現了EMR和CDH的計算流動,緩解了CDH的計算資源壓力。在存儲上,把部分HDFS上的冷數據,比如日志,備份數據等保存在對象存儲上,使CDH和EMR通過外表共享這些數據,大大減輕了CDH存儲的成本壓力。
2020.9-2021.8,OSS+EMR生態的云原生數據湖。
在這種架構下為每個部門搭建了屬于他們自己的EMR集群。在計算上,多個EMR共享一套Hive元數據,且各個EMR各司其職完成自己的任務,完全做到不同角色EMR之間的計算流動。在存儲上,多個EMR共享OSS對象存儲,且每個EMR綁定自己的RAM角色做到EMR訪問OSS對象存儲的權限控制。
2021.8-至今,基于MC+DLF+EMR的湖倉一體架構。
自從數禾購買了阿里云數據中臺產品之后,該產品使用MaxCompute作為計算引擎,對上個階段的云原生數據湖架構兼容性帶來一些挑戰。在和阿里云專家團隊進行了幾輪充分討論后,落地了基于MaxCompute+DLF+EMR的湖倉一體架構。 MaxCompute 多項目與多EMR集群共享DLF元數據和數據湖存儲OSS,真正做到EMR和MaxCompute之間計算流動。
· 湖倉一體演進中大數據架構以及演進原因
(1) 云上自建CDH集群
在六年前,與大多數公司創立之初一樣,數禾選擇了在云上購買服務器并自建CDH集群的大數據解決方案。
數據源分為離線數據源,存儲在RDS和對象存儲上,實時數據源為埋點日志Kafka數據。 離線數據使用Sqoop組件抽取,實時數據使用Flume組件抽取 ,抽取后的實時和離線數據統一保存在CDH的HDFS存儲上。
計算層一開始使用Hive,后面使用了執行更加高效的計算引擎Spark和TEZ。
應用層為報表系統,統一用數交互式查詢,Jupyter機器學習和RDS業務庫。統一用數交互式查詢是數禾自研的一套即席查詢交互式查詢系統,集成了工單審批,權限控制,數據樣本和血緣展示等功能。RDS業務庫是為了凌晨讓數倉加工產生的應用層數據寫入,白天讓業務系統進行調用。
(2) 第二階段:CDH+EMR混合云
隨著公司業務的飛速發展,業務所用計算資源消耗越來越大,云上自建CDH集群也出現了一系列瓶頸:
自建CDH集群擴展性差。操作難度高且有一定操作風險。且操作周期長,從一開始購買機器,添加節點到集群,分配角色,分發配置,可能還需要擇機重啟依賴組件或集群,整個過程少則半天,多則一天。
晝夜資源使用不均,導致資源無法合理使用。從半夜的業務系統的日切結束,數倉開始抽取并加工數據,使用大量的計算資源,且早上某些核心數據產出有時效性要求。如果半夜發生事故導致任務延遲,還需要加速跑保證早上數據按時產出,這樣需要額外更多的資源儲備。而白天集群大部分時間只是供業務人員即席查詢,分析,建模使用,需要的計算資源較少。由于沒有集群彈性擴縮容,需要全天使集群資源保持一個較高的水位,造成資源的浪費。
CDH集群使用本地SSD磁盤,存儲費用高。一開始數據量較少,為了提高CDH磁盤IO性能選擇了SSD磁盤,且選擇了HDFS三副本保存,后面隨著數據量的逐漸增多,SSD磁盤消耗的成本越來越高。且計算和存儲不分離,計算資源的增多也造成存儲資源的相應增加。
CDH組件的壓力日益變大。隨著集群任務的逐漸增多,CDH的ResourceManager和HiveServer2組件壓力逐漸增加,只能采用Master節點升配,JVM配置調整,重啟組件,加強組件監控告警的方式解決。但還是存在很大的事故風險。
為了擴展CDH集群的計算能力,提出了CDH+EMR混合云的大數據架構。
在計算上,一方面根據各個業務場景搭建了多套獨立的EMR集群;另一方面,為擴展CDH集群的計算能力,修改了EMR 較高Hive版本的Hive Metastore源代碼,使之可以兼容CDH 較低版本Hive的元數據,這樣CDH和EMR Hive統一使用一套CDH Hive元數據,用EMR的彈性伸縮能力擴展了CDH計算資源,大大緩解了CDH的計算資源壓力,且彈性伸縮能力保證了計算資源的有效利用。
在存儲上,把部分CDH磁盤上的冷數據,比如日志,備份數據以Hive 外表的方式保存在對象存儲上,使CDH和EMR可以共享這些數據,由于對象存儲的費用成本大大低于SSD磁盤存儲,因此大大減輕了CDH磁盤成本壓力。
(3) 第三階段:OSS+EMR生態的云原生數據湖
隨著員工日益增多,組織架構日趨復雜,CDH+EMR的混合云架構不能滿足需求:
元數據管理不完全統一,存在CDH和EMR多套元數據。
用戶管理和權限管理不統一,使用Hive自帶的用戶權限管理系統,CDH和EMR多套元數據也帶來了多套用戶權限管理體系。
HDFS和對象存儲上的數據有冗余。
部門計算資源不能有效隔離。雖然Yarn隊列能隔離內存資源,但不能徹底隔離所有資源,比如CPU資源,IO資源和Network資源。
為了解決上面問題,我們提出OSS+EMR生態的云原生數據湖架構。
為了方便管理VPC資源,數禾根據業務單元劃分了多個VPC,其中包括業務VPC和大數據VPC。
業務數據保存在業務VPC下,包括資信數據放在業務VPC的OSS對象存儲上,埋點日志數據放在業務VPC的云Kafka上,業務數據放在業務VPC的RDS數據庫上,還有一些第三方存儲包括Mongo,Oracle數據也放在業務VPC下。
大數據VPC上的EMR集群,根據EMR的職能分為數據同步集群,核心數倉集群,標簽集群和給每個部門使用的業務集群。數據同步集群利用Sqoop組件把業務VPC下的RDS業務數據和OSS業務數據抽取到數據湖存儲OSS中;核心數倉集群對ODS層數據進行數據加工,放到數倉層中;標簽集群對數倉層數據進行加工,產出離線標簽;而各個部門的業務集群對數倉層數據加工,產生各自的集市數據。每個EMR集群各司其職,完成整個分層數倉的功能。
另外,在EMR訪問權限上,每個EMR根據職能綁定各自的RAM角色,訪問各自的OSS桶數據;在用戶管理上,單獨搭建了一個EMR LDAP集群,統一保存所有EMR Hive用戶賬號,且此LDAP集群T+1和公司的Active Directory同步,加入新員工賬號并刪除離職員工賬號;在權限管理上,使用統一的Ranger權限管理系統,把所有EMR Ranger元數據保存在一個元數據庫里管理;所有的EMR Hive元數據也保存在統一的元數據庫里;調度系統使用Airflow,搭建了高可用的Airflow Master架構,并把Airflow Worker部署在每個EMR集群的Gateway節點上方便調度任務直接提交到EMR集群;使用了JindoFS組件對數據湖的存儲和計算進行加速,這里使用了JindoFS的Cache模式。
三、 基于 MaxCompute+Data Lake Formation+E-MapReduce的湖倉一體架構
· OSS+EMR生態的云原生數據湖架構的瓶頸
數禾引入MaxCompute作為計算引擎的數據中臺產品,給原來的OSS+EMR生態的云原生數據湖架構帶來很大的挑戰:
異構計算引擎元數據管理不統一,MaxCompute的元數據保存在MaxCompute元倉項目上,而EMR的元數據保存在外置RDS數據庫上。
異構計算引擎存儲管理不統一,MaxCompute表數據存儲在MaxCompute內部存儲上,而EMR的表數據存儲在OSS對象存儲上。
異構計算引擎權限管理不統一,MaxCompute表的訪問權限由MaxCompute內部權限管理系統控制,而EMR的Hive表的訪問權限由Ranger控制。
湖倉計算不能自由流動,由于以上三點原因,EMR創建的表不能馬上被MaxCompute訪問,而MaxCompute中創建的表也不能馬上被EMR訪問,當前必須通過創建MaxCompute和EMR的OSS外表才能做到兩邊引擎的數據互訪。
· 基于MaxCompute+DLF+EMR的湖倉一體架構
在和阿里云專家團隊進行了好幾輪充分討論后,提出基于MaxCompute+DLF+EMR的湖倉一體架構。
數據湖構建DLF(Data Lake Formation)是一款全托管構建云上數據湖服務的產品,產品提供了云上數據湖統一的權限管理、數據湖元數據管理和元數據自動抽取能力。
從架構上看,底層還是采用數據湖存儲OSS,中間是元數據管理+湖加速 ,元數據管理使用DLF數據湖構建,包括元數據管理,數據血緣管理和數據權限管理。湖加速由JindoFS+MaxCompute數據湖加速實現,包括智能Cache,冷熱分層,本地緩存加速來實現計算和存儲的加速。 計算引擎層,數據湖中的多EMR集群和數據倉庫中的多MaxCompute項目,借助統一的元數據管理+湖加速的能力,兩者實現元數據的統一和計算的自由流動。
從數據流上看,首先數據同步EMR抽取業務RDS和業務OSS數據到數據湖,阿里云數據中臺產品綁定的MaxCompute的ODS貼源層項目,對數據湖中的ODS數據進行數據清洗,脫敏,統一命名,精度清洗等操作。CDM數倉層項目主要提供OneData規范建模的功能。這里需要強調一下,由于阿里云數據中臺產品的設計,這層的數據主要以內表的方式落在MaxCompute內部,不落在數據湖上,這里用灰色表示。ADS應用層項目主要用于各個業務方基于CDM層數據建立各自的數據集市,可以直接對數據湖進行讀取和寫入。VDM沙箱層項目直接向終端用戶提供ADS層和CDM層數據的查詢,分析功能。
這樣,數據湖上的統一用數交互式查詢可以通過即席查詢EMR對數據湖的數據進行查詢和分析,Jupyter也可以通過機器學習EMR對數據湖中的數據進行模型訓練和推理。
· 實現MaxCompute+DLF+EMR架構面臨的挑戰
當前數禾線上25個EMR處于生產環境,任何事故將導致EMR產出延遲造成公司的資損。阿里云DLF團隊為數禾設計了一整套完整的Hive Metastore切換到DLF的解決方案,共分為五個階段,四個切換過程:
METASTORE_ONLY,DLF切換前,讀寫Hive Metastore。
METASTORE_DLF_FAILURE,這個階段首先讀寫Hive Metastore, 然后寫入DLF允許失敗。
METASTORE_DLF_SUCCESS,這個階段首先讀寫Hive Metastore,然后寫入DLF不允許失敗。
DLF_METASTORE_SUCCESS,這個階段首先讀寫DLF,然后寫入Hive Metastore不允許失敗。
DLF_ONLY,最終切換完成后只讀寫DLF,完全拋棄Hive Metastore;
每個切換階段,25個EMR集群分為不重要集群,非重要業務集群,重要業務集群和核心集群,按順序進行灰度切換。且每個EMR切換后都用自動化Hive全場景單元測試腳本進行驗證,保證切換結果正確。
· 基于MaxCompute+DLF+EMR湖倉一體架構的收益
統一元數據管理,統一把EMR元數據和MaxCompute元數據保存在DLF中。
統一存儲管理,統一把EMR的數據和MaxCompute外表數據保存在數據湖OSS中。
統一權限管理,統一把EMR權限和MaxCompute外表訪問權限收斂在DLF中。
湖倉計算自由流動,基于以上特點,EMR中創建的表,MaxCompute能馬上訪問;反之亦然,真正做到湖倉計算自動流動。
四、湖倉一體的未來規劃
未來湖倉一體會把DLF元數據管理功能升級為統一的元數據管理平臺,包括統一的元數據倉庫和統一的元數據服務。
可以注冊數據湖EMR的元數據到元數據管理平臺,數據湖以E-MapReduce作為執行引擎,且用JindoFS作為計算和存儲的加速模塊,以OSS對象存儲保存;可以注冊數據倉庫MaxCompute的元數據到元數據管理平臺,同時支持MaxCompute的內表和外表。數據倉庫以MaxCompute為計算引擎,以智能cache作為計算和存儲的加速,數據既可以落在OSS存儲也可以落在MaxCompute內部;也可以同步其他的聯邦數據源到元數據管理平臺,包括Hologres交互式分析,RDS數據庫,ElasticSearch搜索和分析引擎,和云Hbase等數據源。這樣可以實現多種數據源元數據的統一,計算和數據的自由流動。
在應用層上使用湖倉統一開發管理平臺對所有接入統一元數據管理平臺的云產品進行開發和管理,功能包括湖倉數據集成和開發模塊,既可以集成多數據源,也可以做免數據傳輸的多數據源聯邦查詢;湖倉血緣關系模塊,管理所有數據源的大血緣關系;湖倉權限管理模塊,管理所有數據源的用戶訪問權限;湖倉數據管理和治理模塊,包括多數據源表字段的命名規范,數據有效性驗證等功能。
更多關于大數據計算、云數據倉庫技術交流,歡迎掃碼查看咨詢。
