FFA2024分論壇-行業解決方案.pdf

《FFA2024分論壇-行業解決方案.pdf》由會員分享，可在線閱讀，更多相關《FFA2024分論壇-行業解決方案.pdf（235頁珍藏版）》請在三個皮匠報告上搜索。

1、騰訊廣告基于Flink的實時特征平臺建設宋奇騰訊大數據工程師特征平臺概述特征計算和存儲未來規劃特征平臺概述1.1 煙囪式特征鏈路的問題特征開發難繁雜的工程事務，浪費業務團隊的人力，妨礙他們在特征數據本身的探索和調研特征應用難特異特征鏈路對大部分人而言是黑盒，特征含義模糊不清，模型選擇和應用特征的效果全憑運氣特征管控難特征鏈路運行狀態未知，特征數據分散、規范各異，管控和維護難度高1.2 特征平臺：數據和模型的中間橋梁目標：把數據快速、高效、正確地應用于模型1.3 騰訊廣告-特征平臺整體示意圖Flink數據流特征生產Stream任務流特征組1流特征組2管控系統生產系統TDW 算子Lake算子IO類

2、算子序列算子統計算子生產類算子分析算子預覽算子調試類算子DSLNotebook規劃器批計算引擎優化器流計算引擎規劃器優化器批量特征實時特征存儲系統特征發布離線存儲在線存儲離線分析質量檢測更多算子特征補錄MarvelX-StorIceberg數據湖特征服務樣本工程模型預測模型訓練血緣追蹤：數據 特征 模型DAG執行AdCache特征抽取特征抽取Label Joiner123Flink數據流特征生產Batch任務批特征組1批特征組24任務控制：版本發布、實例運維數據管理：特征回滾、質量檢查特征計算和存儲2.1 流批一體的特征計算 Python DSL可交互、聲明式 DSL，降低特征開發難度2.1

3、流批一體的特征計算 Python DSL特征接口層統一，中間層解耦，執行層分引擎適配，降低業務理解與應用特征的難度特征業務場景算子庫序列特征統計特征內容理解特征Match特征PV過濾數值分段2.1 流批一體的特征計算 Python DSL窗口統計特征（批場景）目標群體在廣告上近 60 天，180 天內的曝光數優化：增量聚合，資源開銷降低 70%用戶根據業務訴求修改時間參數，平臺負責流批引擎選擇與解釋優化2.1 流批一體的特征計算 Python DSL窗口統計特征（流場景）目標群體在廣告上近 1小時，2小時內的曝光數優化：分片狀態復用，資源開銷降低 90%用戶根據業務訴求修改時間參數，平臺負責流

4、批引擎選擇與解釋優化2.2 實時內容理解特征計算場景優化業務舉例：商品特征是廣告側的重要特征，如果廣告創建時未關聯商品庫，需要對創意素材（圖片、視頻、落地頁）做內容理解后，關聯到最相似的商品 ID，再在商品庫檢索得到商品類目、商品屬性等信息作為特征值痛點：實時串聯調用各個算法模型（如語音識別、圖片OCR、視頻抽幀）生產內容理解類特征在工程上缺乏一個成熟易用的解決方案，但特征訴求越來越大2.2 實時內容理解特征計算場景優化挑戰點：異步執行+狀態管理+算子隔離調度依賴管理、容錯重試、平滑請求（削峰填谷）、服務緩存、異常服務節點降級 2.2 實時內容理解特征計算場景優化1.使用 Flink Asyn

5、cIO 對大量外部服務進行異步調用2.把廣告流水與 DAG 節點的大狀態托管給 Flink Keyed State 管理3.實時收集運行時信息對 DAG 進行動態裁剪，確保質量參差不齊的節點間不會互相影響，避免 Flink反壓異步 DAG 計算引擎2.2 實時內容理解特征計算場景優化使用同一套 DSL 描述，一致易用的交互式開發體驗用戶也使用統一的 Python DSL 描述內容理解特征的生產邏輯（如預處理、后處理、模型調用等），和常規的統計、序列等特征生產一樣的開發體驗2.3 流批一體的特征存儲特征數據存儲的挑戰點1.生產來源多樣，近千個數據源同時更新2.更新方式多樣，Upsert/Repl

6、ace/Append3.查詢模式多樣，如增量數據實時在線發布、變化數據分鐘級異?；貪L、全量數據統計分析等4.版本管理靈活，以年為單位的版本回溯、回滾、修正和回補2.3 流批一體的特征存儲特征存儲的業務訴求Iceberg 社區版/騰訊內部版本PaimonHudi主鍵 Upsert部分列更新上千特征（上千列），每個特征有自己的版本，單獨更新高并發寫入多特征生產流同時更新一張表多模式查詢分支化管理與演進記錄與管理上百個特征版本分支，并支持對任意歷史版本進行更新演進容易定制化擴展現有的數據湖技術能較好地契合大部分特征存儲的需求，但無法同時滿足，出于擴展性和騰訊大數據生態的兼容性兩方面考慮，使用 Ice

7、berg 作為基礎底座2.3 流批一體的特征存儲基于 Iceberg，新增主鍵特性，支持實時 Upsert 更新核心思想是對主鍵進行 bucket 分桶并確保每個桶內的數據文件是按主鍵有序的。由于數據文件本身主鍵有序，對數據進行歸并更新取最新的記錄是個相對廉價的操作，對數據的 Upsert 操作可以轉換為寫入時 Append Only、讀取時 Merge 的操作(Merge on Read)，以擁有良好的吞吐性能2.3 流批一體的特征存儲基于主鍵特性，新增列可重疊的多流數據合并能力，支持近千個特征源同時更新在多流數據合并能力上，計算層方案主要通過 Flink State 來實現，使用狀態 KV

8、 來緩存和拼接出整行數據，一方面對任務的性能調優要求很高，另一方面存在數據寫放大的問題。更優的方案是考慮將相關的拼接合并邏輯下推到存儲側。2.3 流批一體的特征存儲使用 Iceberg 主鍵+多流合并方案后，存儲側負責進行高效拼接，Flink 計算任務本身無復雜邏輯，時效性高、穩定性強基于實時入湖的特征數據，在無冗余的數據鏈路上，可以更低成本地協助業務更快發現線上數據的潛在問題，比如通過廣告新鮮度特征數據，快速獲取當前時段的 uv 統計結果和截斷比例，確認投放狀態是否健康生產環境實踐與應用2.3 流批一體的特征存儲1.版本回補：業務方寫入每個版本的增量數據，特征數據湖會文件級別記錄所有版本的全

9、量數據，不會有數據冗余2.版本回溯：使用方可以直接查詢到任意歷史版本的數據，由數據湖負責數據高效合并和壓縮3.版本修正：歷史版本特征元信息級別進行低成本修正，免去代價高昂的數據重刷4.版本回滾：指針化方式快速重撥與回滾到任意版本，并且支持隨時撤銷靈活高效的多版本管理能力2.4 特征平臺的收益切換前（煙囪式）切換后（平臺化）生產效率批特征 1 周，實時特征 2 周1 天單季度新增特征數目4002000（提升 4 倍）低質特征率50%10%（標準化特征管理）生產機器成本降低 30%未來規劃探索對流式任務的多流優化以及 Python UDF 的性能提升核心代碼已在騰訊內部開源，嘗試在搜推業務場景推廣

10、THANK YOU謝 謝 觀 看中國聯通網絡資源湖倉一體應用實踐李曉昱中國聯通專家China Unicom Network Resources Data Lakehouse Application Practice現狀及挑戰湖倉一體新架構效果及規劃Status and ChallengesNew Structure of Data LakehouseEffects and Plans現狀及挑戰Status and Challenges中國聯通網絡資源中心寬帶業務開通物理網絡圖無線/傳輸數字網絡圖分布式數據庫分片修改導致CDC亂序增量消費處理能力不足，數據時延最長小時級資源數據不定期更新，數據小

11、文件堆積一寫多讀場景，導致計算存儲資源大量浪費現狀&挑戰湖倉一體新架構New Structure of Data Lakehouse湖倉一體架構基于 Watermark+State+TimerService 多流保序合并策略全字段比對100%一致分鐘級延遲10mb存儲成本挑戰1CDC 亂序全量寫 Paimon 的 Schema 檢測及變更全增量 Schema Evolution-CdcSchemaCommonUtils挑戰2-全+增 Schema EvolutionSchema Evolution+Schema Compatibility 一體化多個增量寫同一個表字段兼容支持挑戰3-Schem

12、a Compatibility效果及規劃Effects and Plans數倉 vs 湖倉業務場景應用源碼改造未來規劃THANK YOU謝 謝 觀 看微財基于flink構造實時變量池Construction of Real-Time Variable Pool in Wetech Based on Flink穆建魁數據開發資深工程師業務背景策略模型變量用戶行為用戶屬性實時變量T0注冊進件T0T-1正常行為異常行為新用戶沒有歷史數據老用戶T0變異原始方案-即時計算APIAPIAPIQPS組件耦合SLA優化方案-流式計算CDCCDCCDCODSOLAPLambdaKappa不支持非線性變量計算一套

13、計算口徑架構選型Flink Exactly Once語義離線+實時的解決方案開發慢慢遇到的問題StreamApi 學習成本高flink sql 無法滿足需求 邏輯調整無法從state恢復 多流關聯state不可控 state 算子數據源變量原子層Stream-api數據清洗、加工數據關聯變量計算變量計算層Flink Sql變量池實時變量分層生命周期unionjoinjoinjoinunion all+key by 同一關聯鍵state多流關聯完整架構數據源變量原子層實時變量池slspaimonrdskafka變量計算層流式計算查詢接口查詢日志DorisEMR查詢接口查詢請求實時質量監控Paim

