UData+StarRocks在京東物流的實踐

来源:https://www.cnblogs.com/jingdongkeji/archive/2023/11/28/17861557.html
-Advertisement-
Play Games

數據服務與數據分析場景是數據團隊在數據應用上兩個大的方向,行業內大家有可能會遇到很多問題,數據服務和數據分析系統也是無法統一,分析產生的數據結果往往是離線的,需要額外開發數據服務,無法快速轉化為線上服務賦能外部系統,使得分析和服務之間難以快速形成閉環。而且在以往數據加工過程中存儲往往只考慮了當時的需... ...


1 背景

數據服務與數據分析場景是數據團隊在數據應用上兩個大的方向,行業內大家有可能會遇到下麵的問題:

1.1 數據服務

  • 煙囪式開發模式:每來一個需求開發一個數據服務,數據服務無法復用,難以平臺化,技術上無法積累
  • 服務維護難度大:當開發了大量數據服務後,後期維護是大問題,尤其是618、雙11大促期間,在沒有統一的監控、限流、災備方案的情況下一個人維護上百個數據服務是一件很痛苦的事,也造成了很大的安全隱患
  • 業務需求量大:數據開發的同學常常會被大量重覆枯燥的數據服務開發束縛,大量的時間投入在業務數據服務開發中

1.2 數據分析

  • 找數據難:用戶難以找到自己想要,即便找到名稱相近的指標或數據,由於指標口徑不明確也不統一也無法直接使用
  • 用數難:由於目前數據分佈在各個系統中,用戶無法用一個系統滿足所有的數據需求。特別是一線運營人員要通過每個從各個系統導出大量Excel的方式做數據分析,費時費力,同時也造成數據安全隱患
  • 查詢慢:用傳統的Olap引擎,用戶跑SQL往往需要幾分鐘才出結果,大大降低了分析人員的效率。
  • 查詢引擎不統一:系統可能有多種查詢引擎組成,每一種查詢引擎都有自己的DSL,增大了用戶的學習成本,同時需要跨多數據源查詢也是一件很不方便的事。異構查詢引擎帶來的另一個問題是形成了數據孤島,各系統間的數據之間無法相互關聯
  • 數據實時更新:傳統離線T+1方式數據更新已經無法滿足當今的實時化運營的業務訴求,這就要求系統需要到達秒級別的延遲

除了以上問題,數據服務和數據分析系統也是無法統一,分析產生的數據結果往往是離線的,需要額外開發數據服務,無法快速轉化為線上服務賦能外部系統,使得分析和服務之間難以快速形成閉環。而且在以往數據加工過程中存儲往往只考慮了當時的需求,當後續需求場景擴展,最初的存儲引擎可能不適用,導致一份數據針對不同的場景要存儲到不同的存儲引擎,帶來數據一致性隱患和成本浪費問題。

2 基於StarRocks 的數據服務分析一體化實踐

基於以上這些業務痛點京東物流運營數據產品團隊研發了服務分析一體化系統——UData(Universal Data),UData系統是以StarRocks引擎為技術基礎的實現的。UData把數據指標生成的過程抽象出來,用配置的方式低代碼化生成數據服務,大大降低的開發複雜性和難度,讓非研發同學也可以根據自己的需求配置和發佈自己數據服務,指標的開發時間由之前的一兩天縮短為30分鐘,大大解放了研發力。平臺化的指標管理體系和數據地圖的功能,讓用戶更加直觀和方便地查找與維護指標,同時也讓指標復用變成可能。

在數據分析方面,我們用基於StarRocks的聯邦查詢方案打造了UData統一查詢引擎,解決了查詢引擎不統一和數據孤島問題,同時StarRocks提供了強悍的數據查詢性能,無論是大寬表還是多表關聯查詢性能都十分出色。StarRocks提供數據實時攝入的能力和多種實時數據模型,可以很好的支持數據實時更新場景。UData系統把分析和服務結合在一起,讓分析和服務不再是分割的兩個過程,用戶分析出有價值的數據後可以立即生成對應的數據服務,讓服務分析快速閉環。

