公司簡介
錢大媽是在社群生鮮連鎖中，以"不賣隔夜肉"作為品牌理念的的行業開拓者。在成立之初即從新鮮角度重新梳理傳統生鮮行業的标準，對肉菜市場進行新的定義。通過嘗試和驗證"日清"模式，以及"定時打折"清貨機制，堅定落實不隔夜銷售。
截至2021年5月，錢大媽已全國布局近30座城市，門店總數突破3000家+，服務家庭超1000萬+，經營蔬菜、水産、水果、豬肉類、肉類（非豬肉）、蛋奶、加工食品、綜合标品八大生鮮品類，逾500種優質産品。 而"不賣隔夜肉"的理念，回歸最樸素的目的：讓消費者能買到新鮮的食物。踐行這一理念，除了依賴強大的供應鍊系統，更離不開科學技術和數字化建設的支援。
項目背景
錢大媽全管道資料中台主要承載交易側資料，貼近業務一線為業務賦能。現資料中台已為3000家+門店提供線上資料服務，支撐各部門營運、業務人員在智慧中台進行資料分析、挖掘資料背後的業務價值，并作為錢大媽首個支援實時計算、首個完成資料埋點的團隊，從資料驅動業務理念為出發點，為錢大媽業務發展保駕護航。
而項目初期，在極端情況下隻有一個産品、一個技術的人員配置情況下，一個月内背靠背完成項目初期的基礎建設，包括但不限于：數倉規劃、技術架構、次元模組化、資料名額、資料開發等一系列工作，那麼我們團隊是如何在有限的人力資源下進行破局的呢？下面請聽我娓娓道來。
資料中台建設
架構和中間件的選型，影響資料中台建設過程中後續的開發流程和運維複雜度，而目前開源的大資料元件可謂是遍地開花，每個元件都各有特色，但是它們在大資料的體系化方面又各有各的玩法。
琳琅滿目的大資料元件組合方案：
本着以業務為導向的原則，我們希望整個架構易于運維管理，功能性盡可能統一，以便将更多的精力和時間用在業務思考和資料賦能的應用上。
- 我們的硬需求：離線計算引擎，實時計算引擎，OLAP資料庫，KV資料庫，資料內建元件，分布式存儲系統
- 我們的軟需求：計算資源可彈性調整、易于運維且元件鍊路盡可能短、批流統一
在項目前期投入人力有限，業務急需在短期内上線的背景下，綜合考慮成本和系統架構的相容性和擴充性，我們團隊認為基于雲原生的全托管大資料解決方案：DataWorks+Maxcompute+Hologres+Flink比較适合我們。
以下是各個元件的定位：
- DataWorks：資料的內建、開發、運維、服務等的一站式管理平台
- Maxcompute：離線分布式計算引擎
- Hologres：查詢性能快、支援線上OLAP、KV點查、實時讀寫
- Flink：高性能實時計算系統
錢大媽資料中台架構 V1.0
産品選型确定好之後，開始建設資料中台V1.0，主要應用在業務接口加速查詢場景。以下為資料中台V1.0架構圖：
當确定了架構和中間件後，從雲元件開通到VPC網連通一天内就可以完成，讓項目組可以快速地投入項目初期的業務資料內建接入和資料分域模組化工作。這兩項大工程，我們都可以在Dataworks的對應子產品上完成。
在資料接入過程中，我們不需要部署諸如Kafka+Canal元件來完成業務資料庫的Binlog訂閱和部署AirFlow等元件來負責任務排程管理，通過DataWorks的資料內建子產品，即可将業務資料"一鍵"實時和離線同步到Maxcompute和Hologres。
在DataWorks的資料模組化功能上，我們通過模組化語言：基于Kimball次元模組化範式下梳理業務闆塊、業務過程，并進行資料分域、維表事實表定義等資料模組化操作，并用FML（Fast Modeling Language）模組化語言将邏輯模型落實到實體模型。
在業務接口查詢加速場景上，我們通過将MaxCompute的資料離線排程至Hologres内表以獲得更快的查詢體驗，由于兩者底層資料無縫連接配接，是以同步速度也是比較快的，10萬級别的資料隻需1秒即可完成（100,000/s）。
選擇Hologres作為線上業務支援的重要一環，是因為：
- 安全：接入RAM鑒權，權限管理友善和安全。
- 索引豐富：根據不同的查詢場景，選擇不同的存儲模式（行存或列存），提供專屬的索引支援。
- 少資料備援：在一個系統内滿足 KV 和 OLAP 兩個場景，減少跨系統帶來的資料備援。
錢大媽資料中台架構 V2.0
在資料中台V2.0建設上，我們的架構分階段先後實作了純離線、離線-實時的Lambda架構疊代。如下圖所示：
- 同步：利用DataWorks的資料內建功能，實時訂閱同一份Binlog日志，雙寫到Hologres和MaxCompute兩個系統。
- 離線鍊路：對于時效性不敏感且計算複雜的場景：如使用者畫像、人貨場标簽體系、促銷效果複盤等，依然通過MaxCompute進行離線ETL計算生成，最後彙集到Hologres做查詢加速。
- 實時鍊路：對于實時性要求高的場景：如實時看闆、風控感覺、規則報警等場景，通過Hologres+Flink組合實作。
值得留意的是，在資料中台V2.0版本，我們隻是新增了一個實時計算引擎（Flink），就擴充出了一條新的實時鍊路：Hologres（source）-> Flink -> Hologres（Sink）。這得益于這兩個元件的原生适配：
- Flink實時計算引擎原生支援Hologres的Connector，相容性好，讀寫友善
- Hologres支援主鍵（Primary Key，PK），能保證Flink端對端場景中的精确一緻性（Exactly Once）
- Hologres采用LSM架構，支援實時更新 ，細粒度更新
Lambda架構下經常面臨的一個問題點就是實時和離線的計算結果如何聯邦計算，Hologres的内表和外表結合的特性從設計層面就為我們解決了這個問題：實時計算的結果存儲在内表，離線計算的結果存儲在MaxCompute上，通過外表進行通路，由于Hologres在底層和MaxCompute資料無逢連接配接，友善聯通離線和實時資料。
在資料中台V1.0純離線的架構版本，我們更多的是通過離線ETL加工，将ADS層的結果集推到Hologres作為查詢的加速。但随着業務的發展，更要求我們具備實時性的DWD寬表層和準實時、甚至是實時的、主題性DWS層的資料。是以在技術上，我們基于Hologres内外表特性實作的實時打寬、冷熱鍊路和資料回刷機制：
- DWD層，實時打寬+冷熱鍊路
如訂單業務場景，業務端需要要實時擷取近30天的訂單變更情況，是以近30天的熱資料我們用Flink實時寫入Hologres内表，因為内表的優勢是查詢快，缺點是存儲成本略高（内表存儲在SSD，硬體成本高）。對于超30天的資料，通過歸檔或直接通路的形式通路存儲在MaxCompute上的資料，做到冷熱資料的分層，降低低頻通路資料的存儲成本。另外，利用Hologres支援PK的特性，通過"Insert on Conflict"的語義定期對實時寫入的資料進行滾動補漏、資料回刷等資料兜底機制，確定資料層具備"自修複"能力，防止某些故障情況下實時寫入帶來的資料不一緻情況。
- DWS層，微批排程/邏輯視圖+聯綁查詢
如BI場景，業務可以接受5-10分鐘左右的延遲，我們通過結合微批排程和邏輯視圖計算DWS層，用于支援BI資料接口和業務的即席查詢。 依然是通過内外表的形式，實作資料的冷熱分層。冷資料則視業務和資料量情況，決定是存儲于MaxCompute通過外表通路，還是同步進Hologres内表加速查詢速度。最後通過在Hologres進行查詢時的合并，達到聯綁查詢的效果。
風控場景應用
資料中台架構V2.0目前已在錢大媽多個業務場景落地，如資料服務、資料報表、實時風控系統等，下面将介紹如何具體應用到風控場景。
實時風控系統需要結合業務記錄和埋點日志線上甄别異地支付、大筆異常訂單、消費終端變更等風險事件，實時觸發風險應對動作，為風控專員提供及時的資料支撐和更快速的反應能力。
從上圖可以看到，實時風控資料流的整過生命周期都會經過Hologres：資料源Binlog、實時維表點查、OLAP分析：風控全鍊路都由Binlog進行事件式驅動，且Hologres在開啟Binlog模式下，底層提供Binlog資訊查詢，友善定位消費位點和複盤消費情況。在維表點查場景則可以使LRU，微批寫入等優化手段進行Lookup Join性能優化。最終将結果資訊實時寫回Hologres提供線上分析和即席查詢應用，也可以實時推到其它業務關聯觸達系統，進行業務端攔截、系統報警等一系列風險應對動作，以此完成整個風控場景的閉環。
業務價值
錢大媽全管道資料中台基于阿裡雲大資料方案進行靈活式的業務落地，支撐内外部多個應用場景，給業務帶來的價值主要如下：
- 資源成本降低：零硬體資源成本，各環節支援資源彈性升縮，靈活應對各種資料高峰場景
- 運維成本降低：全托管式運維，減輕運維成本，讓更多精力集中在業務邏輯開發
- 架構簡單：将OLTP、OLAP 和KV三個場景內建于一個系統（Hologres），縮短中間件鍊路
- 架構生态相容度高：Hologres與離線計算引擎（MaxCompute）、實時計算引擎（Flink）、DataWorks相容程度高，融于雲原生生态，易開發适配
期望
Hologres作為雲原生體系下的一款HSAP（分析服務一體化）産品，從定位和理念上都與錢大媽全管道資料中台的架構理念一緻，希望在不久的将來能在産品側能夠支援如下特性：
- 資源隔離。Hologres現在資源隔離是通過不同的執行個體進行隔離的，希望通過例如租戶的形式實作自定義的資源隔離。
- 分時彈性。根據業務的不同峰值時段彈性調整資源，以節省使用者成本。
- 物化視圖。截至Hologres 0.10版本，尚未支援物化視圖。有了物化視圖，可以一定程度上減少微批排程的場景。
- 内表冷熱分層。現在Hologres是将冷資料存儲于MaxCompute上，但是查詢速度還是和内表相比存在一定的差距，希望在内表上能就實作冷熱資料的分層。
作者：彭明德，目前就職于錢大媽，任全管道資料中台大資料開發工程師