14、onDQC 任務PSI、缺失率、均值、方差當前成果風險營銷市場客服實時資源2000+cu，實時任務300+日均20億+消息處理覆蓋多項業務，且持續擴展中DorisSelectDBStarRocks未來展望THANK YOU謝 謝 觀 看陸上風光電站實時監測數據治理和架構思考姚遠工程師中國能建ENERGYCHINA背景陸上風光電站數據治理實時監測數據架構思考適應于特定業務系統的系統背景陸上風光電站外部驅動自主開發開發自有系統產品業務擴展重資產的投入業務融合監測和運維結合注：運維是指電站的運行維護業務背景降低運行和維護成本風力發電機組和光伏面板大多位于偏遠地區，巡檢作業復雜，覆蓋周期長。如何減少巡

15、檢頻次，快速發現問題、定位問題和解決問題，達到降低運行和維護成本的目的。提高安全性，保障場站平穩運行場站的高效率監測運維，可以提高場站安全性，保障場站的平穩運行；也可以保障場站運維人員的人身安全。提升發電量，增加效益隨著設備老化和部分設備的損壞，發電量會降低。如何對出問題的設備或模塊盡快恢復，提升運行效率，增加發電量。數據治理實時監測數據技術架構數據采集消息隊列KafkaFlink實時處理與計算實時處理與計算存儲數據對象存儲/自定義文件數據處理分析關系型數據庫時序數據庫緩存數據服務運行監控無人機巡檢故障預警升壓站監測線路監測運維檢修數據應用運行監控Zabb i x元數據管理時序數據庫HDFS關