數據流程架構圖:

改造前的架構:


圖1 改造前架構圖

改造前實時數據由JDQ(京東日誌消息隊列,類似Kafka)和JMQ導入Flink做實時數據加工,加工後數據寫入Clickhouse和ElasticSearch,為數據服務和數據分析提供Olap查詢服務。離線數據由Spark做個數倉層級加工,APP層數據會同步至Mysql或Clickhouse做Olap查詢。此架構中,在數據服務和數據分析是兩個分隔的部分,分析工具由於要跨多數據源和不同的查詢語言做數據分析比較困難的,數據服務也是煙囪式開發。

改造後的架構:


圖2 改造後的架構

改造後,我們在數據存儲層引入了StarRocks,StarRocks提供了極速的單表和多表查詢能力,同時以StarRocks為基礎我們打造了統一查詢引擎,統一查詢引擎根據京東的業務特點增加數據源和聚合下推等功能,UData在統一查詢引擎的基礎上統一了數據分析和數據服務功能。

打造一款數據服務分析一體化系統對查詢引擎有比較高的要求,需要同時滿足:極速的查詢性能、支持聯邦查詢、實時與離線存儲統一。基於這三點要求,下麵我們就StarRocks極速的查詢性能的原因、我們對聯邦查詢的改造、實時場景的實踐展開討論。

2.1 StarRocks極速的查詢性能的原因

極速查詢的單表查詢:

StarRocks在極速查詢方面上做了很多,下麵著重介紹下麵四點:

  1. 向量化執行:StarRocks實現了從存儲層到查詢層的全面向量化執行,這是SR在速度上優勢的基礎。向量化執行充分發揮了CPU的處理能力。全面向量化引擎按照列式的方式組織和處理數據。StarRocks的數據存儲、記憶體中數據的組織方式,以及SQL運算元的計算方式,都是列式實現的。按列的數據組織也會更加充分的利用CPU的Cache,按列計算會有更少的虛函數調用以及更少的分支判斷從而獲得更加充分的CPU指令流水。另一方面,StarRocks的全面向量化引擎通過向量化演算法充分的利用CPU提供的SIMD指令。這樣StarRocks可以用更少的指令數目,完成更多的數據操作。經過標準測試集的驗證,StarRocks的全面向量化引擎可以將執行運算元的性能,整體提升3—10倍。
  2. 物化視圖加速查詢:在實際分析場景中,我們經常遇到分析上百億的大表情況,儘管SR性能優異但數據量過大查詢速度還是有影響的,此時在用戶經常聚合的維度加上了物化視圖,在不用改變查詢語句的情況下查詢速度提升10倍以上,SR智能化的物化視圖可以讓請求自動匹配視圖,無需手動查詢視圖。
  3. CBO:CBO(Cost-based Optimizer ) 優化器採用 Cascades 框架,使用多種統計信息來完善成本估算,同時補充邏輯轉換(Transformation Rule)和物理實現(Implementation Rule)規則,能夠在數萬級別執行計劃的搜索空間中,選擇成本最低的最優執行計劃。
  4. 自適應低基數優化:StarRocks可以自適的根據數據分佈,對低基數的字元串類型的列構建一張全局字典,用Int類型做存儲和查詢,使得記憶體開銷更小,有利於SIMD指令執行,加快了查詢速度。與此對應Clickhouse也有LowCardinality方式優化,只是需要在建表時候需要聲明,使用起來會麻煩一些。

極速的多表關聯:

