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