數(shù)據(jù)湖實踐 | 百草味基于“ EMR+Databricks+DLF ”構(gòu)建云上數(shù)據(jù)湖的最佳實踐
作者
劉凱廷 ?百草味-信息數(shù)據(jù)中心負(fù)責(zé)人??
朱齊天 ?百草味-信息數(shù)據(jù)中心-數(shù)據(jù)部負(fù)責(zé)人
百草味是以休閑食品研發(fā)、加工、生產(chǎn)、貿(mào)易、倉儲、物流為主體，集互聯(lián)網(wǎng)商務(wù)經(jīng)營模式、新零售為一體的全渠道品牌和綜合型品牌。百草味以“讓更多的人吃上放心健康的食品”為使命，以“食品安全布道者，行業(yè)模式探索者”的角色，專注休閑食品，在全球優(yōu)質(zhì)原產(chǎn)地探尋美味，于全鏈路探索更健康的休閑方式與更好的用戶體驗，在全渠道無限觸達消費者，聚焦消費者。
百草味不斷探索產(chǎn)品解決方案，完善涵蓋堅果、果干、肉類、糕點、糖果等全品類休閑食品供應(yīng)鏈，目前擁有全品類零食產(chǎn)品1000+SKU；持續(xù)革新零售模式，實現(xiàn)電商、商超、新零售、流通、進出口全網(wǎng)覆蓋，為1億多用戶和更多消費者帶來更好購物體驗。此外，百草味打通了物流體系，建立起覆蓋全國華東、華北、華中、華南、東北五大區(qū)域的十七大倉儲物流中心，樹立起世界領(lǐng)先的現(xiàn)代智能化物流標(biāo)桿。未來，百草味將持續(xù)耕耘全品類休閑食品，在強大的研發(fā)、供應(yīng)鏈、物流鏈以及新零售基礎(chǔ)上，領(lǐng)跑中國休閑食品走向全新格局，實現(xiàn)“成為受全世界尊重的食品企業(yè)”愿景。
在上云之前，百草味的大數(shù)據(jù)部署在 IDC 機房，基于 CDH 自建的 Hadoop 集群。選擇采用了較為通用的 Hadoop 架構(gòu)和組件，基本能滿足數(shù)倉常規(guī)的數(shù)據(jù)匯聚、計算和使用需求。架構(gòu)圖如下：
但隨著業(yè)務(wù)發(fā)展的需要，對接的第三方系統(tǒng)越來越多，不同的場景對數(shù)據(jù)時效性和精準(zhǔn)性要求差異較大，比如：日經(jīng)營數(shù)據(jù)T+1的延遲業(yè)務(wù)部門是接受的，但是輸送給 CRM 的用戶交易信息就需要秒級的響應(yīng)以滿足用戶登記和積分的變更。不同業(yè)務(wù)的差異性以及實時性的要求都對我們這個大數(shù)據(jù)平臺的靈活性和穩(wěn)定性帶來了新的挑戰(zhàn)。
為了滿足業(yè)務(wù)的需求，整個團隊一直處于疲于奔命的狀態(tài)。為了提升系統(tǒng)的靈活性和穩(wěn)定性，以及的研發(fā)和運維效率，我們首先梳理當(dāng)前這套 IDC 自建 Hadoop 平臺的主要痛點問題：
1.運維困難、成本高
升級和擴容周期長、操作繁瑣、風(fēng)險大：需要到現(xiàn)場進行擴容操作，有選擇性的停掉 DataNode 節(jié)點，加上磁盤，循環(huán)操作后 Rebalance，HDFS 的一次 Rebalance 耗時較久，頻繁的元數(shù)據(jù)變更對 NameNode 也會產(chǎn)生較大壓力。
運維成本高：集群本身的核心服務(wù)都是要滿足 HA，但是像開源 Presto 這種組件是有單點故障的，很多情況下需要額外寫監(jiān)控程序頻繁監(jiān)控機器進程來做補救操作。
開源組件多，相互之間的兼容和管理越來越復(fù)雜，組件升級和改動對系統(tǒng)穩(wěn)定性帶來較大風(fēng)險
2. 數(shù)據(jù)開發(fā)、運維難度大，任務(wù)穩(wěn)定性差
開發(fā)難度比較高：組件越來越多，且組件間依賴關(guān)系復(fù)雜，大部分開源的開發(fā)組件都支持SQL，這是非常友好且靈活的，很多情況下，復(fù)雜的業(yè)務(wù)邏輯需要上千行 SQL，給代碼的開發(fā)和維護帶來很大挑戰(zhàn)。
??
問題排查效率低：由于技術(shù)和工具的儲備不夠，線上問題排查非常麻煩。比如排查一個數(shù)據(jù)傾斜就需要花半天的時間，再比如由于上游落盤文件數(shù)多，導(dǎo)致下游一個任務(wù)數(shù)萬個 MapTask 產(chǎn)生，這都給任務(wù)的穩(wěn)定性和出現(xiàn)問題后的排查效率帶來很大的困難。
計算任務(wù)穩(wěn)定性差，由于機房的網(wǎng)絡(luò)抖動、磁盤故障等問題會導(dǎo)致流任務(wù)出現(xiàn)報錯、反壓等情況而經(jīng)常掛掉。
3. 缺乏健全的安全體系
只有機器級別的賬號權(quán)限，用戶登錄機器后服務(wù)和數(shù)據(jù)的安全性不可控。對一些常用的權(quán)限組件進行了嘗試，kerberos、ranger 等。但學(xué)習(xí)和接入成本較高，始終沒有投產(chǎn)。
數(shù)據(jù)權(quán)限控制上也沒有很好的能夠精細(xì)到行列級別控制的方案，無法滿足公司對數(shù)據(jù)安全的要求。
4.?IDC 機房的安全性不滿足集團的合規(guī)要求
IDC 機房自身的安全性和穩(wěn)定性得不到保障。
沒有很好的容災(zāi)方案，一旦機房出現(xiàn)問題，對企業(yè)的業(yè)務(wù)和數(shù)據(jù)都將是致命的打擊。
由于以上的種種痛點，尤其是 IDC 機房在安全和容災(zāi)方面的風(fēng)險受到集團合規(guī)部門的很大挑戰(zhàn)，所以我們決定遷移到云廠商提供的更安全穩(wěn)定的平臺上。
架構(gòu)演進目標(biāo)
基于上文分析的一些痛點和問題，我們將這次上云架構(gòu)演進的目標(biāo)確定如下：
通過上云解決基礎(chǔ)設(shè)施和數(shù)據(jù)合規(guī)性風(fēng)險（安全、穩(wěn)定）。
簡化架構(gòu)，縮短數(shù)據(jù)鏈路，降低復(fù)雜度，提升開發(fā)和運維效率。
提高系統(tǒng)可擴展性，在資源擴縮容、組件升級等方面有完善的方案。
引進權(quán)限體系，提升數(shù)據(jù)安全性。
架構(gòu)設(shè)計原則
基于我們的目標(biāo)及企業(yè)自身的業(yè)務(wù)和技術(shù)環(huán)境，我們設(shè)定了以下的一些架構(gòu)原則：
核心模塊使用開源技術(shù)：自主可控，不被廠商技術(shù)綁定，同時沉淀團隊技術(shù)實力。
使用全托管服務(wù)：將繁重的運維工作交給廠商解決，我們可以專注在業(yè)務(wù)上。
使用批流一體降低鏈路和開發(fā)復(fù)雜度：盡量使用統(tǒng)一的引擎來實現(xiàn)數(shù)據(jù)鏈路和業(yè)務(wù)邏輯，降低開發(fā)和運維成本，提高效率和技術(shù)深度。
采用存算分離架構(gòu)：同時擁有更好的數(shù)據(jù)安全性和資源的擴展性。
方案選型
在云廠商以及大數(shù)據(jù)平臺方案的選型上，我們主要對比了 AWS 和阿里云提供的數(shù)據(jù)湖方案。
方案一：AWS 數(shù)據(jù)湖方案
AWS 有較為成熟完善的數(shù)據(jù)湖方案，基于 S3 做統(tǒng)一數(shù)據(jù)湖存儲，Lake Formation 元數(shù)據(jù)管理和權(quán)限控制，Glue 做數(shù)據(jù) ETL，Athena 和 Redshift 做數(shù)據(jù)計算和分析。組件間耦合度很低，一個組件專干一個事情，很好的保證了靈活性和性能。
其主要的問題是，相關(guān)的產(chǎn)品都是自研的。不滿足我們使用開源引擎和不被綁定的原則。提供的 EMR 的產(chǎn)品盡管是開源的，但是是半托管的服務(wù)，運維的工作基本還是需要我們自己來承擔(dān)。
?? ?
方案二：阿里云云原生數(shù)據(jù)湖方案
阿里云的數(shù)據(jù)湖方案，在基于 OSS 的統(tǒng)一存儲之上，提供了開源和自研兩條路線。自研是以 MaxCompute 為主的數(shù)倉引擎。開源是包含了 EMR 的半托管模式和DDI/CDP/Starburst 等全托管模式。除此之外，有數(shù)據(jù)湖構(gòu)建 DLF 這樣的產(chǎn)品幫助企業(yè)快速構(gòu)建和管理數(shù)據(jù)湖，結(jié)合數(shù)據(jù)湖加速相關(guān)的技術(shù)組件，在性能上也有所保障。阿里云的這套數(shù)據(jù)湖方案整體上還是比較完善的。
???
選型結(jié)論
結(jié)合我們這次架構(gòu)演進的目標(biāo)和要遵循的一些原則，我們最終決定基于阿里云的數(shù)據(jù)湖方案來構(gòu)建百草味的新一代云上大數(shù)據(jù)平臺。一方面在存算分離、開源體系和全托管模式等架構(gòu)上能夠滿足我們的訴求；另一方面，我們公司其他的很多業(yè)務(wù)也發(fā)生在阿里云生態(tài)里，未來的整合會更方便。
結(jié)合百草味具體的業(yè)務(wù)和數(shù)據(jù)系統(tǒng)的現(xiàn)狀，我們基于阿里云的數(shù)據(jù)湖整體架構(gòu)最終設(shè)計如下：
? ?
統(tǒng)一存儲：對象存儲 OSS
在存儲上，我們沒有繼續(xù)使用 HDFS，一方面是 HDFS 會影響集群的擴縮容效率，另一方面 HDFS 的 Namenode 的高可用和穩(wěn)定性方面都給運維帶來很大的挑戰(zhàn)。因此我們選擇了阿里云上的對象存儲 OSS 作為數(shù)據(jù)湖的統(tǒng)一存儲。
阿里云對象存儲 OSS 是數(shù)據(jù)湖的統(tǒng)一存儲層，它有12個9的可靠性，可存儲任意規(guī)模的數(shù)據(jù)，可對接業(yè)務(wù)應(yīng)用、各類計算分析平臺，非常適合用來存儲企業(yè)大規(guī)模和快速增長的數(shù)據(jù)。相對于 HDFS 來說，OSS 可以存儲海量文件，并且通過冷熱分層、高密度存儲、 高壓縮率算法等先進技術(shù)極大降低單位存儲成本。同時 OSS 對 Hadoop 生態(tài)友好，基于 JindoFS 的協(xié)議轉(zhuǎn)換能力，可以無縫對接阿里云各種大數(shù)據(jù)計算引擎。
數(shù)據(jù)湖構(gòu)建與管理：數(shù)據(jù)湖構(gòu)建 DLF
在實現(xiàn)了存儲層的統(tǒng)一之后，統(tǒng)一的數(shù)據(jù)管理和權(quán)限控制也是我們非常關(guān)心的問題。阿里云的數(shù)據(jù)湖構(gòu)建（Data Lake Formation）作為數(shù)據(jù)湖構(gòu)建和管理的核心組件，為我們解決了數(shù)據(jù)入湖、統(tǒng)一元數(shù)據(jù)管理、統(tǒng)一權(quán)限控制等關(guān)鍵問題。
DLF 通過統(tǒng)一元數(shù)據(jù)服務(wù)提供數(shù)據(jù)湖內(nèi)數(shù)據(jù)的管理視圖，企業(yè)可以通過該服務(wù)管理和檢索企業(yè)的數(shù)據(jù)，同時無縫對接云上的各類大數(shù)據(jù)計算和分析引擎。DLF 權(quán)限管理模塊基于用戶和用戶組提供列級別的精細(xì)化權(quán)限控制能力，降低數(shù)據(jù)安全管理的難度和風(fēng)險。此外，DLF 還提供了多種數(shù)據(jù)源的數(shù)據(jù)入湖和清洗模板，支持以全量和實時增量的方式將數(shù)據(jù)同步至數(shù)據(jù)湖中。
數(shù)據(jù)湖格式：Deltalake
在數(shù)據(jù)的存儲格式上，我們選擇使用 Databricks 公司提供的 Delta Lake 格式。該格式支持?jǐn)?shù)據(jù)的增量更新和消費，從而避免了使用 Lamda 架構(gòu)的兩條鏈路來支持離線和實時的數(shù)據(jù)計算。
數(shù)據(jù)分析計算引擎：DDI 數(shù)據(jù)洞察+EMR-Presto 交互式分析
在數(shù)據(jù)計算和分析層面，我們主要使用 Spark 做離線計算、用 Spark Streaming 做實時計算、用 Presto 做交互式的聯(lián)邦分析（有一些實時性要求非常高的數(shù)據(jù)，我們直接從關(guān)系數(shù)據(jù)中讀?。?。
阿里云的 Databricks 數(shù)據(jù)洞察（DDI）產(chǎn)品，提供了全托管及商業(yè)版的 Spark 服務(wù)。在保證軟件產(chǎn)品功能和性能領(lǐng)先的基礎(chǔ)上，提供了全托管免運維的服務(wù)，同時有極高的 SLA 保證，讓我們可以更專注在業(yè)務(wù)模塊的開發(fā)上。
在交互式分析方面，我們選擇使用 EMR 提供的 Presto 服務(wù)。Presto 是一個開源的分布式 SQL 查詢引擎，適用于 GB 到 PB 級別的大數(shù)據(jù)交互式分析。同時由于我們部分?jǐn)?shù)據(jù)需要從業(yè)務(wù)的關(guān)系數(shù)據(jù)庫直接拉取，使用 Presto 的多 Catalog 和 Connector，可以快速支持跨數(shù)據(jù)源的聯(lián)邦分析。阿里云的EMR服務(wù)可以幫助我們快速拉起和管理 Presto 集群，并且通過 DLF 可以無縫訪問 OSS 數(shù)據(jù)湖中的數(shù)據(jù)。
數(shù)據(jù)開發(fā)與調(diào)度
在數(shù)據(jù)開發(fā)方面，我們團隊繼續(xù)沿用熟悉的 Zeppelin Notebook 和 Airflow。EMR Studio 是 E-MapReduce 最新推出的用于開源大數(shù)據(jù)開發(fā)場景的集群類型，提供交互式開發(fā)、作業(yè)提交、作業(yè)調(diào)試和工作流一站式數(shù)據(jù)開發(fā)體驗。能夠無縫對接 EMR 計算集群，自動適配多種計算引擎協(xié)同工作。覆蓋了大數(shù)據(jù)處理 ETL、交互式數(shù)據(jù)分析、機器學(xué)習(xí)和實時計算等多種應(yīng)用場景。EMR 的 Data Studio 針對開源的 Zeppelin 和 Airflow 上做了系統(tǒng)化集成以及組件功能的優(yōu)化和增強。一方面可以從 EMR 上快速構(gòu)建起 Zeppelin 和 Airflow 的服務(wù)，同時擁有更穩(wěn)定和易用的數(shù)據(jù)開發(fā)界面。
至此，我們從數(shù)據(jù)的存儲與管理，到計算引擎的使用與開發(fā)，介紹了百草味這次大數(shù)據(jù)上云的全新架構(gòu)。下面我們再具體介紹數(shù)據(jù)、代碼、調(diào)度等遷移上云的實施過程，以及新架構(gòu)上的數(shù)據(jù)開發(fā)運維的落地細(xì)節(jié)。
Hadoop 數(shù)據(jù)和任務(wù)遷移
第一部分涉及的是歷史數(shù)據(jù)的搬遷，從 IDC 的 Hadoop 集群遷移到阿里云的 OSS 上，同時要完成元數(shù)據(jù)從集群內(nèi)的 Hive Metastore 到云上 DLF 的統(tǒng)一元數(shù)據(jù)服務(wù)的遷移。
1. HDFS 數(shù)據(jù)上云，寫入 OSS
HDFS數(shù)據(jù)的遷移，我們使用了阿里云 JindoFS 組件提供的 distcp 功能，通過一行命令完成所有數(shù)據(jù)文件的遷移。
??
2. 元數(shù)據(jù)遷移，Hive 表遷移至 DLF
DLF 產(chǎn)品提供了元數(shù)據(jù)遷移的功能，只要配置好 HMS 所在的 RDS/Mysql 數(shù)據(jù)庫的連接方式，就可以一鍵運行命令，將 HMS 的元數(shù)據(jù)同步至 DLF 元數(shù)據(jù)服務(wù)中。
??
3. 任務(wù)遷移
我們在新老集群里都是用 Zeppelin Notebook 作為主要的開發(fā)工具，所以任務(wù)遷移只需要線下集群的代碼遷移過來就可以了。Zeppelin 支持使用 SQL、Scala、Java、Python等多種語言進行數(shù)據(jù)開發(fā)，使用非常靈活。
以下是我們的一些代碼管理目錄和示例：
? ?
??
4. 調(diào)度遷移
在調(diào)度方面，由于我們遷移的時候，EMR Studio 的 Airflow 組件還沒有正式發(fā)布，所以我們使用了 EMR 提供的 Workflow 進行調(diào)度。它也支持以 DAG 的形式進行任務(wù)依賴的管理和調(diào)度。后續(xù)等 Airflow 發(fā)布后，我們會考慮遷移到 Airflow上。
??
業(yè)務(wù)數(shù)據(jù)入湖，DLF 批量/增量入湖
在完成了歷史數(shù)據(jù)和任務(wù)遷移之后，我們要開始接入業(yè)務(wù)系統(tǒng)的數(shù)據(jù)。從業(yè)務(wù)上我們主要有兩類接入方式，一類是原始數(shù)據(jù)的同步，分歷史數(shù)據(jù)的批量導(dǎo)入和實時數(shù)據(jù)的增量導(dǎo)入，另一類是需要在導(dǎo)入的過程中做一些相對復(fù)雜的計算邏輯。針對這兩種方式，我們分別采用 DLF 的數(shù)據(jù)入湖和 DDI Spark 的 ETL 來實現(xiàn)。
如下圖所示，我們在 DLF上 配置了全量和增量入湖的任務(wù)，直接從 RDS 入湖轉(zhuǎn)換成 Delta Lake 格式。實時入湖的鏈路，底層通過 Spark Streaming 訂閱并解析 RDS 的 binlog，將數(shù)據(jù)更新至 Delta lake 表?？梢宰龅椒昼娂壗鼘崟r的數(shù)據(jù)可見性。
DLF 提供了任務(wù)級別的監(jiān)控，當(dāng)任務(wù)失敗時，可以將失敗告警以短信、郵件或釘釘群的形式通知到運維人員；針對實時的任務(wù)，還可以配置任務(wù)延時監(jiān)控，當(dāng)數(shù)據(jù)同步延時超過指定時間時，也會觸發(fā)告警。這大大提高了我們的運維效率。
DLF 監(jiān)控
針對一些需要做數(shù)據(jù)計算的復(fù)雜入湖任務(wù)，我們使用 Spark 做 ETL 任務(wù)，在任務(wù)節(jié)點上編寫具體的計算邏輯。但這部分任務(wù)相對較少，需要我們自己做任務(wù)狀態(tài)的監(jiān)控和管理。
基于 Deltalake 的批流一體數(shù)據(jù)處理
在 Delta lake 格式下，結(jié)合使用 DLF 的實時入湖和 DDI 的 Spark Streaming 技術(shù)，我們可以獲得分鐘級近實時的數(shù)據(jù)流。使用 Spark Streaming 消費 Delta 的增量數(shù)據(jù)后，我們將數(shù)據(jù) Sink 到在線庫（如 TableStore、RDS 等），可以快速給下游的 BI 和業(yè)務(wù)系統(tǒng)提供最新的數(shù)據(jù)做分析與決策。同時基于 DDI Spark，我們可以對 Delta Lake 中的數(shù)據(jù)做離線計算和分析。
聯(lián)邦分析
在聯(lián)邦分析方面，由于全托管的 Presto 目前還沒有正式發(fā)布，我們暫時通過 SparkSql 來實現(xiàn)。我們基于 Databricks，通過簡單百來行代碼，完成整庫或指定表的注冊，完成邏輯統(tǒng)一后就可以進行聯(lián)邦的數(shù)據(jù)分析。
目前我們初步完成了大數(shù)據(jù)平臺上云的建設(shè)以及業(yè)務(wù)的遷移，但離我們的理想形態(tài)還有很長的路要走。一方面，業(yè)務(wù)的發(fā)展也對我們平臺在安全性和性能等方面提出更高的要求，另一方面阿里云的相關(guān)產(chǎn)品也在不斷完善和發(fā)布中，我們會適時引進新的產(chǎn)品和功能。目前有以下幾個方面我們正在跟阿里云的同學(xué)們一起建設(shè)中：
多引擎支持多場景數(shù)據(jù)分析
當(dāng)下選擇的 OSS 作為統(tǒng)一存儲，上層的計算層主要 Databricks 數(shù)據(jù)洞察提供 Spark 引擎做離線和實時的計算分析。因為在線下做數(shù)據(jù)需求我們是強依賴 Presto 的，OLAP 場景下 Spark 跟 Presto 還是有些差異，阿里云上有半托管的 EMR Presto 產(chǎn)品形態(tài)，同時也將推出全托管的 Presto 服務(wù)，我們后續(xù)會綜合考慮需求和產(chǎn)品的發(fā)布時間，增加 Presto 的組件。
數(shù)據(jù)權(quán)限管理體系
現(xiàn)有權(quán)限管理功能剛剛發(fā)布，我們正在接入中。
存儲優(yōu)化
在存儲的數(shù)據(jù)治理和優(yōu)化方面，阿里云也提供了很多建議，我們后續(xù)會進一步實施。
OSS 開了多版本之后，存儲成本會高很多，另一方面也會影響計算性能，其實 delta這種文件存儲也已經(jīng)做了一層多版本控制。所以要使用 OSS 的生命周期管理消除多版本帶來的副作用。
分層存儲：DLF 產(chǎn)品將推出表和分區(qū)級別的數(shù)據(jù)冷熱度分析，同時利用 OSS 的分層存儲來進一步優(yōu)化存儲的成本。
小文件合并：線下集群的小文件合并是非常透明的，但是 OSS 沒有提供這種功能，希望后面可以在 DLF 數(shù)據(jù)湖管理相關(guān)模塊中有所體現(xiàn)。
本文介紹了百草味的大數(shù)據(jù)平臺從 IDC 自建 Hadoop 集群遷移到阿里云云原生數(shù)據(jù)湖過程中的思考和實踐，目前我們還在不斷建設(shè)和優(yōu)化過程中。
最后，非常感謝阿里云數(shù)據(jù)湖和 Databricks 團隊，他們在大數(shù)據(jù)領(lǐng)域的專業(yè)能力和過程中的高效反饋，在我們這次新架構(gòu)的規(guī)劃和落地中起到了關(guān)鍵作用。
對相關(guān)產(chǎn)品感興趣的同學(xué)歡迎掃碼加入以下釘釘交流群，探討相關(guān)技術(shù)問題！