在實時數據分析場景中只滿足單表極速查詢是不夠的,目前為了加速查詢速度行業內習慣於把多張表打成一張大寬表,大寬表雖隨度快,但是帶來的問題是極其不靈活,實時數據加工層是用flink將多表 join成一張表寫入大寬表,當業務方想修改或增加分析維度時往往數據開發周期過長,數據加工完成後發現已經錯過了分析最佳時機。所以需要更靈活的數據模型,比較理想的方法是把大寬表模式退歸回星型模型或者雪花模型。在此場景下查詢引擎對多表數據關聯查詢的性能成了關鍵,以往clickhouse以大寬表為主,多表聯查情況下無法保證查詢相應時間,甚至有很大幾率出現OOM。SR很好解決了這個問題,大表join性能提升3~5倍以上,成為星型模型分析利器。CBO(Cost-based Optimizer )是多表關聯極致性能關鍵,同時StarRocks 支持Broadcost Join、Shuffle Join、Bucket shuffle Join、Colocated Join、Replicated Join等多種join方式,CBO可以智能的選擇join順序和join方式。

2.2 對StarRocks聯邦查詢的改造

在存儲層層由於需求、場景、歷史等原因是很難做到真正統一的存儲的,在過去的數據服務開發中由於存儲層不統一、資料庫查詢語法不同,開發基本是煙囪式開發,已開發的指標很難復用,也很難管理大量的已開髮指標。聯邦查詢可以很好的解決這個問題,使用統一的查詢引擎屏蔽了不同olap的引擎的專有DSL,大大提升了開發效率和學習成本,同時可以用ONE SQL方式整合來自不同數據源的指標形成新的指標,從而提高了指標的復用性。StarRocks外表擴展功能讓它具備了實現聯邦查詢的基礎,但細節上我們有一些自己的業務需求。

StarRocks在聯邦查詢上支持了多種外表如ES、Mysql、hive、數據湖等,已經有了很好的聯邦查詢的基礎。不過在實際的業務場景需求中,一些聚合類的查詢需要從外部數據源拉取數據再聚合,而且這些數據源自身的聚合性能也不錯,這反而增加了查詢時間。我們的思路是讓這部分擅長聚合的引擎自己做聚合,把聚合操作下推到外部引擎,目前符合這個優化條件的引擎有:Mysql、ElasticSearch、Clickhouse。同時為了相容更多的數據源,我們還增加了 JSF(京東內部RPC服務)/HTTP 數據源,下麵簡單介紹下這兩部分:

1.Mysql、ElasticSearch的聚合下推功能

現在StarRocks對於聚合外部數據源的方案是拉取謂詞下推後的全量的數據,雖然謂詞下推後已經過濾一部分數據但是把數據拉取到StarRocks再聚合是一個很重的操作,導致聚合時間不理想。我們的思路是下推聚合操作,讓外部表引擎自己做聚合,節省數據拉取時間,同時本地化聚合效率更高。聚合下推的優化在某些場景下有10倍以上的性能提升。


圖3 物理計劃優化圖

在物理執行計劃層我們做了再次優化,當遇到ES、Mysql、clickhouse的聚合造作時,會把ScanNode+AGGNode的執行計劃優化為QueryNode,QueryNode為一種特殊的ScanNode,與普通的ScanNode區別為QueryNode會直接把聚合查詢請求直接發送到對應外部引擎,而不是scan數據後在本地執行聚合。其中EsQueryNode我們會在FE端就生成ES查詢的DSL語句,直接下推到BE端查詢 。在同時在BE端我們實現了EsQueryNode 和MysqlQueryNode這兩種QueryNode。

2.增加 JSF(京東內部RPC服務)/HTTP 數據源

數據服務中可能會涉及到整合外部數據服務和復用原先已開髮指標的場景,我們的思路是把JSF(京東內部RPC服務)/HTTP也抽象成StarRocks的外部表,用戶可以通過SQL像查詢資料庫一樣訪問數據服務,這樣不僅可以復用老的指標還可以結合其他數據源的數據生成新的複合指標。我們在FE和BE端同時增加JSF和HTTP 兩種ScanNode。

2.3 實時場景的實踐

京東物流實時數據絕大多數屬於更新場景,運單類數據會根據業務狀態的改變而改變,下麵介紹我們在生產中的三種實時更新方案:

