文目錄：.電商離線數(shù)倉4.電商實時數(shù)倉.電商數(shù)據(jù)應用6.后續(xù)演進和流批一體探索分享嘉賓|王春波高級數(shù)倉工程師《Doris實時數(shù)倉實戰(zhàn)》作者文字校對|志明與數(shù)據(jù)出品社區(qū)|DataFun01背景介紹最重要的業(yè)務形式之一，目前主流的業(yè)務形態(tài)是B2C。在這個群雄逐鹿的年代，除了淘寶、京東、拼多多等頭部電商以外，還活躍著眾多的中小規(guī)模電商平臺。筆者所在公司的電商APP就是其中一個，目前注冊用戶超過2億，月活躍用戶接APP為載體，最重要的數(shù)據(jù)就是以訂單為核心的結構化數(shù)據(jù)和以日志流為訂單業(yè)務包括下單、支付、發(fā)貨、物流、評價、退貨等業(yè)務流程，但是都可以通過order_id串聯(lián)起來，數(shù)據(jù)保存在關系型數(shù)據(jù)庫中。我們這邊通過MySQL分庫分表方案承載訂單相關的業(yè)務數(shù)據(jù)，目前積累了自系統(tǒng)上線以來的1.5億訂單，目前日增長訂單數(shù)為點擊流數(shù)據(jù)則是APP上所有用戶的操作行為埋點記錄數(shù)據(jù)，是源源不斷產生的半結構化數(shù)據(jù)。由于前期對APP埋點和日志流數(shù)據(jù)做過治理，所以目前數(shù)據(jù)格式比較規(guī)范，數(shù)據(jù)輸出也比較穩(wěn)定。點擊流數(shù)據(jù)包括30+固定字段和一個擴展json字段組成，固定字段包括設備信息、會話信息、用戶信息、網絡信息、埋點編碼等，擴展json字段內容則根據(jù)實際的頁面情況生成，不同的頁面或者埋點對應的擴展信息不同。點擊流數(shù)據(jù)每日增量在筆者接手電商數(shù)倉項目時，恰逢公司推進數(shù)據(jù)治理項目，準備重建電商數(shù)倉。在我接手之前，公司數(shù)倉按照不同的業(yè)務模塊劃分不同的數(shù)據(jù)集市，電商業(yè)務有專門的電商集市，但是內部數(shù)據(jù)加工邏輯比較復雜、沒有明確的數(shù)據(jù)分層和清晰的數(shù)據(jù)處理邏輯，基本上是面向需求開發(fā)，重復邏輯比較多，數(shù)據(jù)一致性差。我接手電商數(shù)倉以后，按照標準的數(shù)倉分層重構了電商數(shù)倉，同步產出實時數(shù)據(jù)，滿足了實時數(shù)據(jù)看板、自助分析數(shù)據(jù)集、雙十一大屏、每日業(yè)績播報等多個數(shù)據(jù)應用。恰逢最近經歷了新一輪618大促的考型數(shù)據(jù)中臺作為公司統(tǒng)一的數(shù)據(jù)平臺，承載著全公司大數(shù)據(jù)集群平臺的基礎能力，包括離e如自助分析工具QuickBI、調度系統(tǒng)、畫像系統(tǒng)、監(jiān)控告警系統(tǒng)、基于Zepplin的統(tǒng)一數(shù)據(jù)多臺服務器，基于Yarn框架進行統(tǒng)一的資源管理，計算資源分為離線計算、實時計算、實時查詢等不同的資源隊列，其中離線計算目前以Spark為主，部分高優(yōu)先級的任務或者時效性較高的任務已經切換到內部改造過的Presto計算引擎。目ive實時數(shù)據(jù)處理分為實時數(shù)據(jù)采集、實時數(shù)據(jù)計算和實時數(shù)據(jù)查詢三個方面。實時數(shù)據(jù)采集通過自動化配置，直接寫入Hive數(shù)倉的rt_ods庫，目前有接近1000張表；實時數(shù)據(jù)計算目前主要是交給Flink完成，目前線上運行的大約500個任務；實時數(shù)據(jù)查詢包括為交互式查詢引擎。選擇ClickHouse的原因主要是由于查詢性能快、查詢穩(wěn)定，只要設置合理的分區(qū)，單表數(shù)據(jù)量可以達到百億甚至千億級別。目前公司在多個業(yè)務線引入了L數(shù)據(jù)的快速實時查詢。大數(shù)據(jù)線的ClickHouse集群由28臺節(jié)點組成14主*2副本集群，每ODS叫數(shù)據(jù)采集層，數(shù)據(jù)來源于源系統(tǒng)，保留源系統(tǒng)概貌，為上游邏輯層提供原始放快照數(shù)據(jù)、增量追加數(shù)據(jù)和全量歷史快照數(shù)據(jù)。對于全量采集的數(shù)據(jù)，直接抽取到按日分區(qū)存入ODS庫，然后按照庫表主鍵合并去重寫入SNAP庫；對于有保存歷史快照份按日保存到History庫。DWS據(jù)主要來源于DWD層，以指標加工為核心，按照維度建模的兩步進行數(shù)據(jù)加工，第一步聚焦于指標計算，統(tǒng)一加工業(yè)務指標，第二步關聯(lián)維度信DM應用層，數(shù)據(jù)來源主要來自DWS層，可按業(yè)務和應用主題分ClickHouse庫；對于百萬級以下的數(shù)據(jù)，則直接保存到MySQL數(shù)據(jù)庫。此外，還有應用是在DWS層的基礎上進行二次加工，包括簡單匯總、計算同環(huán)比、多維匯總等，先寫入表：際項目上設計和建設的模型遠不止這幾張表，我們還針對售后訂單創(chuàng)建單獨的表、根據(jù)埋點業(yè)務的運營位曝光和點擊計算下單成交率、根據(jù)商品的推薦計算推薦模型的有效性，根據(jù)搜索的結果及點擊計算不同入口的搜索成交情況等等。但是項目主要的核心的訂單和點擊數(shù)據(jù)流就是這10張表，其中商品標簽表和用戶標簽表還作為電商業(yè)務 04在離線數(shù)據(jù)加工的基礎上，業(yè)務用戶提出來實時數(shù)據(jù)的需求，主要包括企業(yè)微信業(yè)績播最開始開發(fā)的是企業(yè)微信業(yè)績播報機器人需求，每小時匯總一次當日成交數(shù)據(jù)，并和歷史成交進行對比，將數(shù)據(jù)寫入MySQL，再由Java程序讀取數(shù)據(jù)，按照指定的數(shù)據(jù)格式播針對這個業(yè)務場景，我們按照典型的Lambda架構設計，復用公司的Kafka寫入Hive數(shù)據(jù)組件，通過配置化實現(xiàn)關鍵業(yè)務數(shù)據(jù)自動同步到Hive的rt_ods數(shù)據(jù)庫。然后我們通過Presto算引擎簡化訂單業(yè)務的加工邏輯，只計算關鍵成交指標，加工到DWS，并和離線數(shù)據(jù)加工的DWS層數(shù)據(jù)進行合并去重，保留最近13個月的訂單明細。點擊流數(shù)據(jù)不需去重，只保留當日、上月環(huán)期和去年同期三個日期的明細數(shù)據(jù)，并加工好關鍵指標，保留明細數(shù)據(jù)。最后一步是加工計算本期、同期、環(huán)期的不同指標，并分別按照商品維度第一代實時數(shù)倉架構實時播報滿足了業(yè)務用戶跟蹤業(yè)績進展的需求，但是時效性比較差，無法滿足實時成交監(jiān)控、實時看板和大促大屏的需求，于是我們又進一步開發(fā)了新的實時鏈路，即Flink實第二代實時數(shù)倉架構FlinkFlinkSQL組成，分別讀取訂單CDC日志流數(shù)據(jù)和點擊埋點日志流數(shù)據(jù)，在進行簡單的數(shù)據(jù)轉換以后關聯(lián)離線加工的商品信息表(定時同步到HBase，全量1600萬)獲取商品維度然后寫入Clickhouse。在電商業(yè)務的多維分析中，用戶基本屬性、用戶成交記錄和用戶衍生標簽。在我們的業(yè)務場景中，商品維度是千萬級別，用戶維度是億級別，經過測試，在實時點擊流中，由于數(shù)據(jù)流量比較大，關聯(lián)用戶信息會出現(xiàn)查詢超時導致關聯(lián)不上的場景，因為我們砍掉了實時數(shù)據(jù)的用戶維度，而選擇在ClickHouse進行結果數(shù)據(jù)查詢時再利用LocalJoin的優(yōu)勢來關聯(lián)用戶維度。實時加FlinkClickHouse們首先將離線加工好的訂單寬表、點擊流寬表和用戶維度信息表在每天跑批完成以后同步到Clickhouse(其中訂單寬表是每日全量同步最近三個自然年的數(shù)據(jù)，點擊流每日增量同步昨日數(shù)據(jù))，然后通過一個視圖來合并離線數(shù)1.離線數(shù)據(jù)取下單(點擊)日期小于當日的數(shù)據(jù)，實時數(shù)據(jù)取離線數(shù)據(jù)沒有的下單(點擊)日期對應的數(shù)據(jù)。這是為了避免在凌晨時離線數(shù)據(jù)還沒有跑出來，導致查詢昨日沒2.實時數(shù)據(jù)關聯(lián)用戶維度，取用戶注冊時間和用戶引流渠道等信息。基于ClickHouse的特性，我們將所有接入的數(shù)據(jù)默認按照fuid的hash值進行數(shù)據(jù)分片，確保同一個用戶的訂單、點擊數(shù)據(jù)和用戶維度數(shù)據(jù)在同一個數(shù)據(jù)分片上，既可以實現(xiàn)Join的本地化，又能減少用戶數(shù)去重計算的資源消耗。為了強制join在本地進行，我們會直接在SQL中使用右表據(jù)訂單和點擊流的不同特點，承接訂單實時數(shù)據(jù)的表我們采用ReplicatedReplacingMergeTree表則采用ReplicatedMergeTree引擎表。在使用訂單實時數(shù)據(jù)時，我們會在表名后增加final關鍵字，確保讀取到最新的Flink數(shù)據(jù)完整度高并且基本上都是明細數(shù)據(jù)，可以滿足各種業(yè)務場景，因此在這個數(shù)據(jù)集基礎上我們創(chuàng)建實時成交看板、實時監(jiān)控預警和大促大屏等據(jù)應用在電商數(shù)倉的基礎上，我們構建了自助分析、固定報表、企業(yè)微信播報、標簽畫像、大促大屏等多個數(shù)據(jù)應用。其中，自助分析和固定報表都是基于QuickBI實現(xiàn)的，企業(yè)微信VUEWeb首先是自助分析，我們基于訂單數(shù)據(jù)和點擊流數(shù)據(jù)各自構建了一個寬表并同步到ClickHouse，不同的類目運營用戶和數(shù)據(jù)產品都可以基于這兩個自主數(shù)據(jù)構建自己的看板，并分享給其他同事。自助分析數(shù)據(jù)集根據(jù)用戶的需求還在不停的追加字段，完成各種實驗場景分析、用戶成交分析和經營利潤分析。訂單寬表已經擴充到了256個字段，還有不少的用戶標簽和商品標簽封裝在fuser_label_json和fsku_label_json兩個json字段等固定報表，滿足管理層經營數(shù)據(jù)分析需求。這些報表主要在同環(huán)比、日周月年等維度第三個應用是前面提到的企業(yè)微信播報，這里只截取其中一部分內容展現(xiàn)。企業(yè)微信從早上9點到晚上24點，每小時播報一次。其中最難的是24點以后的那次播報，需要做很多第四個應用是標簽畫像。我們的標簽畫像系統(tǒng)支持用戶和商品兩個維度，在標簽系統(tǒng)定義的基礎標簽都會換成成SparkSQL，加工以后同步到HBase。衍生標簽在基礎標簽的基礎上組合定義，結果數(shù)據(jù)也會加工到HBase。標簽系統(tǒng)提供單個用戶查詢標簽值和標簽組合圈選用戶兩個功能，前者用于在線接口調第五個應用是大促大屏。我們參照阿里雙十一大屏，構建了實時大促大屏，包括實時成交額、大促期間累計成交額、用戶分類成交金額及本同期對比、商品分類成交金額及本后續(xù)演進和流批一體探索補補的微調，但是整④①離線數(shù)據(jù)跑完以后，昨日的實時成交數(shù)據(jù)會提高，但是第三天又會下降。這是因為離線數(shù)據(jù)是以12點作為快照時間點計算的，后面的成交或者退款數(shù)據(jù)在實時里面可以體②商品維度數(shù)據(jù)一天只更新一次，導致當日上線的商品在統(tǒng)計時丟失，或者商品層級調③流處理SQL封裝在Flink管理平臺中，批處理SQL封裝在調度平臺，導致兩邊容易出現(xiàn)較困難，導致我們點擊流數(shù)據(jù)只保留最近半年數(shù)據(jù)并且一次最多查詢一個月的數(shù)據(jù)，用面對以上這些問題，我們開啟了第三代實時架構的設計和驗證之路。第三代實時架構我們引入了基于數(shù)據(jù)湖的流批一體模式和基于OLAP數(shù)據(jù)庫的多維實時數(shù)據(jù)查詢模式。在數(shù)據(jù)湖方面，經過多方對比，最終選擇Hudi作為數(shù)據(jù)湖底座，繼續(xù)沿用Flink進行流式數(shù)據(jù)i選擇Doris的原因有很多，例如支持多表關聯(lián)、方便擴展、支持多種數(shù)據(jù)模型、支持多種索引機制和查詢優(yōu)化，還支持存算分離遷移歷史數(shù)據(jù)到對象存儲，直接查詢外部數(shù)據(jù)源。更詳細的關于Doris的特點和使用方法，歡迎購買筆者撰寫的《Doris實時數(shù)倉實戰(zhàn)》一書。有了Doris，最大的好處是我們可以做到維度解耦，可以在查詢的時候才進行關采用這種流批一體的架構，可以解決流數(shù)據(jù)和實時數(shù)據(jù)切換時成交金額回退的情況；同時保留中間過程數(shù)據(jù)，可以邏輯變更導致需要回溯歷史重算的情況；引入獨立的OLAP查雖然理想狀態(tài)下，所有數(shù)據(jù)都通過Flink流式進行加工，但是經過調研，我們還是有一些數(shù)據(jù)的邏輯無法做到純流處理，比如用戶下單時是新用戶還是老用戶，所以我們還是保留了批處理的鏈路，批處理的數(shù)據(jù)通過Spark加工完成以后，直接寫入Doris更新主鍵模監(jiān)控，預計Q4會全