16、系數據庫時序計算時序計算（備備）數據同步數據同步DataXDataX數據采集一體YJ01-分布式S501(#30)JH1n01-8n02-8n03-8n04-8n05-4JH2n06-8n07-8n08-8n09-8n10-8JH5n21-8n22-8n23-8n24-7n25-8S502(#31)S504(#33)分布式箱變交流匯流箱分布逆變器-路數光伏電站光伏組件直流匯流箱集中式逆變器集中式箱變升壓站YJ01-集中式S303(#20)N1ZH01-16ZH02-16ZH03-16ZH04-14ZH05-16ZH06-10N2ZH07-13ZH08-15ZH09-16ZH10-15ZH11-

17、16ZH12-16S503(#32)N1ZH01-15ZH02-15ZH03-14ZH04-14ZH05-15ZH06-16N2ZH08-16ZH09-16ZH10-14ZH11-14ZH12-13ZH13-12S506(#35)集中式箱變集中式逆變器直流匯流箱-路數光伏組件分布式逆變器交流匯流箱分布式箱變升壓站數據采集一體風機(本身)葉片振動變槳軸承傳動鏈 偏航軸承塔筒傾斜螺栓松動錨索拉力風電場數據采集一體電能量環境監測功率預測火災監測安防無人機機器人場地安全通用數據監測類型編碼監測方法編碼數據字段單位變形監測L1裂縫LFvaluemm(毫米)地表位移GPgpsTotalXmm(毫米)gps

18、TotalYgpsTotalZ加速度JSgXmg(加速度)gYgZ傾角QJX(度)YZangleAZI物理場監測L2 土壓力TYvaluekPa(千帕)監測類型編碼 監測方法編碼數據字段單位影響因素監測L3雨量YLvaluemm(毫米)totalValuemm(毫米)氣溫QWvalue(攝氏度)土壤溫度 TWvalue(攝氏度)土壤含水率HSvalue%(百分比)地下水DXtemp(攝氏度)valuem(米)孔隙水壓力SYtemp(攝氏度)valuekPa(千帕)氣壓QYvalueKpa(千帕)宏觀現象監測L4泥(水)位 NWvaluem(米)數據采集一體Http Client Modbus-

19、tcpModbus-rtuE文本IEC104 RabbitMQ流上解析原始采集流上數據治理-函數類型轉換 根據配置可以將遙測轉換為遙信，采用的策略是配置遙信值對應的遙測值范圍、區間，則可對接收到的遙測值按范圍、區間轉換相應的遙信值。數據變比 對于原始數據值，可以根據配置的比例、系數計算結果值。偏移處理 原始數據值，可以根據配置的偏移值計算結果值。數據包錯誤判斷 根據數據包校驗邏輯判斷是否接收到了錯誤的數據，如誤包、丟包、錯包，根據判斷結果進行相應的后續處理。TransFunc挑戰：模塊化清洗過程，抽象配置RatioFuncMoveFuncErrorFuncKafka-Tag流上數據治理-函數時

20、標清洗 在數據傳輸過程中會出現未來時標，需要清洗此種數據；跳變清洗 有時在數據接收過程中，會發現上傳的數據有跳變的情況。缺失清洗 在數據采集和傳輸過程中因為通訊原因可能會造成數據丟失，根據后面數據插補中提到的方法對丟失數據進行填補。死值清洗 在數據傳輸過程中會出現部分測點壞點或者停止刷新的情況。挑戰：數據流穩定、狀態數據大，TimeFuncHopFuncMissFuncErrorFuncSink to TSSink to kafka流上數據治理-函數統計功能（1）遙測統計：包括日月年最大值、最小值、平均值、最大值時間、最小值時間，負荷率，（2）峰谷差：越上下限次數，越限時間，電壓合格率?？梢砸?/p>

21、表格形式顯示，打印。（3）電度統計：日、月、年峰谷平尖總電度統計，可以以表格形式顯示，打印。（4）具有通道停運時間統計。（5）開關事故/非事故動作次數統計。（6）按月統計開關運行時間、電容器投運時間、RTU停運時間、可用率。消息隊列預警等統計等指標計算待計算指標隊列數據服務指標數據Flink異常應急時序直接計算挑戰：異常情況下的處理流上數據治理-計算指標計算數據分析統計報表能效指標生產指標發電量統計損失電量報表電能表統計故障統計效率分析損耗分析離散率分析歷史數據查詢架構思考適應于特定業務系統的系統壁壁壁壁枯枯I枯枯II枯枯III焐儉枯焐儉枯枯枯多場站架構數據跨區設備設備設備數據采集集控中心控制

22、區管理區時序/文件數據恢復Flink處理應用分析解決網絡長期隔離狀況下的數據同步數據跨區-融合應用集線等效時箱變等效時組串等效時聯合機缺陷控制區數據的統一場站類型不統一 風力發電/光伏發電。相同場站構網不統一 同樣場站，采用不同的構網發電模式。數據類型不統一 即使同種功效設備，廠家也是多樣化。部分設備數據能否獲取不統一 因場站而異，部分設備無法采集數據。推導計算統一標準數據的安全消息隊列Flink實時治理時序數據庫HDFS|Hbase數據的多類型存儲HDFS時序庫集控場站實時業務展望全站統合基于全站數據，實時分析場站健康狀況擴充分析基于設備生命周期的分析交叉驗證傳感器是不可靠的THANK YO

23、U謝 謝 觀 看基于Flink的中國電信星海時空數據多引擎實時改造中國電信數據發展中心企業級大數據時空智能系統2024年11月李新虎中國電信集團大數據架構師時空數據現狀中國電信集團時空數據現狀及能力體系實時場景多引擎化基于Flink構建多引擎實時場景匹配介紹典型應用實時改造的典型應用未來展望深空智能方面的工作布局時空數據現狀中國電信集團星海時空智能系統現狀及能力體系星海時空智能系統的現狀8000億+33P日增8000億條信令，存量數據43p，日增40T800+|251+流批任務800+，原子能力API 251+，離線實時模型1200+，各類畫像標簽1600+1000萬+電信支撐的c端和B端應用

24、，每天覆蓋的人數超1000萬n星海時空智能系統是基于電信全網4.3億用戶的信令數據打造的“通用平臺+通用能力”。近年來，通過構建時空系統的運營體系，結合全量客戶信息，形成跨地域、跨部門的客戶位置、軌跡、特征等信息，封裝各類標準化時空服務能力，強化生態合作，促進了時空系統的規?；l展n時空資產：2023年建設基站畫像、用戶位置標簽體系、多維數據集市、電子圍欄配置中心、網格畫像、智能區域（區域畫像）2024年建設行業指標庫、時空算法庫、基于MR數據集指紋庫n2024年8月，中國電信“星海大數據時空位置綜合服務能力”，獲得中國國際大數據產業博覽會優秀科技成果獎（左圖）。這是對電信時空智能系統建設和發

25、展的高度認可體量數據資產服務補充科普：信令數據的特點是，被動無感，全天24小時不間斷，40分鐘強制刷新。時空系統是“3底座+1通用平臺+N業務場景”的開放的系統。4g/5g/VoLTE/VoNR等位置信令形成數據底座。網元底座指的是通信核心網的實體網元。對支持移動網通信網絡中下行通道LPP協議，適用ECID、OTDOA、衛星單波定位技術的用戶，時空系統可在控制面獲取用戶亞米級的定位；生態合作方面，通過引入外部數據、外部能力，或者由隱私計算、數據要素渠道構建融合時空能力，組成生態集約底座。1 指的是通用能力，N是通用行業場景時空系統能力分層體系交通旅游金融農業教育醫療應急政務.群智感知+個體行為

26、+識別運動狀態通用行業匯總層4G信令數據工參數據數據接入層AOI數據用戶標簽數據融合位置壓縮小時表軌跡小時表駐留小時表用戶出行分類小時表用戶OD清單表位置基礎能力層5G信令數據Volte信令數據.基礎場景特征建模（柵格+基站）小區場景識別（AOI+基站工參）位置原子能力用戶月工作地表用戶月居住地表OD統計表通用柵格級用戶統計通用柵格級用戶駐留清單表用戶工作地柵格月表用戶駐留柵格top3天表自定義區域人員天表景區場景人員天表交通樞紐場景人員天表人員拉鏈分析三級區劃人員天表跨區人員清單天表區縣遷徙天表跨區出行人員清單月表基站柵格四級區劃場景、自定義區域價值鏈31N大模型智能隱私計算生態數據+生態能

27、力隱私計算、數據要素流通北斗室內5G電信網元能力+實時定位能力數據底座網元底座生態底座提示：電信對數據開放一直持謹慎和保守的態度。從后端開發、邏輯加工、數據開放、應用上線等環節時空系統層層把關，充分重視、保障數據安全。實時計算發展歷程第一階段：flume+storm2020年6月，利用開源lume組件快速的配置source、sink、agent，實現數據的快速收集flume架構缺點是運維成本比較高、經常容易丟數、流量高峰來時，需要收到部署很多agent，很難管理和維護Flume的配置文件也非常的繁瑣，經常的出事故2021年4月，為了解決上一階段的問題，完成Flink1.11的部署上線。通過YA

28、RN建設統一的資源池解決自動擴縮容的問題在kafka 的partiton數量變動的時候，也能快速的捕獲。Flink集群也有一套非常完善的監控運維體系，不需要過多的擔心數據的質量2022年，業務發展帶來更高的要求，需要自動化水平進一步提高，需要提供統一治理的功能第二階段：Flink 1.112022年9月，對實時數據域進行分層分類的打寬和輕度匯總，重點構建的基于基站、網格、四級區劃的數據匯總能力此階段，集團公司與省公司在兩級的情況下如何去滿足客戶需求的問題。因此，開發上線了位置工場，承接從數據集成、數據加工、資產建設、數據開放等各階段的自動化能力和可視化、標準化及綜合治理的能力第三階段：實時數倉

29、第四階段：多引擎實時架構2024年2月，復盤業務痛點，創新性的提出了多引擎的思路。構建了運動狀態、個體行為、群智感知為主的多引擎架構。根據用戶駐留情況，用戶與電子圍欄的相對空間關系，判斷用戶的運動狀態。根據個體與基站的駐留情況和畫像關系，分析個體行為，判斷是否匹配業務方的場景根據群體與柵格的流動關系和畫像關系，形成統計分析，形成群智感知實時場景多引擎化基于Flink構建多引擎化實時場景實時計算業務痛點多場景LBS支撐復雜邏輯封裝海量數據處理基于AOI信息進行數據計算多個AOI數據，散布全國金融、征信、文旅等不同行業指標體系不一致同一個行業，不同客戶的需求不一致自動化分布式計算與人工核驗融合在一

30、起31省信令數據+工參無統一的數據源管理不支持策略/規則/質量管控AOI數據LBS服務的生命周期管控2023年，時空業務迎來的發展的高峰。數據域從5個擴展到10個，數據量進一步擴大。實時業務遇到很多挑戰，包括計算資源適用迅速增加、業務場景分散不聚焦、相同場景不同客戶的業務口徑不一致。需要時空系統回答如何將數據資產規?；ㄔO、業務場景封裝、客戶個性化口徑三者協同的問題。簡單說來，我們既想要關注數據的完備性，具有處理海量的數據能力，又想要封裝行業的通用能力，還想要快速的敏捷的生產滿足客戶要求多引擎實時架構思路多引擎運動狀態識別引擎個體行為識別引擎群智感知識別引擎時空數據融合實時流實時流交通旅游金融

31、零售教育制造應急公共服務商務會展數據服務組件REDISHBASEHDFSFlink程序KAFKA自定義程序VOLTE4GXDR5GXDR標簽數據維表數據實時流AOI/POI抽象出來了運動狀態識別引擎，個體行為識別引擎，群智感知識別引擎三類。通用邏輯引擎化、口徑&參數配置化用戶位置與電子圍欄的駐留情況和空間關系，構成運動狀態識別引擎；用戶與基站駐留情況和空間關系，構成個體行為識別引擎。群體用戶與柵格流動關系和畫像關系，構成群智感知的引擎，比如對于熱門景區的熱點識別、人流引導，可以基于群智感知識別引擎開發，并支持多場景多駐留市場的不同口徑的計算多引擎改造1實時架構演進北京KAFKAKAFKAHBa

32、seKAFKA上海山東.工參ES31省應用層北京上海山東.31省KAFKAKAFKAKAFKAKAFKA第一階段：多鏈路煙囪式開發第二階段：多引擎加工（實時數倉）支撐需求位置工場配置中心AOI特征畫像白名單終端.多鏈路分類加工異常告警計算出行分析計算區域洞察計算人群駐留計算人群流動計算OLAPOLTP多引擎改造2這是一個多點運維到集中自動化運營的過程，監控運維平臺的構建需要滿足自動化的要求。Flink集群Backpressure監控、CheckPoint的生效的監控、長尾任務的解析，數據消費lag值監控，生產加工時長的監控等都實現了自動化Flink CDCFlink CEP位置工場：引擎規則配

33、置中心web頁面：手動配置數據流規則客戶：調用API網關進行配置數據總線 KafKa 信令流多引擎實時流生效（運動狀態、個體行為、群智感知）MysqlOceanBase引擎配置DBDMDWODS工參表配置中心選項：畫像、標簽、指標、閾值FLINK CDC實時多引擎離線數倉位置工廠任務與引擎映射關系多引擎改造3kafka無法復用無實時數倉支撐引擎規則完成配置化與位置能力工場的配置中心協同，隨時修改和制定新的引擎規則重復加工31省的數據被重復掃描告警監控復雜問題排查難度大實時數倉增加復用構建基于基站、行政區劃、網格、AOI數據的實時數倉。Kafka數量從311Topic降低到187全生命周期控制基

34、于事件的TTL生效策略基于Flink多引擎化的收益分析多鏈路實時加工多引擎實時加工資源Kafka存儲節約100T計算cpu 節約1w+復用度低于2的將實時引擎被融合提升到5穩定性異常告警減低60%AOI數據拉鏈化，穩定性增強計算處理貼源數據的軌跡點去重原始數據原軌跡點586個點1分鐘去重347個點5分鐘去重124個點原始用戶軌跡點中存在位置點重合及聚集現象（職住地尤為明顯），導致用戶軌跡過度冗余，為更清晰呈現用戶軌跡且減少計算和存儲資源浪費，對用戶軌跡數據進行分組、清洗，同時使用Flink滾動窗口函數進行位置點剔重計算優化1經緯度完全相同mysq數據增量數據全量Flink CDC雙流JOIN計

35、算MysqlKafkaESFileSystem任務規則配置數據位置數據傳統方式定時掃描外部數據加載到flink內部進行關聯，并非基于事件驅動，存在實時關聯效率低現象；利用Flink CDC全增量一體的方式捕獲規則變動，以事件驅動的方式，與信令主數據流進行join，達到實時驅動觸發基于配置規則的計算，降低計算的時延和提高計算準確性2分鐘定時掃描引擎規則生效的優化計算優化2周邊位置檢索優化n時空伴隨分析n附近網約車等快速檢索n周邊POI興趣點推薦使場景Flink遍歷求，解通過對數據庫中的每個地理實體進行逐一匹配和計算，以確定與查詢條件的匹配程度。這種方法隨著數據量的增加，計算復雜度和響應時間會顯著

36、增加，效率較低。常規法遍歷求解geohash通過將地理區域進行網格化并base32編碼，相鄰網格其編號前綴相同。如此，將二維空間數據壓縮為一維。結合B+樹索引，可適應于不同范圍的大規模位置點的查詢新法7位GeoHashn 檢索方法：利用公共前綴特性，快速定位鄰近點。n 空間索引優化：計算時間復雜度最低為遍歷求解的1/9提升點或效果Geohash示意圖算法優化1幾何圍欄時空映射優化n 點面相交判斷n 文旅景區游客識別n 交通樞紐乘客分析n 保險理賠位置核驗使場景Flink在給定區域和位置點情況下，通 用 點面包含、面面相交常使用ST_Intersects、ST_Within等空間算法進行計算，但

37、應對海量數據計算效率偏低，查詢耗時10s以上，很難滿足客戶需求常規法量空間計算預先使用空間算法找到面與基站的映射關系，轉換點面包含成為點與集合的join關系。在實際處理時，直接通過數據流中基站編號映射關聯，來判定用戶是否在區域中新法基站匹配關聯效率提升：基站匹配方式優化了幾何圍欄關系計算，在點面包含計算場景下，約為傳統矢量計算時間復雜度的1/k倍（k為面的折線包絡的頂點數）提升點或效果空間計算點相交算法優化2基站匹配典型應用實時改造的典型應用ETL基本數據處理根據業務集接入基礎數據通過工場配置中心獲取AOI、白名單等維度信息，關聯基礎數據，完成過濾通過保留用戶上一次的statement數據，加

38、工駐留邏輯、畫像邏輯漫入漫出類應用：運動狀態識別引擎ODS北京通過AOI地理數據與用戶運動方向的關聯識別，對運動狀態進行識別比如識別是否進入AOI電子圍欄、駐留電子圍欄、漫出電子圍欄、老人長時跌倒、多人時空伴隨等再通過網元側米級的實時定位確認，可以判定為符合捕獲條件的數據對個體，數據進行粗粒度捕獲，網元進行細粒度跟蹤DWD 基本數據流個體為識別引擎DWS翼聯呵護數據流DWSga重點數據流DWS應急告警數據流任務關聯，打標處理進行二次邏輯加工并分流。在精準數據流上加工OD分析，出行語義翼聯呵護重點應急監控平臺伴隨分析告警監護人監管分析應用側呵護名單配置中監護名單活動區域圍欄位置異常告警規則營銷類

39、應用：個體行為識別引擎漫入特征用戶識別流程舉例上圖為用戶漫入漫出的程序編排讀取kafka（公共位置模型）篩選目標地市的數據剔除常駐人口關聯目標用戶群，二次確認剔除已營銷用戶剔除免打擾用戶計算駐留時長駐留時長達到閾值，判定為個體行為識別用戶12345687經過抽象：通用邏輯引擎化口徑、參數配置化個體為識別引擎營銷類產品ETL基本數據處理通過工廠配置中心獲取醫院圍欄、白名單等維度信息，加載至Flink State并進行廣播，完成過濾外部數據引入類應用：個體行為識別引擎ODS北京醫保核驗規則使用Flink State,以及定義以下三種規則并組合為一個CEP事件進行匹配計算白名單用戶在指定醫院范圍的夜

40、晚住院駐留時長（外部數據引入）核驗白名單用戶在指定醫院是否存在醫保刷卡記錄（外部數據引入）核驗白名單用戶在指定醫院是否存在住院記錄DWD 基本數據流個為識別引擎DWS醫保核驗結果醫保局報銷保險公司審計部應用側通過OLAP分析，和數據傳遞，完成業務閉環醫保刷卡記錄醫院住院記錄醫院圍欄信息核驗人白名單醫保核驗規則配置中心FlinkCEPETL基本數據處理通過工廠配置中心獲取景區及交通樞紐圍欄維度信息，以及需核驗省市，加載至Flink State并進行廣播，完成過濾關聯Redis中用戶畫像標簽（如：年齡、性別等），以及常住地標簽剔除物聯網及工作地/居住地用戶智慧文旅類應用：群智感知識別引擎ODS北京

41、根據游/旅客識別規則，通過Flink時間窗口計算分析：計算用戶于景區及交通樞紐駐留時長計算符合規則的駐留用戶為游/旅客根據游/旅客數據，計算輸出景區及交通樞紐實時游/旅客人流量、實時人口熱力、實時人群畫像DWD 基本數據流群體感知識別引擎DWS區域游客分析旅廳/局交通廳/局應用側通過OLTP數據庫實現應用邏輯：游客總量變化趨勢畫像游客變化趨勢游客量變化環比/同比等交通樞紐圍欄游/旅客識別規則景區圍欄信息配置中ODS 戶畫像標簽+位置標簽Redis想象空間：封裝更多引擎實時位置監控人員行為分析人員考勤管理異常位置告警服務政法：小區內服刑服務防汛：短信智能告警服務經濟：商圈分析短信任務管理短信號碼

42、清單計算短信號碼推送短信任務發送統計商圈客流分析商圈競對分析商圈通勤分析TOP小區客流分析未來展望深空智能方面的工作布局推進基于Flink+Paimon的湖倉一體的改造整合層明細層匯總層應用層數據源增量數倉（Paimon）OLAPDoris實時大屏翼點觸達社區矯正OLTP明細層ES.安全出湖API明細層匯總層離線數倉（Paimon）實時數倉（kafka）整合層應用層Hbase匯總層應用層對外服務批計算入湖增量計算入湖實時計算批/流批/流流流流批/流批/流批/流批/流計算流計算批計算kafka234G位置信令聯機工單白名單位置.秒級延遲分鐘級延遲小時級延遲批批整合層45G MR翼支付位置標簽數據

43、.ftp/hdfs批2024下半年，已完成調研和測試，符合業務要求滿足規劃指引使用Paimon建設增量數倉和離線數倉保留多引擎的Kafka實時鏈路復用多引擎思路到分鐘級的增量數倉，支持定制化分析計劃2025年構建秒級延遲、分鐘級延遲、小時級延時，三個維度的湖倉一體的時空服務能力n 長期來看，根據3GPP組織（第三代合作伙伴計劃）在2024年6月凍結的 Release 18 的最新通信協議，未來通訊大網將融合低軌衛星互聯網、5G6G基站、室分室內等定位能力，增加包含大模型、深度學習構建的通導感一體、空天地全域、軟硬結合的“三位一體”的業務場景（比如低空經濟），電信時空智能系統會有進一步加快發展。

44、n 后期，電信時空系統會為大家帶來更多的最佳實踐分享【網絡數據中臺（子系統）】提供精定位（三角定位、TOA/AOA定位、指紋定位）和粗定位（基站定位）【基站主動定位平臺（子系統）】提供基站主動定位【室分定位系統（子系統）】室內用戶精準定位【企業級位置服務系統（主系統）】定位能力：提供融合定位（4/5G融合定位、AOI/POI定位、軌跡定位、室內定位等）能力；服務能力：內外部數據融合，通用服務能力/智能化能力的構建、應用場景/業務的支撐；數據與服務的產、監、管、用、評一體化的數據運營數據安全體系【行業應用場景】智慧文旅、智慧城市、智慧交通、應急保障等【衛星定位】用戶納米/米級定位【感知終端】手持

45、終端、車載終端、飛行器終端、艦船終端、物聯網終端等目標3：軟硬一體n 泛化終端按需集成、聯合研發目標2：空天地一體n 衛星+456G網絡+行業定位網絡目標1：通導感一體n 通信+導航+感知一體化智能服務通用能力沉淀服務能力調用一體化運營監控體系THANK YOU謝 謝 觀 看Hologres+Flink+Paimon面向未來的一體化實時湖倉架構設計姜偉華阿里云實時數倉Hologres負責人第一代實時數倉：面向業務開發建設特點典型Lambda架構，采集-加工-服務根據業務煙囪化建設數據架構不分層，以任務為單位支撐應用場景據預處理完畢，存儲到OLAP和KV引擎架構痛點隨著業務場景復雜度增加，運維開

46、發成本越來越高全部預處理方式要求每個開發同學E2E加工，不能適應業務變化第二代實時數倉：面向數倉開發建設特點引入OLAP引擎：小數據量明細、輕度匯總存儲在MPP數據庫，支持OLAP Query數據分層：在DWD層按照主題將數據源整合，構建可復用的DWS層，減少煙囪化。架構痛點任務重復建設：由于存儲/服務多樣，不可避免在不同任務和引擎中沉淀煙囪化業務邏輯。數據存儲冗余：不同業務SLA不同，KV引擎和OLAP根據SLA拆分多實例，造成數據冗余和更高運維開發成本。元數據管理：KV Schema Free，元數據管理難第三代實時數倉：面向一站式實時數倉開發建設特點統一存儲：公共明細層、公共匯總層，應用

47、明細層、應用匯總層集中存儲。統 一 服 務：接 口 一 致、OLAP、KeyValue 統一接口。簡化實時鏈路：無外部消息中間件，內置Binlog事件驅動訂閱，原生全鏈路實時驅動。關鍵收益支持自助分析、秒級響應全鏈路狀態可見，深度洞察問題根因，快速定位問題組件更少，依賴更少，降低成本Hologres+Flink：第三代實時數倉架構FlinkFlinkFlinkDashboardsDWDODSHologresDWSHologresHologresbinlogbinlogHologres Binlog類似于傳統數據庫的Binlog，用來記錄單表數據修改的日志，記錄INSERT、DELETE、BEF

48、ORE UPDATE、AFTER UPDATE四種事件類型，提供了表的增量變化信息通過 Flink 全增量消費Hologres表，加工后再寫入Hologres，實現全鏈路數據的實時流動架構優勢 解決傳統中間層Kafka數據不易查、不易更新、不易修正的問題。每一層都可查、可修正 中間層不僅供Flink消費，還可以直接對接OLAP/在線服務等消費 數據復用，模型統一，架構簡化Hologres 與 Flink深度集成實時計算FlinkHologres維表維表查詢維表百萬RPS查詢維表實時可更新場景：離線維表、實時特征Hologres Catalog元數據查詢&更新元數據服務整庫同步Schema Ev

49、olution全量讀取Binlog讀取CDC讀取全增量一體化讀取Hologres源表流批一體CDC全鏈路實時觸發實時寫入與更新寬表MergeDDL變更同步整庫同步Hologres結果表強大的實時寫入能力與整行更新能力，完美匹配Flink寬表局部更新，簡化多流Join實時湖倉的架構應該什么樣？實時湖倉應該具備的能力統一的存儲管理在存儲層需要統一，既能存儲大量歷史數據，又能快速接入實時數據流，實現數據的統一管理和查詢。4生命周期管理與查詢服務需要確保數據的時效性、一致性和可查詢性。這通常涉及到復雜的數據管道設計和實時查詢服務的構建5低延遲與高吞吐量在保證數據處理準確性的基礎上，實現低延遲的實時處理

50、能力和高吞吐量的大規模數據處理能力，以滿足不同場景下的業務需求6統一的數據模型流和批都基于相同的數據模型進行操作，確保歷史數據和實時數據的分析結果具備一致性和可比性1共享的處理邏輯流和批共享相同的業務邏輯和算法，減少了開發和維護成本，無需維護兩套代碼2靈活的計算引擎同一個計算引擎需要能夠同時支持批、實時、近實時處理，自動調整處理方式，實現批流統一處理3？Hologres+Flink+Paimon一體化實時湖倉Hologres External Database統一元數據管理Hologres計算資源存儲資源2.查詢加速1.元數據映射4.數倉分層3.ETL5.讀寫1CREATE EXTERNAL

51、DATABASE dlf_paimon_catalogWITH metastore_type dlf-paimon catalog_type paimondlf_region cn-hangzhou dlf_catalog clg-paimon-dc758349b48a4e9e;3INSERT INTO dlf_paimon_catalog.default.sink_tblSELECT*FROM source_tblWHERE ds=to_char(CURRENT_DATE,YYYY-MM-DD);4CREATE DYNAMIC TABLE ads_repo_infoWITH(refresh_

52、mode=streaming)ASSELECT repo_name,COUNT(*)AS eventsFROM dwd_github_eventsGROUP BY repo_name;2FlinkEMRMeta Store表格式DLFHive MetaStoreDELTA LAKEICEBERGHUDIPAIMONDataLakeMaxComputeExternal DatabaseDynamic TableWorkersHologres+Paimon 實時湖倉的最佳組合OLAP分析CDC 入湖流批一體變更日志流讀索引能力優化寬表合并HologresHologresHologresHologr

53、esHologres+Paimon 核心特性極致性能支持讀取 Deletion VectorC+直讀查詢性能優化統一元數據支持增刪改查 Paimon 表統一元數據管理當前唯一能消費Changelog的OLAP產品消費 Paimon Changelog增量/流式構建 Dynamic Table增量消費支持寫入 Paimon 表支持輕量 ETLETL來源：社區技術文檔Hologres+Paimon VS Trino+Paimon051015202530354045501 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22Trino 422H

54、ologres V3.0.5600%在 TPC-H 標準測試集上查詢 Paimon 表，同等計算資源下，Hologres V3.0.5相比Trino 422有6倍以上的性能提升Hologres+Paimon 湖倉分析提速1x base6x10 x提速Data lakePaimonTrino/Presto 查詢Hologres外表查詢l查詢優化器 lHQE 向量查詢引擎lC+直讀lDeletion Vectorl多級緩存lShard/Partition PruninglLocal joinlBitmap IndexlClusteringlRuntime Filter提速Data lake Pai

55、monData lake PaimonHologres內表查詢Hologres Dynamic Table+Paimon一體化實時湖倉分層Hologres Dynamic Table：多模式統一計算一份數據、一份SQL、一份計算刷新模式全量（V3.0）增量（V3.0）流式（TBD）時效性小時級分鐘級秒級應用場景定期報表歷史回刷近實時數據分析實時數據分析、風控Serverless運行支持支持不支持成本低中高應用層數據源實時采集離線全量同步統一SQL服務計算層存儲層ODS層DWD層DWS層ADS層數倉分層加工Hologres Dynamic Table實時計算流式刷新（Streaming）增量刷新

56、（Incremental）增量計算全量刷新（Full）全量計算Hologres內置高性能存儲OpenLake湖倉存儲OLAP查詢AI與大模型在線服務日志服務MySQL數據庫消息事件 解決實時數倉分層等強需求 實現性能、成本、時效性等的完美平衡Hologres Dynamic Table 技術原理引擎會保證3種模式的SQL語義一致，計算邏輯盡量復用，計算層統一；聲明式數據處理架構，引擎自動管理數據pipeline；Hologres本身具備一體的存儲；無需額外配置資源，可按需選擇本實例、serverless資源執行計算，資源層統一；全量數據結果物化全量刷新（Batch）增量刷新（Increment

57、al）流式刷新（Streaming）列存狀態表(State)存聚合結果數據編碼優化，微批次處理聚合結果，Merge+update緩存優化減少IO實時處理聚合結果，Merge+update本實例計算資源Serverless資源Hologres存儲（熱存、冷存）計算存儲全量數據增量數據增量數據行存狀態表(State)Dynamic Table全量刷新（Full）具備OLAP的所有技術能力優化多種算子，自適應agg、join等場景增量刷新（Incremental）內置列存state表維護存量聚合結果，數據編碼優化，提升增量數據與狀態表Merge性能基于Hologres對多表事務能力保證Failove

58、r時數據正確性Bulkload增量更新dynamic table提升微批寫入性能流式刷新（Streaming）-待發布內置行存state表，優化緩存機制減少IO，提升實時點查更新能力Checkpoint機制保證Failover時數據正確性內置算法優化，提升增量數據與狀態表的merge性能執行刷新Hologres Dynamic Table 多模式統一計算一份數據、一份SQL、一份計算，多種刷新模式，滿足不同的業務時效性要求CREATE DYNAMIC TABLE ads_repo_infoWITH(refresh_mode=incremental,incremental_auto_refres

59、h_interval=1 mins)ASSELECTrepo_name,COUNT(*)AS eventsFROMdwd_github_eventsGROUP BYrepo_name;增量刷新（Incremental）CREATE DYNAMIC TABLE ads_repo_info WITH(refresh_mode=streaming)ASSELECTrepo_name,COUNT(*)AS eventsFROMdwd_github_eventsGROUP BYrepo_name;流式刷新（Streaming）CREATE DYNAMIC TABLE ads_repo_infoWITH(

60、refresh_mode=full,full_auto_refresh_interval=1 hours)ASSELECTrepo_name,COUNT(*)AS eventsFROMdwd_github_eventsGROUP BYrepo_name;全量刷新（Full）Dynamic Table+Serverless：數據自動流動、彈性、隔離實時數倉HologresFlink實時數據離線數據MaxCompute數據湖Paimon/OSSDWD同步（增量/流式刷新）DWSADS回刷（全量刷新）同步（增量/流式刷新）回刷（全量刷新）Serverless Computing Pool可將Dyna

61、mic Table的刷新任務以Serverless方式執行執行不占用實例資源，任務間相互隔離。更加穩定、更高效率、更低成本Dynamic Table 增量和全量刷新都支持 Serverless 模式執行Dynamic Table 多模式消費 Paimon 的 ChangelogCREATE DYNAMIC TABLE commerce_taobao_adv_behavior_summaryPARTITION BY LIST(ds)AS WITH(refresh_mode=Incremental,orientation=column,distribution_key=behavior_type,

62、)ASSELECTds,behavior_type,COUNT(*)AS total_behavior_count,COUNT(DISTINCT user_id)AS uv_countFROMmerce_taobar_adv_benavior_log behavior_logWHERE user_profile.shopping_level 1GROUP BY ds,behavior_typeORDER BY ds,behavior_type讀取 Paimon 表的 Changelog 生成數據2024 雙11大促淘天集團核心業務案例 Hologres Dynamic Table 多模式統一計

63、算Hologres內表DWDDWSHologres Dynamic TableADSHologres Dynamic TableDynamic Table流式刷新Dynamic TableT+1全量回刷Hologres Dynamic TableDynamic TableT+1全量回刷Dynamic Table增量刷新營銷分析報表活動數據監控實時直播看板實時風控Dynamic Table流式刷新Dynamic TableT+1全量回刷E2E時效性：秒級E2E時效性：分鐘級成本降低50%200%開發效率成本降低70%回刷延遲減少80%Paimon 湖表DWDADS應用淘寶直播（全倉案例）淘天營銷

64、活動分析（湖倉案例）應用數據源Flink數據源FlinkDemo：Hologres+Flink+Paimon 實時湖倉分層主要流程1.DLF建表，External Database自動映射元數據2.Flink 消費 SLS 的 Github Events 半結構化數據，實時寫入 Openlake(Paimon)3.Hologres 直接加速查詢Paimon數據4.Hologres創建增量Dynamic Table 解析JSON字符，半結構化數據轉結構化數據5.增量Dynamic Table轉換為流式Dynamic Table6.歷史數據歸檔到 Openlake(Paimon)7.使用MaxCo

65、mpute、EMR、Flink等二次消費歸檔數據，數據在多引擎自由流轉Github Events 半結構化 日志數據數據源Flink消費SLS實時寫入DWD-增量Dynamic TableOpenLake湖倉數據存儲 ODS-Paimon表 DWD-湖倉加速查詢消費 ChangelogVDWD-流式Dynamic Table轉換刷新模式數據歸檔VV二次消費HologresMaxComputeE-MapReduce實時計算Flink版湖倉數據分層與消費原生支持 JSONDemo：Hologres+Flink+Paimon 實時湖倉分層湖倉建表，元數據映射1.通過External Database

66、在Hologres創建Catalog，映射DLF Catalog2.在Catalog中創建Database存放數據3.在Openlake（Paimon表）中創建表，并開啟Paimon Changelog，后續供Hologres消費Hologres CatalogDLF CatalogDemo：Hologres+Flink+Paimon 實時湖倉分層Hologres加速查詢Paimon1.Hologres可以直接查詢Paimon上的非結構化數據2.同時可以將半結構化數據轉換為結構化數據進行分析半結構化原始數據解析結構化數據Demo：Hologres+Flink+Paimon 實時湖倉分層生成多模

67、式Dynamic Table1.消費Paimon Changelog，創建DWD-Dynamic Table，從ODS-Paimon表增量刷新數據2.增量刷新時效性不滿足業務需求，將DWD-Dynamic Table刷新模式從增量切換為流式增量刷新Dynamic Table流式刷新Dynamic TableDemo：Hologres+Flink+Paimon 實時湖倉分層1.將DWD-Dynamic Table表寫回ODS-Paimon表，存入OpenLake2.歸檔數據由EMR-Spark 二次消費3.歸檔數據由MaxCompute 二次消費使用PySpark進行分析使用MaxCompute

68、 進行分析Hologres歸檔Paimon二次消費面向未來的一體化實時湖倉架構設計更好的湖倉一體使用體驗+多模式統一計算湖倉架構全倉架構DWDFlink+Binlog或Dynamic TableFlink+Binlog或Dynamic Table時效性高查詢性能強共享能力中固定報表OLAP分析自助分析ADS/DWSDWDDynamic Table 數倉分層Dynamic Table 數倉分層時效性中查詢性能中共享能力強External Database 元數據映射ODS固定報表OLAP分析自助分析ODSADS/DWS40+客戶案例合集：Hologres一體化實時湖倉平臺阿里云上客戶案例阿里巴巴

69、集團案例互聯網平臺小紅書曹操出行錢大媽新氧醫美諾亞財富來電科技輕松籌玩物得志游戲娛樂37手游樂元素TapTap心動玩吧軟件服務金蝶管易云萬里?？腿缭凭鬯稄V告營銷小邁科技飛書深諾物流交通遞四方運滿滿易倉快狗打車在線教育好未來新東方實時數倉CCO淘菜菜Lazada阿里媽媽菜鳥Aliexpress零售通交互式分析CCO菜鳥天貓國際淘特網絡部流量分析友盟Lazada淘天實時大屏飛豬淘天搜索推薦淘寶搜索搜推實時數倉搜推多維分析淘寶訂閱AI淘天掃碼查看（Hologres官網可查）免費試用5000CU時 100GB存儲THANK YOU謝 謝 觀 看基于Flink和Paimon構建Pulsar的大規模消息

70、追蹤平臺翟佳諳流科技CEOAbout MySelf翟佳(wechat_id:zhai-jia)：Co-Founder of AscentStreamCo-Founder of StreamNativeApache MemberApache Pulsar PMC member&CommitterApache BookKeeper PMC member&Committer背景介紹架構和實現總結和未來規劃背景介紹消息隊列發展歷程商業閉源時代 80年代，The Information Bus 90年代，IBM MQ開源時代，單機架構 開源崛起，標準形成 Active、RabbitMQ 傳統企業級應用互

71、聯網時代分布式架構 互聯網、電子商務爆發 大數據、互聯網中間件 Kafka、RocketMQ云計算時代，云原生架構 云原生 存算分離、批流統一 PulsarApache Pulsar 架構簡介云原生架構 1、存儲計算分離 2、節點對等 3、獨立擴容 4、邏輯分區、物理分片Apache Pulsar：存儲層 BookKeeper 分布式日志WriteAheadLog 低延遲、高吞吐、持久化 強一致性 高可用 讀寫隔離Apache Pulsar：InfoWorld 最佳開源軟件Apache Pulsar：社區狀態Committer 670+Star 14K+Apache Pulsar：深度使用于中

72、國頭部企業構建消息追蹤系統的必要性Platform構建消息追蹤系統的必要性ProducerProducerPlatform MaintainerConsumerConsumer背景介紹架構和實現總結和未來規劃架構和實現構建消息追蹤系統ProducerProducerConsumerConsumer構建消息追蹤系統：Interceptor ProducerProducerConsumerConsumerInterceptorInterceptorInterceptormessage_trace_topic構建消息追蹤系統：Pulsar IO ConnectorProducerProducerCo

73、nsumerConsumerInterceptorInterceptorInterceptormessage_trace_topic構建消息追蹤系統：Pulsar IO ConnectorPulsar IO Framework構建消息追蹤系統：Pulsar IO ConnectorPulsar Sink ConnectorPulsar Sink構建消息追蹤系統：Pulsar IO ConnectorPulsar Sink構建消息追蹤系統：Paimon+Flink ProducerProducerConsumerConsumerInterceptorInterceptorPaimonInterc

74、eptormessage_trace_topicPulsar Paimon SinkFlink SQL消息追蹤系統消息追蹤系統背景介紹架構和實現總結和未來規劃總結和未來規劃基于Paimon+Flink 的消息追蹤系統ProducerProducerConsumerConsumerInterceptorInterceptorPaimonInterceptormessage_trace_topicPulsar Paimon SinkFlink SQL實踐總結 1、Eat your own dog food；2、數據讀寫模式契合；3、降低存儲成本：消息（行存）到 Paimon（Parquet），5倍

75、成本節約；4、完善的生態，降低開發運維成本：Paimon 和 Flink 的無縫集成：安裝、使用、批流融合（SQL）可擴展的元數據：便于未來應用開發未來探索：基于 Paimon 探索 Pulsar 的層級存儲Pulsar Tiered StorageTHANK YOU謝 謝 觀 看社區資源微信公眾號:ApachePulsar/諳流科技網站:https:/pulsar.apache.org/https:/ Paimon x Spark 構建極速湖倉分析鄒欣宇Paimon CommitterPaimon x Spark 的發展歷程Paimon x Spark 極致查詢優化湖倉架構下的典型案例未來展

76、望與規劃Paimon x Spark 的發展歷程Paimon x Spark 的發展歷程 Streaming Source DML For PK Table Call Procedure極致讀寫優化完整流批能力新特性探索V 0.5V 0.6V 0.7V 0.8V 0.9V Insert Into/Overwrite Streaming Sink Schema Evolution Session Extension2023-092023-122024-022024-052024-092024-Compact/Zorder Merge Into Analyze table Query Optimi

77、zation Deletion Vector DML For Non-PK Table DV With Non-PK Table Bucket Join Dynamic Option Spark 4.0 Variant Data More Read/Write OptimizationPaimon 生態體系生態體系從從 DBMS 到到 LakeHouse面臨的挑戰ACID 事務數據更新寫入高性能應對Lake Format x Enginedata warehousedata lakedata lakehouseACID 事務事務時間旅行增量查詢Paimon 元數據架構Tag 和 Branch多

78、版本查詢多版本管理版本清理版本回滾TagBranch數據更新與寫入數據更新與寫入主鍵表非主鍵表基于 LSM 實時 Upsert(MOR)Merge EngineChange Log ProducerDelete/Update/Merge 支持 Deletion Vector大規模 Batch ProcessingZ-Order SortFile IndexDelete/Update/Merge(COW)支持 Deletion VectorPaimon x Spark 極致查詢優化元數據加載優化元數據加載優化緩存元數據（默認開啟）對象存儲場景，顯著降低 planning 耗時Caching Ca

79、talogscan read snapshots read manifests read file meta generate splitsplansplitsreaderDeletion Vector主鍵表面臨的問題 讀時 merge 非主鍵字段無法下推 并發受限于 bucket 數 native 引擎集成L2primary-key:idfilter:where c 10 and id=1f2 不能被 filter！id:1,c:5 c(min:0,max:7)bucket-0L3L1f1f2f3f4f5f6id:1,c:15 c(min:12,max:18)Deletion Vector3

80、-5 倍查詢性能提升 集成 native 引擎提升更大 bitmapbitmapf5:dv1,f6:dv2https:/cwiki.apache.org/confluence/display/PAIMON/PIP-16%3A+Introduce+deletion+vectors+for+primary+key+table 輕量 filter，no merge 解鎖非主鍵 filter 下推 讀并發不再受限于 bucket 數 native 引擎集成友好L2./bucket-0/L3L1f1f2f3f4f5f6./index/index-1id:1,c:5 id:1,c:15 標記刪除，通過 b

81、itmap 記錄被刪除的記錄的行號Scan IO 優化優化Partition PruningDynamic Partition PruningFile Meta(min,max)File Index(bloom,bitmap,.)Clustering(Hilbert,z-order,)Column PruningFilter Push DownScan IO 優化優化Nested Column Pruning支持 Struct、Map、Array 嵌套類型core 層通用 API 接口Scan IO 優化優化SELECT COUNT(*)查詢元數據快速返回結果Spark SQL 執行鏈路執行鏈

82、路3 個關鍵階段影響湖格式查詢性能：元數據加載；Query Optimization；Table Scan Spark 查詢優化查詢優化Spark:DPP,DSV2 Projection/Predicate/Limit Pushdown Session Extension:MergePaimonScalarSubqueries,EvalSubqueriesForDeleteTable RBOCBOjoin reorderhttps:/ 查詢優化查詢優化Bucket Join（Spark 3.3+支持）消除 shuffle/sort性能測試流式更新批分析TPC-H Tools5000萬全量1億更

83、新Lake House流式更新+合并MySQLTPC-DS ToolsCSV Files24 張表1TBLake House批 load99 queriesUser01234阿里云 Flink 流更新：TPC-H 流式更新+合并 總耗時PaimonHudiIceberg00.511.52阿里云 Spark 批更新：TPC-DS Load+Query 總耗時PaimonIcebergHudi以上測試基于阿里云商業化產品湖倉架構下的典型案例Open Lake House實際案例簡化技術棧，降低維護成本未來發展與規劃Spark 4 集成 引入 Spark3/4 common 層 通過 profile

84、 切換 Spark3/4 JDK 17,Scala 2.13 底層 API 接口改變 難點實現Variant Type 半結構化的數據需求日益增加 Json 靈活，但是解析慢 結構化數據解析快，但是不靈活 靈活，高效，開放 Shredding 列化后，查詢性能數量級提升VariantVariant測試版本已完成 Variant 和 Shredding 的集成Paimon 1.0 or 1.1 支持 Variant 類型！問題：寫入開銷，數據膨脹，嵌套類型讀性能 性能：復雜場景 2倍+提升，純讀 Json 場景 10倍+提升 現狀THANK YOU謝 謝 觀 看基于 TiDB+Flink 實時匯

85、聚平臺實踐李振環解決方案架構師TiDB 簡介和架構公司和架構原理TiDB&Flink 實時數倉TiDB&Flink 實時數倉場景分析和案例TiDB 通用場景選型TiDB 通用場景選型和案例TiDB 簡介和架構公司簡介和架構原理平凱星辰公司:自主開源&技術引領&國產化100%自主研發首批通過分布式數據庫安可評測軟件出海最大數據庫海外單筆訂單全球頂級開源數據庫項目Star 37200具有國際影響力的開源社區成熟可靠國外數據庫替換之選Oracle/MySQL4000+全球優質企業用戶新一代分布式數據庫引領者NewSQL/HTAP 愿景：成為世界上最好且最受尊重的基礎軟件公司 公司使命：為開發者和企業

86、賦能，以速度、敏捷、增長之道創新。TiDB是國內和全球高流行的分布式數據庫DB-Engines 關系型數據庫流行度全球排名#38，中國唯一進入 Top 50 的數據庫上榜工業和信息化部2023年工業和信息化發展情況三大具有國際影響力的開源社區之一PingCAP社區開源社區貢獻入選 2024 Gartner 云數據庫“客戶之聲”最高分選，是唯一獲得該稱號的中國廠商，PingCAP 連續三年入選該報告。2024年9月份，中國信息安全測評中心的安全可靠測評結果（2024年第2號）：平凱數據庫企業版軟件V7.1首批通過分布式數據庫安全可靠測評。圍XC名錄TiDB：眾多中國頭部企業的選擇金融&金融科技互

87、聯網科技運營商 零售 制造物流 地產 政企TiDB&Flink 實時數倉TiDB&Flink 實時數倉場景分析和案例TiDB 定位：基于 OLTP 的分布式數據庫高吞吐高擴展HTAP天然高可用超大號 MySQL多庫合一超大號 MySQL：應用透明、自動分片、彈性擴縮容HTAP：隔離性、一致性、高性能自主開源TiDB 技術架構計算層 TiDB對外提供 MySQL 協議接口，處理 SQL 請求，生成分布式執行計劃。集群大腦 PD管理元信息，存儲數據分布和集群拓撲，分配事務 ID，下發數據調度命令。存儲層 TiKV存儲數據，提供事務支持的 Key-Value 存儲引擎，維護數據副本。存儲層 TiFl

88、ash特殊存儲節點，以列式存儲數據，主要用于加速分析型場景。TiDB 架構特性:自動分片/彈性擴縮容/高可用將 SQL 和 Schema 映射到KV 數據數據按照主鍵排序Region Start key,End key)無需按照分庫分表做開發數據自動分片應用透明TiDB 無狀態、多活，在線擴縮容TiKV 多活在線擴縮容，PD 自動均衡可擴展任意節點數量，無需三節點或者成倍擴展彈性擴縮容高吞吐高擴展三副本強一致性同城三中心多活同城兩中心：RPO=0 DR Auto Sync/TiCDC兩地三中心金融級高可用天然高可用Store 5Store 6TiFlash node 1TiFlash node

89、 2列式存儲引擎計算層Region 1Region 3TiKV node 1Region 4Store 1Region 1Region 2TiKV node 2Region 3Store 2Region 3Region 1TiKV node 3Store 3Region 4Region 4Region 2Region 1Region 2TiKV node 4Store 4行式存儲引擎存儲層1.數據寫入（寫入/更新/刪除）：高并發實時、批量，均提供事務保障2.數據查詢（OLTP 明細、輕度匯總）：可合理設計索引數據查詢（匯總類）：基本已經無法設計索引時負載邏輯表order_main/dtl 表：

90、3 份全量行存數據（34:1 壓縮比）order_main/dtl 表：12份全量列存數據Raft Group 一張表同時擁有兩份存儲格式 行列異步同步，毫秒級延遲 列存只讀，具備 mpp 并行計算能力，查詢時校對確保一致性DDLTiDBTiDBTiDB缺省配置：優化器自動決定使用哪個引擎查詢僅訪問 tikv僅訪問 tiflashrwrwrwroroTiDBTiDBrwrwroTiDBTiDBTiDB HTAP 一體化架構:無需數據同步TiDB 高并發寫入吞吐優于 MySQL應用寫入流量主庫從庫從庫只讀只讀存儲引擎：InnoDB（B+Tree）隨機 IO 問題，隨著表數據增長，寫入效率急劇下降

91、性能優勢：一般在單表千萬較為明顯，單行數據越長越明顯負載均衡應用TiDBTiDBR1*TiKV 1R2*R3*R4R5R6R7R8R1TiKV 2R2R3R4*R5*R6*R7R8R1TiKV 3R2R3R4R5R6R7*R8*寫入流量寫入流量寫入流量分布式架構下：所有節點可讀可寫存儲引擎：LSMTree順序寫，寫入性能高；通過compact機制解決讀放大。主從架構下：寫入壓力集中在主庫TiDB大批量數據查詢性能優于 MySQLSQL 示例：select t2.v_type,sum(t1.k+t2.k)from t1 join t2 on t1.id=t2.id and t2.dt2023-0

92、6-01 00:00:01 group by t2.v_type;TiFlash 1Store 1TiDBTiFlash 2Store 21.t2 表多節點并行掃描+selection 過濾后，加載到節點內存中，并構建 hash table2.利用 hash 算法，將 t1 的數據從各個節點重分布到對應的 hash 桶中，完成關聯與分組3.將查詢結果返回給計算節點 TiFlash mpp hash join（0.5秒）MySQL 5.7 Nested-Loop Join（20秒）t2.ibdt1.ibd磁盤及緩存區域Join BufferMasterSlave 1Slave 2單線程Regio

93、n 1*Region 2TiKV node 1Region 3Store 1TiDBRegion 4Region 5*Region 6Region 1Region 2*TiKV node 2Region 3Region 4Region 5Region 6*Region 1Region 2TiKV node 3Region 3*Region 4*Region 5Region 61.t2 表多節點并行掃描+selection 過濾3.t1 表多節點并行掃描2.基于 t2 表構建 hash table4.關聯與分組TiKV hash join（5.57秒）Store 2Store 3TiDB VS

94、集中式 VS 中間件方案對比集中式(MySQL)中間件TiDB 分布式架構聯機交易吞吐受限硬件資源高，可擴展高，可擴展聯機交易延遲低低低批量處理能力受限硬件資源中高聯機查詢能力高，集中式架構高高匯總查詢能力高，集中式架構低高(實時查詢)多維度分析能力高，集中式架構低高(任意維度)應用適配能力高低，應用邏輯入侵高，對應用透明擴展能力低靜態擴展動態擴展DDL能力離線/在線離線（復雜）在線 DDL彈性伸縮低低高，在線伸縮高可用能力高中(基于主從復制)高(基于 Raft 強一致)容災能力同城災備+異地中(基于主從復制)高(基于 Raft 及調度)可觀測能力低中高研發成本低高（至少1名有經驗高級架構師規

95、劃，研發人員數量至少增加2人。）低（無需額外增加架構師，對開發沒有限制，開發更自由沒有限制）維護成本低高（至少增加2名高級DBA）低（原來的dba只需通過學習和實踐就能掌握。而且能維護多套分布式數據庫）TiDB VS AP 類數據庫方案對比GBASE MPPClickhouseTiDB技術架構列式存儲支持多副本列式存儲存算一體架構，支持多副本，1個副本對應1個數據節點行列混合存儲Raft多副本機制、存儲計算分離數據分布策略基于random或hash分片支持本地表與分布式表對應用透明的分片、數據路由策略分布式事務支持能力有限不支持原生支持彈性擴縮容支持在線擴展不擅長彈性擴縮容分片策略支持在線按需

96、擴縮計算和存儲節點高可用支持同城災備更適合單機房部署支持同城A-A模式，異地災備數據規模PB級PB級單集群百TB級并發吞吐能力中低并發，通常為幾十中等并發行存支持高QPS，列存支持中等并發實時分析數據重平衡hash分片擴縮容過程涉及數據重平衡，影響大不擅長，需人工介入支持，對業務幾乎無感業務侵入性random分片無侵入，hash分片有一定侵入適宜將涉及關聯的大表拼接成寬表進行操作業務透明，最大程度延續原先的數據模型和業務SQL高并發實時寫入和更新更適合離線批量導入更適合離線批量導入，對刪除和更新不友好支持，行存基于LSM-Tree的追加寫能力，列存基于Delta-Tree的快速寫入高并發單表查

97、詢不適合場景不適合場景支持，基于行存、二級索引實現單表多維度查詢，無業務侵入高并發關聯查詢不適合場景不適合場景支持，基于行存、二級索引實現，復雜SQL性能更優批量處理更適合T+1的離線加工，批量數據加載性能最優更適合T+1的離線加工更適合涉及多維度、跨分片的批量處理大數據分析性能PB級的MPP計算能力，性能優PB級的MPP計算能力，單表性能優，不適合大表間關聯TB級的復雜分析性能優，可支持實時更新數據的分析與大數據生態的集成支持與Hadoop平臺的互相備份、恢復，性能高支持HDFS、文件系統等作為外表與Spark、Flink生態深度集成，通過定制版SDK進行能力增強Flink 實時數倉架構數據

98、源用戶行為業務數據系統日志爬蟲數據維度數據MySQLFile數據采集LogstashCanalFlink CDC數據倉庫Kafka ODS Kafka DWD ETLHBase DWS Redis DWS ES APP TiDB APP Doris APP 實時應用實時分析實時風控實時推薦實時查詢架構復雜，依賴多套存儲和計算引擎實時數倉架構對比Lambda 架構Kappa 架構Flink 批流一體架構計算引擎流批兩套計算引擎流計算引擎批流計算引擎一體開發成本高，需要維護兩套代碼低，只需維護一套代碼低，只需維護一套代碼OLAP 靈活性中中高是否依賴實時 OLAP 引擎非強依賴非強依賴強依賴計算資

99、源需要批流兩套計算資源只需流計算資源流計算資源，實時OLAP 資源邏輯變更重算批處理重算消息隊列重算通過消息隊列重新導入OLAP 引擎Flink 目前更主流，強依賴批量一體和 OLAP 引擎數據同步工具：TiCDC&DM工具自身高可用模式運行保護分布式運行，支持任意規模 TiKV 集群毫秒級捕獲存儲層變化并異步復制到下游集群支持事務和下游事務的原子性ODS/DWD/DWSTiCDC Flink CDC變更流實時分層計算數據源DM/Flink CDCTiDB+Flink 實時數倉架構數據源用戶行為業務數據系統日志爬蟲數據TiDB+Flink 實時數據倉庫ODS實時應用實時分析實時風控實時推薦實時

100、查詢Flink流處理:事實表:TiDB-TiCDC-Kafka-Flink-TiDB，維度表:Flink+TiDB-TiDBFlink批處理：Flink Batch-TiDB-TiDBTiDB 數據處理：數據調度跑批加工+HTAP能力所有層數據都可以提供數據服務/分析數據服務DWDDWSAPPTiCDC+Flink批流一體TiCDC+Flink批流一體TiCDC+Flink批流一體調度批量加工調度批量加工調度批量加工數據服務數據分析數據服務統一視圖某衛健委：TiDB+Flink 全民健康平臺醫療數據互聯互通建立數據標準和服務標準，提高區域健康信息共享水平和醫療服務。時效性：在規定的時候內完成海

101、量數據收集、質量檢測和數據交換等數據處理擴展性：Oracle 無法支持海量數據快速處理使用 TiDB 替換 Oracle，完成衛生信息實時匯聚，統一標準，提供豐富數據服務如病人主索引，當前數據量 50TB一棧式支持高并發查詢、寫入和海量數據加工：日常QPS 1.5W，TiDB+TiFlash 支持海量數據加工處理，數據質控時效顯著提升：月數據質控效率從 2.5 小時縮減到 30 分鐘方案創新背景和需求商業價值實施結果某國有商業銀行：Flink+TiDB 金融市場交易庫Oracle1Oracle2Oracle3Oracle4KafkaFlinkTiDBFineBI數據服務接口OGG 或者國產代替

102、軟件使用 OGG+Flume 將 Oracle 數據實時通過 Kafka+Flink 將數據實時同步到 TiDB業務人員通過 FineBI 查詢 TiDB 對金融市場合約明細數據(包括歷史和實時數據)、匯總查詢或統計分析。實現每筆投資決策 10000使用 Flink 完成實時寬表數據加工支持領導駕駛倉和事后風控業務使用 TiDB HTAP 能力提供數據分析和數據服務接口DMTiCDCFlink CDC風控分析方案創新解決方案TiDB 通用場景TiDB 通用場景：數據庫選型說明TiDB 通用場景概述更好的用戶體驗更高的系統吞吐應對業務峰值高并發讀寫場景C端互聯網用戶系統穩定性系統金融級高可用減少

103、開發成本，提高敏捷性大型聯機交易系統場景企業重要核心系統數據時效性豐富數據使用場景簡化數據棧實時分析和查詢場景高價值數據使用簡化運維成本節約硬件投入，錯峰資源復用SAAS 場景多庫合一場景企業中小系統實時分析和查詢場景：中通快遞數據中臺痛點：海量數據高峰期遇到性能瓶頸T+1不滿足時效性實時數倉與現有技術棧不兼容Oracle 一體機成本高昂收益：10 數個消息匯聚：通過TiSpark同時匯聚 10+個 Topic，通過 TiSpark 實時寫入 TiDB在 TiDB 存儲 70+列的寬表：匯聚的多個消息通過 TiSpark 再與 Hive 維表 Join，打寬數據流后再寫入 TiDB 10 分鐘

104、處理3 億條數據：使用 TiSpark 只讀 TiKV 數據十分鐘讀取 3 條行數據，平均 50W qps高并發數據同步最高 2000W條每秒數據寫入支持快遞員和C端客戶高并發查詢 QPS 7W未來規劃全文索引更多向量索引類型元數據檢索過濾AI 向量化能力增強PD 微服務化大型 SAAS 場景支持百萬級別表數量穩定支持 500 TB+集群運行超大型集群規模TiProxy 真正無感知的擴縮容自動索引建議MySQL v8 特性進一步兼容生態和工具提升Cascades 優化器框架可擴展的并行 DDL 執行框架常用算子均可落盤穩定性和性能提升THANK YOU謝 謝 觀 看Apache Flink+D

105、orisReal-Time Lakehouse Solution陳明雨Apache Doris PMC ChairIntroductionWhat is Apache DorisLakehouse SolutionApache Flink+Paimon+DorisEcosystem Community&CloudIntroductionWhat is Apache DorisWhat is Apache DorisLightning FastLeading performance on benchmark likeClickBench,TPC-H,TPC-DSEasy to UseMulti-

106、ScenarioFriendly for first-time userwith low operational costThe only OLAP productionyou needVectorized query enginePipeline execution modelColumnar StorageCost based optimizerSecondary indexesMaterialized viewSmart CachingMySQL protocol compatibilityANSI SQLBare metal,EC2,K8s supportAuto balance an

107、d data repairFault tolerantReporting&Ad-hoc querySemi-structured data analysisReal-time data CRUDServingLakehouseWhy Choose Apache DorisApache Doris Use CasesHigh-concurrency reporting and analytics services with a large number of real-time user access,including marketing reports(ad exposure,clicks,

108、and spending),insurance analysis(insurance plan tailoring and customer conversion reporting),logistics dashboards(real-time analysis of logistics pressure,efficiency and customer complaints),and transaction reports(order,bill,and delivery queries).Real-Time Reporting&AnalyticsLog Management&Analytic

109、sData Lake AnalyticsFull-Text SearchJSON&Variant2X-5X Fast then ES.4X Storage savingPaimon,Iceberg,Hudi,HiveJDBC ConnectorFile CacheIO Optimization3X-5X Fast then TrinoLakehouse SolutionApache Flink+Paimon+DorisData Warehouse&Data LakeData Warehouse Structured data Inner storage format Predefined Sc

110、hema Proprietary storage system SQL Reporting&BI High performance Efficient data managementData Lake Structured,semi structured data Open storage format Schema-less HDFS,Object Storage API,NoSQL Data analysis,machine learning,etc.Non structured data support Open ecosystem Low storage cost High stora

111、ge cost Vendor lock-in Less flexibility Poor performance High data management costLambda&KappaLambda Separate Batch&Streaming Streaming Layer:Storm Batch Layer:Hadoop Serving Layer:Hive/Presto High operational cost Data inconsistentEarly Kappa Unified Batch&Streaming Streaming Layer:Flink Serving La

112、yer:Presto High cost on data changes Lack of historical data analysisKafkaStreaming/Speed LayerBatch LayerServingLayerKafkaStreaming/Speed LayerServingLayerBatch&StreamingHow to support efficient and low-costbatch&streaming processing integration?Warehouse&LakeData ChangesHow to supportflexible data

113、 changes?How to combinethe advantages of both?Challenges on LakehouseLakehouse SolutionApache Flink+Paimon+DorisApache Flink:Unified streaming&batch data processing.Apache Paimon:Support streaming&batch data ingestion and single source of truth.Apache Doris:High performance on lake data analysis and

114、 processing.Lakehouse SolutionReal-time Data IngestionApache Flink CDC+Apache DorisAuto Database SynchronizationAuto table creationAuto column mappingSynchronized schema changing in msExactly-Once SematicTwo phase commitPrimary key data modelMulti-stream JoinSupport partial column updateLakehouse So

115、lutionData UnboundQuery Acceleration and Data Processing on Lake FormatEnrich Paimon Feature SupportNative file readerDeletion vectorAliyun DLF&OSS-HDFS supportQuery AccelerationNative vectorized query engineData&metadata cachingMaterialized viewTransparent SQL rewritingLakehouse SolutionData Unboun

116、dQuery Acceleration and Data Processing on Lake FormatLakehouse SolutionLakehouse UnboundUnified Data Warehouse and Data LakeFree Flow of Lake&Warehouse DataMatching featuresOpen Storage APIUnified Metadata ManagementCatalogsData GovernanceData LineageData IntegrationEcosystemCommunity&CloudApache D

117、oris on CloudCloud Native Architecture in Apache Doris 3.0Metadata LayerExtensible high performance meta serverMulti-cluster managementGarbage CollectionCompute LayerLoad IsolationElasticSmart cachingStorage LayerLow storage costShared dataSingle source of truthApache Doris CommunityOne of the worlds most active big data open source communities650+Contributors120+Monthly Active ContributorsApache Doris Users獲得全球超過5000家中型企業的信賴，泛應于核線上分析場景FinanceTelecomGamingTransportRetailEnergyPan InternetWelcome to Doris CommunityDev Mailing List devdoris.apache.orgDoris 小助手如想進入社區用戶社群請備注 加群THANK YOU