方案一:基於ES的實時更新方案

原理如下:

  1. 內部先get獲取document
  2. 記憶體中更新老的document
  3. 將老的document標記為deleted
  4. 創建新的document

優點:

  • 支持數據實時更新,可以做到partail update

缺點:

  • ES 聚合性能較差,當出現多個聚合維度時查詢時間會很長
  • ES 的DSL語法增加了開發工作,雖然ES可以支持簡單SQL但是無法滿足複雜的業務場景
  • 舊數據清理難,當觸發compaction物理刪除標記位文檔的時候會觸發大量的io操作,如果此時寫入量又很大,嚴重影響讀寫性能

方案二:基於clickhouse實現準實時的方案

原理如下:

  1. 使用ReplacingMergeTree 的方式實現
  2. 將Primary key相同的數據分發到同一個數據節點的同一個數據分區
  3. 查詢時做Merge on read ,合併多版本數據讀取

優點:

  • clickhouse 寫入基本是append寫入,所以寫入性能強

缺點:

  • 由於讀取時做版本合併,查詢和併發性能較差
  • clickhouse的join性能不佳,會造成數據孤島問題

方案三:基於StarRocks主鍵模型的實時更新方案

原理:StarRocks收到對某行的更新操作時,會通過主鍵索引找到該條記錄的位置,並對其標記為刪除,再插入一條新的記錄。相當於把Update改寫為Delete+Insert。StarRocks收到對某行的刪除操作時,會通過主鍵索引找到該條記錄的位置,對其標記為刪除。這樣在查詢時不影響謂詞下推和索引的使用, 保證了查詢的高效執行。查詢速度比Merge on read方式快5-10倍。

優點:

  • 只有唯一版本數據,查詢性能強,實時更新
  • 雖然Delete+Insert在寫入性能有輕微損失,但總體上還是十分強悍
  • Mysql協議,使用簡單

缺點:

  • 目前版本在數據刪除上有一些限制,無法使用delete語句進行刪除,新版本中社區會增加此功能

實時更新場景總的來說有以下幾種方案:

  1. Merge on read :StarRocks 的聚合、Unique模型和Clickhouse的ReplacingMergeTree、AggregatingMergeTree都是用的此方案。此方案特點是append方式寫入性能好,但是查詢時需要合併多版本數據導致查詢性能不佳。適合數據查詢性能要求不高的實時分析場景。
  2. Copy on write :目前一些數據湖系統如hudi、iceberg都有copy on write 的方案現實,此方案原理是當有更新數據後,會合併新老數據並重寫一份新的文件替換掉老文件,查詢時無需做merge操作,所以查詢性能很好。帶來的問題是寫和數據合併的操作很重,所以此方案不適合實時性強的寫入場景。
  3. Delete and insert:此方案是upsert 方案,通過記憶體中的主鍵索引定位要更新的行,標記刪除然後插入。在犧牲了部分寫入性能的情況下,帶來查詢上數倍於Merge on read 的提升,同時也提升了併發性能。

實時更新在Olap領域一直是一個技術難點,以往的解決方案很難同時具備寫入性能好、讀取性能好、使用簡單這幾個特性。StarRocks的Delete and insert方式目前更接近於理想的方案,在讀寫方面都有很優秀的性能,支持Mysql協議使用上簡單友好。同時離線分析Udata也是用StarRocks完成,讓我們實現了實時離線分析一體化的目標。

3 後續方向

數據湖探索:批流一體已經成為今後發展的大趨勢,數據湖作為批流一體的存儲載體已經成為標準,我們以後大方向也必然是批流一體。目前批流一體中一個大痛點問題是沒有一種查詢引擎可以在數據湖上做極速查詢,後期我們會藉助SR打造在湖上的極速分析能力,讓批流一體不只停留在計算階段。
架構圖如下:

圖4 後期計劃架構圖

  • 實時數據存儲統一:目前系統中還是有多套實時存儲方案,運維成本還是相當高,後期我們會逐步把ES、Clickhouse替換為StarRocks,在實時層做到存儲統一。我們也很期待StarRocks後期關於主鍵模型支持detele語句方式刪除數據的Feature,這個Feature可以簡化目前的數據清除問題。
  • 支持更多的數據源:今後我們還會支持更多的數據源,如Redis、Hbase等kv類型的Nosql資料庫,增強SR的點查能力。
  • StarRocks集群間的聯邦查詢:在實際生產中很難做到只用一個大集群,特別是當實時有大量實時寫入的情況,比較安全的做法是拆分不同的小集群,當一個集群出問題時不會影響其他業務。但是帶來的問題是,集群間可能又會變為數據孤島,即便把StarRocks偽裝成Mysql創建外表,但也需要工具去同步各個集群的表結構等信息,管理起來費時費力,後續我們也會和社區討論如何實現集群間的聯邦功能。

作者:京東物流 張棟 賀思遠

來源:京東雲開發者社區 自猿其說Tech 轉載請註明來源


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • SqlSugar是一個輕量級ORM框架,專門用於.NET平臺,可以簡化資料庫操作,提高開發效率。它支持多種資料庫,包括MySQL、SqlServer、Oracle等,提供了豐富的功能和靈活的配置選項。 下麵將詳細介紹SqlSugar的使用方法及其相比其他ORM框架的優點。 一、SqlSugar的安裝 ...
  • 3)搭建企業內部 Yum 倉庫 利用 HTTPD 搭建 企業內部私有倉庫。 [ 虛擬機演示:掛載一個新的 CD 光碟鏡像源 ] 1)CD 光碟 鏡像源 // `scandisk` 掃描新加的磁碟 echo '- - -' > /sys/class/scsi_host/host0/scan echo ...
  • 1、Linux文件系統結構 Linux:是一個單根倒樹狀的文件系統結構 Windows:是多根多樹狀的文件系統結構 文件系統從根目錄開始,表示為一個單獨的 ‘ / ’ 字元 文件命名大小寫敏感 路徑以 ‘ / ’ 為分隔 2、 Linux重要目錄 /root:超級用戶root的家目錄(用戶文件預設存 ...
  • 通過包管理器安裝 MySQL ubuntu安裝 MySQL 1、配置APT源 ubuntu自己的APT源裡面就有MySQL,以ubuntu2004為例,可以直接用相關源就行了,也可以導入MySQL的官方源。 阿裡雲鏡像源地址:https://developer.aliyun.com/mirror/ ...
  • Proj4:改進LiteOS中物理記憶體分配演算法 實驗目的 掌握LiteOS系統調用的自定義方法 實驗環境 Ubantu和IMX6ULL mini 實驗內容 (從代碼角度詳細描述實驗的步驟和過程) 原先代碼: 1 /* 2 3 * Description : find suitable free bl ...
  • 十二生肖狗年財運預測,你的財源滾滾來? 今年是狗年,按照中國傳統文化,狗年是一個財運井噴的年份。那麼,哪些生肖在這個狗年裡會財源滾滾呢?我們可以利用數據挖掘工具,通過API介面來獲取數據,對於不同生肖在狗年中的財運進行分析預測。 在本篇文章中,我們將使用挖數據平臺提供的API介面來獲取關於十二生肖狗 ...
  • SQL UNION運算符 SQL UNION運算符用於組合兩個或多個SELECT語句的結果集。 每個UNION中的SELECT語句必須具有相同數量的列。 列的數據類型也必須相似。 每個SELECT語句中的列也必須按照相同的順序排列。 UNION語法 SELECT column_name(s) FRO ...
  • LSM-Tree Doris的存儲結構是類似LSM-Tree設計的,因此很多方面都是通用的,先閱讀瞭解LSM相關的知識,再看Doris的底層存儲與讀取流程會清晰透徹很多,如下是幾個關鍵的設計: SSTable: Sorted Strings Table; 一般由一組數據block和一組元數據bloc ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...