DataFun：2025年AI+for+Data：智能數(shù)據(jù)處理與分析實戰(zhàn)報告

下載資料免掃碼關注公眾號下載資料免掃碼關注公眾號小紅書圖數(shù)據(jù)庫在分布式并行查詢上的探索 1快手關于海量模型數(shù)據(jù)處理的實踐 25嗶哩嗶哩基于Iceberg的智能數(shù)據(jù)組織優(yōu)化實踐 41京東零售數(shù)據(jù)可視化平臺產(chǎn)品實踐與思考 58虎牙平臺數(shù)據(jù)驅動業(yè)務實踐，破局在即！ 73騰訊PCG搜廣推機器學習框架GPU性能優(yōu)化實踐 91火山引擎DataLeap計算治理自動化解決方案實踐和思考 106火花思維數(shù)據(jù)分析體系建設和實戰(zhàn)分享 121頁碼：1/137小紅書圖數(shù)據(jù)庫在分布式并行查詢上的探索導讀：小紅書作為一個社區(qū)屬性為主的產(chǎn)品，涵蓋了各個領域的生活社區(qū)，并存儲海量的社交網(wǎng)絡關系。為了解決社交場景下的應用痛點以及分布式并行查詢實現(xiàn)中的問題，我們自研了面向超大規(guī)模社交網(wǎng)絡的圖數(shù)據(jù)庫系統(tǒng)REDgraph，大大提高了系統(tǒng)的查詢效率和性能。本次分享的內容主要包括五個部分：1.背景介紹2.原架構問題分析3.分布式并行查詢實現(xiàn)4.總結與展望5.問答環(huán)節(jié)分享嘉賓｜李凝瑞（薯名：再興）小紅書分布式數(shù)據(jù)庫架構師編輯整理｜張進東內容校對｜李瑤出品社區(qū)｜DataFun背景介紹頁碼：2/1371.圖數(shù)據(jù)庫介紹關于圖數(shù)據(jù)庫的概念，這里不作詳細闡述。而是以圖表的形式，對其與另外幾種NoSQL產(chǎn)品進行比較。圖數(shù)據(jù)庫本身歸屬于NoSQL存儲，而諸如KV類型、寬表類型、文檔類型、時序類型等其他NoSQL產(chǎn)品，各自具備獨特的特性。從上圖左側的坐標軸中可以看到，從KV到寬表、文檔，再到圖，數(shù)據(jù)關聯(lián)度和查詢復雜度是越來越高的。前三者，即KV、寬表和文檔，主要關注的是單個記錄內部的豐富性，但并未涉及記錄間的關系。而圖數(shù)據(jù)庫則專注于處理這些關系。圖數(shù)據(jù)庫主要適用于需要挖掘深鏈路或多維度關系的業(yè)務場景。頁碼：3/137接下來通過一個具體示例，再來對比一下圖數(shù)據(jù)庫與關系型數(shù)據(jù)庫。這是社交網(wǎng)絡中常見的一種表結構，包括四個數(shù)據(jù)表：用戶表、好友關系表、點贊行為表以及筆記詳情表。比如要查詢Tom這個用戶的好友所點贊的筆記的詳細信息，那么可能需要編寫一段冗長的SQL語句。在該SQL語句中，涉及到三個join操作，首先將用戶表和好友關系表進行連接，從而獲取Tom的所有好友信息。然后，將得到的中間結果與點贊行為表進行連接，以確定Tom的好友都點贊了哪些筆記。最后，還需要對先前生成的臨時表和筆記詳情表進行連接，以便最終獲取這些筆記的全部內容。CPU資源、內存空間以及IO，雖然我們可以通過精心的設計，例如針對所要關聯(lián)的列創(chuàng)建索引，以降低掃描操作的比例，通過索引匹配來實現(xiàn)一定程度的性能提升。然而，這樣的舉措所產(chǎn)生的成本相對較高，因為所有新的場景都需要創(chuàng)建索引，要考慮如何撰寫SQL中的join條件，選擇哪個表作為驅動表等等，這些都需要耗費大量的精力和時間。頁碼：4/137而如果采用圖數(shù)據(jù)庫，則會簡單很多。首先進行圖建模，創(chuàng)建兩類頂點，分別為用戶和筆記，同時創(chuàng)建兩類邊，一類是好友關系，即用戶到用戶的邊；另一類是用戶到筆記的點贊關系。當我們將這些數(shù)據(jù)存儲到圖數(shù)據(jù)庫中時，它們在邏輯上呈現(xiàn)出一種網(wǎng)狀結構，其關聯(lián)關系已經(jīng)非常明確。查詢時，如上圖中使用Gremlin'Tom')，用于定位Tom節(jié)點，兩個out子句，第一個out子句用于查找Tom的好友，第二個out子句用于查找Tom的點贊筆記。當?shù)诙€out子句執(zhí)行完畢后，就可以遍歷所有外部的綠色頂點，即筆記節(jié)點。最后，讀取它們的content屬性。可以發(fā)現(xiàn)，與關系型數(shù)據(jù)庫相比，圖數(shù)據(jù)庫的查詢語句更加簡潔、清晰易懂。此外，圖數(shù)據(jù)庫還有一個更為顯著的優(yōu)勢，就是在存儲時，它已經(jīng)將頂點及其關系作為一等公民進行設計和存儲，因此在進行鄰接邊訪問和關系提取時，效率極高。即使數(shù)據(jù)規(guī)模不斷擴大，也不會導致查詢時間顯著增加。2.圖數(shù)據(jù)庫在小紅書的使用場景頁碼：5/137小紅書是一個年輕的生活方式共享平臺。在小紅書，用戶可以通過短視頻、圖片等方式，直觀地記錄生活的點點滴滴。在小紅書內部，圖數(shù)據(jù)庫被廣泛應用于多種場景中，下面將分別列舉在線、近線以及離線場景的實例。第一個案例是社交實時推薦功能。小紅書具有典型的社區(qū)特性，用戶可以在其中點贊、發(fā)布貼文、關注他人、轉發(fā)信息等。譬如我進入某用戶主頁并停留了較長時間，那么系統(tǒng)便會判定我對該用戶有興趣，而這個用戶可能同樣吸引了他人的注意。因此，系統(tǒng)會將該用戶的其他關注者以及他們所關注的其他用戶推薦給我，因為我們有共同的興趣愛好，所以他們的關注內容我也有可能感興趣，這便是一種簡單的實時推薦機制。第二個案例是社區(qū)風控機制，小紅書社區(qū)會對優(yōu)質筆記或優(yōu)質視頻的創(chuàng)作者進行獎勵，但這也給了一些羊毛黨可乘之機，他們發(fā)布一些質量較低的帖子或筆記，將其發(fā)布在互刷群中，或者轉發(fā)給親朋好友，讓他們點贊和轉發(fā)，從而偽裝成所謂的高質量筆記，以此來騙取平臺的獎勵。社區(qū)業(yè)務部門擁有一些離線算法，能夠對已有的數(shù)據(jù)進行分析，識別出哪些用戶和筆記屬于作弊用戶，在圖中用紅色的點標出。在近線場景中，系統(tǒng)會判斷每個頂點在多跳關系內接觸到的作弊用戶的數(shù)量或比例，如果超過一定的閾值，則會將這個人標記為潛在的風險用戶，即黃色的頂點，進而采取防范措施。第三個案例是離線任務的調度問題，在大數(shù)據(jù)平臺中，往往存在大量的離線任務，而任務之間的依賴關系錯綜復雜，如何合理地調度任務，成為一個棘手的問題。圖結構非常適合解決這類問題，通過拓撲排序或其他算法，可以找出最受依賴的任務，并進行反向推理。3.業(yè)務上面臨的困境頁碼：6/137小紅書在社交、風控及離線任務調度等場景中均采用了圖數(shù)據(jù)庫，然而在實際應用過程中遇到了諸多挑戰(zhàn)。在此，簡要介紹其中基于實時推薦場景的一個痛點。業(yè)務訴求是能即時向用戶推送可能感興趣的“好友”或“內容”，如圖所示，A與F之間僅需經(jīng)過三次跳躍即可到達，因此A與F構成了一種可推薦的關聯(lián)關系，如果能即時完成此推薦，則能有效提升用戶使用體驗，提升留存率。然而，由于先前REDgraph在某些方面的能力尚未完善，業(yè)務一直只采用了一跳和兩跳查詢，未使用三跳，風控場景也是類似。業(yè)務對時延的具體要求為，社交推薦要求三跳的P99低于50毫秒，風控則要求三跳的P99低于200毫秒，這是目前REDgraph所面臨的一大難題。那為何一至二跳可行，三跳及以上就難以實現(xiàn)呢？對此，我們基于圖數(shù)據(jù)庫與其他類型系統(tǒng)在工作負載的差異，做了一些難點與可行性分析。頁碼：7/137首先在并發(fā)方面，OLTP的并發(fā)度很高，而OLAP則相對較低。圖的三跳查詢，服務的仍然是在線場景，其并發(fā)度也相對較高，這塊更貼近OLTP場景。其次在計算復雜度方面，OLTP場景中的查詢語句較為簡單，包含一到兩個join操作就算是較為復雜的情況了，因此，OLTP的計算復雜度相對較低。OLAP則是專門為計算設計的，因此其計算復雜度自然較高。圖的三跳查詢則介于OLTP和OLAP之間，它雖不像OLAP那樣需要執(zhí)行大量的計算，但其訪問的數(shù)據(jù)量相對于OLTP來說還是更可觀的，因此屬于中等復雜度。第三，數(shù)據(jù)時效性方面，OLTP對時效性的要求較高，必須基于最新的數(shù)據(jù)提供準確且實時的響應。而在OLAP場景中則沒有這么高的時效要求，早期的OLAP數(shù)據(jù)庫通常提供的是T+1的時效。圖的三跳查詢，由于我們服務的是在線場景，所以對時效性有一定的要求，但并不是非常高。使用一小時或10分鐘前的狀態(tài)進行推薦，也不會產(chǎn)生過于嚴重的后果。因此，我們將其定義為中等時效性。最后，查詢失敗代價方面。OLTP一次查詢的成本較低，因此其失敗的代價也低；而OLAP由于需要消耗大量的計算資源，因此其失敗代價很高。圖查詢在這塊，頁碼：8/137更像OLTP場景一些，但畢竟訪問的數(shù)據(jù)量較大，因此同樣歸屬到中等?？偨Y一下：圖的三跳查詢具備OLTP級別的并發(fā)度，卻又有比一般OLTP大得多的數(shù)據(jù)訪問量和計算復雜度，所以比較難在在線場景中使用。好在其對數(shù)據(jù)時效性的要求沒那么高，也能容忍一些查詢失敗，所以我們能嘗試對其優(yōu)化。正如前面提到的，在小紅書，三跳查詢的首要目標還是降低延遲。有些系統(tǒng)中會考慮犧牲一點時延來換取吞吐的大幅提升，而這在小紅書業(yè)務上是不可接受的。如果吞吐上不去，還可以通過擴大集群規(guī)模來兜底，而如果時延高則直接不能使用了。原架構問題分析第二部分將詳述原體系結構中所存在的問題及其優(yōu)化措施。1.RedGraph整體架構REDgraph的整體結構如上圖所示，其與當前較為流行的NewSQL，如TiDB頁碼：9/137的架構構相似。采用了存儲和計算分離的架構，并且存儲是shared-nothing的。三類節(jié)點分別為meta-server，元信息的管理；query-server，用戶查詢請求的處理；store-server，存儲數(shù)據(jù)。2.RedGraph圖切分方式圖切分的含義為，如果我們擁有一個巨大的圖，規(guī)模在百億到千億水平，應該如何將其存儲在分布式集群之中，以及如何對其進行切分。在工業(yè)界中，主要存在兩種典型的切分策略，即邊切分和點切分。邊切分，以頂點為中心，這種切分策略的核心思想是每個頂點會根據(jù)其ID進行哈希運算，并將其路由到特定的分片上。每個頂點上的每條邊在磁盤中都會被存儲兩份，其中一份與起點位于同一分片，另一份則與終點位于同一分片。如上圖中的例子，其中涉及到ABC三個頂點的哈希定位結果。在這個例子中，A至C的這條出邊，被放置在與A同一個節(jié)點上。同樣，B至C的出邊跟B放到了一起，最后一個桶中保存了C以及C的入邊，即由A和B指向C的兩條入邊。頁碼：10/137點切分，與邊切分相對應，以邊為中心，每個頂點會在集群內保存多份。這兩種切分方式各有利弊。邊切分的優(yōu)點在于每個頂點與其鄰居都保存在同一個分片中，因此當需要查詢某個頂點的鄰居時，其訪問局部性極佳；其缺點在于容易負載不均，且由于節(jié)點分布的不均勻性，引發(fā)熱點問題。點切分則恰恰相反，其優(yōu)點在于負載較為均衡，但缺點在于每個頂點會被切成多個部分，分配到多個機器上，因此更容易出現(xiàn)同步問題。REDgraph作為一個在線的圖查詢系統(tǒng)，選擇的是邊切分的方案。3.優(yōu)化方案1.0我們之前已經(jīng)實施了一些優(yōu)化，可以稱之為優(yōu)化方案1.0。當時主要考慮的是如何快速滿足用戶需求，因此我們的方案包括：首先根據(jù)常用的查詢模式提供一些定制化的算法，這些算法可以跳過解析、校驗、優(yōu)化和執(zhí)行等繁瑣步驟，直接處理請求，從而實現(xiàn)加速。其次，我們會對每個頂點的扇出操作進行優(yōu)化，即每個頂點在向外擴展時，對其擴展數(shù)量進行限制，以避免超級點的影響，降低時延。此外，我們還完善了算子的下推策略，例如filter、sample、limit等，使其盡頁碼：11/137可能在存儲層完成，以減少網(wǎng)絡帶寬的消耗。同時，我們還允許讀從節(jié)點、讀寫線程分離、提高垃圾回收頻率等優(yōu)化。然而，這些優(yōu)化策略有一個共性，就是每個點都比較局部化和零散，因此其通用性較低。比如第一個優(yōu)化，如果用戶需要發(fā)起新的查詢模式，那么此前編寫的算法便無法滿足其需求，需要另行編寫。第二個優(yōu)化，如果用戶所需要的是頂點的全部結果，那此項也不再適用。第三個優(yōu)化，如果查詢中本身就不存在這些運算符，那么自然也無法進行下推操作。諸如此類，通用性較低，因此需要尋找一種更為通用，能夠減少重復工作的優(yōu)化策略。4.新方案思考如上圖中，是對一個耗時接近一秒的三跳查詢的profile分析。我們發(fā)現(xiàn)在每一跳產(chǎn)出的記錄數(shù)量上，第一跳至第二跳擴散了200多倍，第二跳至第三跳擴散了20多倍，表現(xiàn)在結果上，需要計算的數(shù)據(jù)行數(shù)從66條直接躍升至45萬條，產(chǎn)出增長速度令人驚訝。此外，我們發(fā)現(xiàn)三跳算子在整個查詢過程中占據(jù)了較大的比重，其在查詢層的耗時更是占據(jù)了整個查詢的80%以上。頁碼：12/137那么應該如何進行優(yōu)化呢？在數(shù)據(jù)庫性能優(yōu)化方面，有許多可行的方案，主要分為三大類：存儲層的優(yōu)化、查詢計劃的優(yōu)化以及執(zhí)行引擎的優(yōu)化。由于耗時大頭在查詢層，所以我們重點關注這塊。因為查詢計劃的優(yōu)化是一個無止境的工程，用戶可能會寫出各種查詢語句，產(chǎn)生各種算子，難以找到一個通用且可收斂的方案來覆蓋所有情況。而執(zhí)行引擎則可以有一個相對固定的優(yōu)化方案，因此我們優(yōu)先選擇了優(yōu)化執(zhí)行引擎。圖數(shù)據(jù)庫的核心就是多跳查詢執(zhí)行框架，而其由于數(shù)據(jù)量大，計算量大，導致查詢時間較長，因此我們借鑒了MPP數(shù)據(jù)庫和其他計算引擎的思想，提出了分布式并行查詢的解決方案。原有的多跳查詢執(zhí)行流程如上圖所示。假設我們要查詢933頂點的三跳鄰居節(jié)點ID，即檢索到藍圈中的所有頂點。經(jīng)過查詢層處理后，將生成右圖所示執(zhí)行計劃，START表示計劃的起點，本身并無實際操作。GetNeighbor算子則負責實際查詢頂點的鄰居，例如根據(jù)933找到A和B。后續(xù)的Project、InnerJoin以及Project等操作均為對先前產(chǎn)生的結果進行數(shù)據(jù)結構的轉換、處理及裁剪頁碼：13/137等操作，以確保整個計算流程的順利進行。正是后續(xù)的這幾個算子耗費的時延較算子的物理執(zhí)行過程如上圖所示。查詢服務器（QueryServer）執(zhí)行START指令后，將請求發(fā)送至存儲節(jié)點（StoreServer）中的一個，該節(jié)點獲取其鄰居信息，并反饋至查詢層。查詢層接收到結果后，會對其中的數(shù)據(jù)進行去重或其他相關處理，然后再次下發(fā)，此次的目標是另外兩個StoreServer。這一步驟即為獲取二度鄰居的信息，返回至查詢層后，再對這些結果進行匯總和去重處理，如此往復。在整個流程中，我們明顯觀察到三個問題。首先，圖中藍色方框內的算子都是串行運行的，必須等待前一個計算完成后，才能執(zhí)行下一個。對于大規(guī)模的數(shù)據(jù)，串行執(zhí)行的效率顯然無法與并行執(zhí)行相提并論。其次，QueryServer內部存在一個同步點，即左側標注為紅色的字（等待所有響應返回要求queryServer等待所有存儲節(jié)點的響應返回后，才能繼續(xù)執(zhí)行后續(xù)操作。若某一存儲節(jié)點的數(shù)據(jù)量較大或負載過高，導致響應速度較慢，則會耗費大量時間在等待上，因此我頁碼：14/137們考慮取消同步等待的過程。最后，存儲層的結果需要先轉發(fā)回查詢層進行簡單處理，然后再向下發(fā)送，這無疑增加了不必要的轉發(fā)成本。如果存儲節(jié)點（StoreServer）能夠自行轉發(fā)，便可避免一次網(wǎng)絡轉發(fā)過程，從而降低開銷。相應的解決策略便是三點：算子并行執(zhí)行，取消同步點，以及讓StoreServer的結果直接轉發(fā)?；诖?，我們提出了如下的改造思路。首先，查詢服務器（QueryServer）將整個執(zhí)行計劃以及執(zhí)行計劃所需的初始數(shù)據(jù)傳輸至存儲服務器（StoreServer之后StoreServer自身來驅動整個執(zhí)行過程。以StoreServer1為例，當它完成首次查詢后，便會根據(jù)結果ID所在的分區(qū)，將結果轉發(fā)至相應的StoreServer。各個StoreServer可以獨立地繼續(xù)進行后續(xù)操作，從而實現(xiàn)整個執(zhí)行動作的并行化，并且無同步點，也無需額外轉發(fā)。需要說明的是，圖中右側白色方框比左側要矮一些，這是因為數(shù)據(jù)由上方轉到下方時，進行了分區(qū)下發(fā)，必然比在查詢服務器接收到的總數(shù)據(jù)量要少?？梢钥吹剑诟鞑糠知毩Ⅱ寗雍?，并未出現(xiàn)等待或額外轉發(fā)的情況，QueryServer頁碼：15/137只需在最后一步收集各個StoreServer的結果并聚合去重，然后返回給客戶端。如此一來，整體時間相較于原始模型得到了顯著縮短。分布式并行查詢實現(xiàn)分布式并行查詢的具體實現(xiàn)，涉及到多個關鍵元素。接下來介紹其中一些細節(jié)。1.如何保證不對1-2跳產(chǎn)生負優(yōu)化首先一個問題是，在進行改造時如何確保不會對原始的1-2跳產(chǎn)生負優(yōu)化。在企業(yè)內部進行新的改造和優(yōu)化時，必須謹慎評估所采取的措施是否會對原有方案產(chǎn)生負優(yōu)化。我們不希望新方案還未能帶來收益，反而破壞了原有的系統(tǒng)。因此，架構總體上與原來保持一致。在StoreServer內部插入了一層，稱為執(zhí)行層，該層具有網(wǎng)絡互聯(lián)功能，主要用于分布式查詢的轉發(fā)。QueryServer層則基本保持不變。這樣，當接收到用戶的執(zhí)行計劃后，便可根據(jù)其跳數(shù)選擇不同的處理路徑。若為頁碼：16/1371至2跳，則仍沿用原有的流程，因為原有的流程能夠滿足1-2跳的業(yè)務需求，而3跳及以上則采用分布式查詢。2.如何與原有執(zhí)行框架兼容第二個關鍵問題是如何維持與原有執(zhí)行框架的兼容性，即在進行分布式技術改造時，不希望對原有代碼進行大幅修改，而希望通過最小化的調整達到目的。這里參考了其他產(chǎn)品的一些思路，具體來說，就是在一些需要切換分區(qū)訪問的算子（如Forward、Converge和Merge。Forward的作用顯而易見，即當遇到任何運算符時，表示數(shù)據(jù)需要轉發(fā)給其他節(jié)點處理，而當前節(jié)點無法繼續(xù)處理。Converge運算符則是在整個執(zhí)行計劃的最后一步添加，用于指示最終結果應返回至最初接收用戶請求的節(jié)點。在Converge后，還需添加一個Merge運算符，該節(jié)點在收到結果后需要進行聚合操作，然后才能將結果返回給客戶端。如此修改后，我們只需實現(xiàn)這三個算子本身，無需對其他算子進行任何修改，且不會對網(wǎng)絡層造成干擾，實現(xiàn)了極輕量級的改造。在執(zhí)行計劃修改的過程中，我們頁碼：17/137還進行了一些額外的優(yōu)化，例如將GroupBy、OrderBy等算子也進行了下推處3.如何做熱點處理第三問題是如何進行熱點處理，或者說是重復ID的處理。當整個執(zhí)行流程改造成由StoreServer自行驅動之后，會出現(xiàn)一種情況，例如邊AC和邊BC位于兩個不同的StoreServer上，查詢都是單跳的操作，可能左側的機器查詢AC操作更快，而右側的機器查詢BC操作較慢，因此導致左側的機器首先查找到C，GetNeighborfromC，右側的節(jié)點雖然稍顯滯后，但也需要執(zhí)行查詢C鄰居操作。若不進行任何操作，在中間節(jié)點便會對C的鄰居進行兩次查詢，造成資源浪費。優(yōu)化策略非常簡單，即在每個存儲節(jié)點之上添加NeighborCache。本質是這樣一個Map結構，每當讀請求到來時，首先在Map中查找是否存在C的鄰節(jié)點，若存在則獲取，否則再訪問存儲層，訪問完畢后填充NeighborCache的頁碼：18/137掃碼關注公眾號免費下載資料條目，每個條目的生存時間都非常短暫。之所以短暫，其充分性在于左右節(jié)點發(fā)出請求的間隔肯定不會很久，不會達到數(shù)秒的級別，否則業(yè)務上也無法承受。因此，NeighborCache的每個條目也只需存活在秒級，超過則自動刪除。必要性則在于Map的Key的組合模式，即Vid+edgeType這種組合模式還是非常多的，若不及時清理，內存很容易爆炸。此外，查詢層從DiskStore中查詢到數(shù)據(jù)并向NeighborCache回填時，也需進行內存檢查，以避免OOM。4.如何做負載均衡第四個問題是怎么做負載均衡，包括兩塊，一個是存儲的均衡，另一個是計算的均衡。首先存儲的均衡在以邊切分的圖存儲里面其實是很難的，因為它天然的就是把頂點和其鄰居全部都存在了一起，這是圖數(shù)據(jù)庫相比其他數(shù)據(jù)庫的優(yōu)勢，也是其要承擔的代價。所以目前沒有一個徹底的解決方法，只能在真的碰到此問題時擴大集群規(guī)模，讓數(shù)據(jù)的哈希打散能夠更加均勻一些，避免多個熱點都落在同一個機器的情況。而在目前的業(yè)務場景上來看，其實負載不均衡的現(xiàn)象不算嚴重，例如免費下載資料掃碼關注公眾號免費下載資料頁碼：19/137風控的一個比較大的集群，其磁盤用量最高和最低的也不超過10%，所以問題其實并沒有想象中的那么嚴重。另外一個優(yōu)化方法是在存儲層及時清理那些過期的數(shù)據(jù)，清理得快的話也可以減少一些不均衡。計算均衡的問題。存儲層采用了三副本的策略，若業(yè)務能夠接受弱一致的讀?。▽嶋H上大多數(shù)業(yè)務均能接受我們可以在請求轉發(fā)時，查看三副本中的哪個節(jié)點負載較輕，將請求轉發(fā)至該節(jié)點，以盡量平衡負載。此外，正如前文所述，熱點結果緩存也是一種解決方案，只要熱點處理速度足夠快，計算的不均衡現(xiàn)象便不易顯現(xiàn)。5.如何做流程控制接下來的問題是如何進行流程控制。執(zhí)行流程轉變?yōu)橛蒘toreServer自行驅動之后，僅第一個Stage有Driver參與，而后續(xù)步驟則由Worker之間相互傳輸和控制。那么，Driver應如何了解當前執(zhí)行的階段以及其對應的某個Stage何時可以開始執(zhí)行呢？有一種解決方案便是要求每一個Worker在接收到請求免費下載資料掃碼關注公眾號免費下載資料頁碼：20/137后或下發(fā)請求后，向Driver回傳一個響應，如此便可在Driver內記錄所有節(jié)點的進度信息，這是可行的。然而，此設計方案較重，因為driver并不需要深入了解每個節(jié)點的具體狀態(tài)，它僅需判斷自身是否具備執(zhí)行條件，因此在工程實現(xiàn)中，我們采取了更為輕便的方式，即每個Stage生成一個32位的二進制數(shù)字reqId，將其發(fā)送至ACKer確認器以傳達相關信息。Acker也以32位整數(shù)形式記錄該信息，Stage1同樣會接收到Stage0發(fā)來的reqId，經(jīng)過內部一系列處理后，它會將接收到的reqId與自身生成的3個reqId進行異或運算，并將異或結果再次發(fā)送至確認器。由于異或操作的特性，當兩個數(shù)相同時，結果為0，因此，當0010數(shù)進行異或運算后，這部分將變?yōu)?。這就意味著Stage0已經(jīng)執(zhí)行完畢。后續(xù)的所有階段均采用類似的方式，當確認器的結果再次變?yōu)?時，表示整個執(zhí)行流程已經(jīng)完成，即前面的Stage0至Stage3已經(jīng)讀取完畢，此時可以執(zhí)行Stage4，從而實現(xiàn)流程驅動。另一個重要的問題便是全程鏈路的超時自檢，例如在Stage2或Stage3的某一個節(jié)點上運行時間過長，此時不能讓其余所有節(jié)點一直等待，因為客戶端已經(jīng)超時了。因此我們在每個算子內部的執(zhí)行邏輯中都設置了一些埋點，用以檢查算子的執(zhí)行是否超過了用戶側的限制時間，一旦超過，便立即終止自身的執(zhí)行，從而迅速地自我銷毀，避免資源的無謂浪費。以上就是對一些關鍵設計的介紹。6.性能測試我們在改造工程完成后進行了性能測試，采用LDBC組織提供的SNB數(shù)據(jù)集，生成了一個SF100級別的社交網(wǎng)絡圖譜，規(guī)模達到3億頂點，18億條邊。我免費下載資料掃碼關注公眾號免費下載資料頁碼：21/137們主要考察其一跳、二跳、三跳、四跳等多項查詢性能。根據(jù)評估結果顯示，在一跳和二跳情況下，原生查詢和分布式查詢性能基本相當，未出現(xiàn)負優(yōu)化現(xiàn)象。從三跳起，分布式查詢相較于原生查詢能實現(xiàn)50%至60%的性能提升。例如，在Maxdegree場景下的分布式查詢已將時延控制在50毫秒以內。在帶有Maxdegree或Limit值的情況下，時延均在200毫秒以下。盡管數(shù)據(jù)集與實際業(yè)務數(shù)據(jù)集存在差異，但它們皆屬于社交網(wǎng)絡領域，因此仍具有一定的參考價值。免費下載資料掃碼關注公眾號免費下載資料頁碼：22/137四跳查詢，無論是原始查詢還是分布式查詢，其時延的規(guī)模基本上都在秒至十余秒的范圍內。因為四跳查詢涉及的數(shù)據(jù)量實在過于龐大，已達到數(shù)十萬甚至百萬級別，僅依賴分布式并行查詢難以滿足需求，因此需要采取其他策略。然而，即便如此，我們所提出的改進方案相較于原始查詢模式仍能實現(xiàn)50%至70%的提升，效果還是很可觀的。總結與展望我們結合MPP的思想，成功地對原有REDgraph的執(zhí)行流程實現(xiàn)了框架級別上的革新，提出了一種較為通用的圖中分布式并行查詢方案。在完成改良后，至少在業(yè)務層面上，原本無法執(zhí)行的三跳任務現(xiàn)在得以實現(xiàn)，這無疑是一項重大突破。同時，通過實驗驗證，效率得到了50%的顯著提升。免費下載資料掃碼關注公眾號免費下載資料頁碼：23/137隨著小紅書DAU的持續(xù)攀升，業(yè)務數(shù)據(jù)規(guī)模正逐步向著萬億的規(guī)模發(fā)展。在這樣的大背景下，業(yè)務對多條查詢的需求也將日益強烈。因此，該方案本身具有優(yōu)化的潛力，具備落地的可能性，且有實際應用的場景。因此，我們將繼續(xù)致力于提升REDgraph的查詢能力。另外，盡管該方案主要在圖數(shù)據(jù)庫上實施，但其思想對于其他具有類似重查詢需求的在線存儲系統(tǒng)同樣具有一定的參考價值。因此，其他產(chǎn)品也可借鑒此方案，設計出符合自身需求的高效執(zhí)行框架。最后。我們誠摯地邀請對技術有著極致追求、志同道合的同學們加入我們的團隊。在此，我們特別推薦兩個渠道：一是掃描上方二維碼加入微信群，共同探討圖數(shù)據(jù)庫相關的技術問題；二是關注小紅書的技術公眾號REDtech，該公眾號會不定期發(fā)布技術文章，歡迎大家關注和轉發(fā)。問答環(huán)節(jié)Q：介紹中提到的LDBC-SF100那個數(shù)據(jù)集選擇測試樣本的規(guī)模有多大？免費下載資料掃碼關注公眾號免費下載資料頁碼：24/137另外，分布式方式能夠提升性能，但分布式實施過程中可能會帶來消息通信的成本開支，反而可能導致測試結果表現(xiàn)不佳，可否介紹一下小紅書的解決方法。A：三跳基本上都是在幾十萬的量級。關于分布式引發(fā)的消息通信，這確實是一個問題，但在我們的場景下，目前這還不是最嚴重的問題。因為每一跳，特別是三跳中產(chǎn)生的數(shù)據(jù)量是巨大的，計算算子處理這些數(shù)據(jù)量所需的時間已經(jīng)遠遠超過了消息通信的耗時。尤其是在多跳并存的環(huán)境中，比如一跳和二跳，其實它們作為中間結果其數(shù)據(jù)量并不大，一跳只有幾十上百個，二跳可能也就幾萬個，但是三跳作為最后的需要參與計算的結果直接到了幾十萬，所以通信開銷跟這個比起來，其實是非常微小的。在消息通信方面，我們也有一些解決思路，比如在發(fā)送端開一些很小的窗口（比如5毫秒）來做一些聚合，把那些目標點相同的請求進行聚合，這樣可以減少一些通信的請求次數(shù)。頁碼：25/137掃碼關注公眾號免費下載資料快手關于海量模型數(shù)據(jù)處理的實踐導讀：本文將分享快手對海量模型數(shù)據(jù)處理的實踐。（文章整理自2023年11月王靖的分享，數(shù)據(jù)具有即時性）主要介紹包括：1.模型場景介紹2.大規(guī)模模型數(shù)據(jù)處理3.大規(guī)模模型數(shù)據(jù)存儲4.展望分享嘉賓｜王靖快手推薦系統(tǒng)架構師編輯整理｜薛敏內容校對｜李瑤出品社區(qū)｜DataFun模型場景介紹1.實時大模型免費下載資料掃碼關注公眾號免費下載資料頁碼：26/137*本文數(shù)據(jù)具有即時性，不代表實時數(shù)據(jù)?？焓值哪Ｐ蛨鼍爸饕菍崟r的大模型。實時主要體現(xiàn)在社交上。每天都有新用戶上傳1500萬以上的視頻，每天有億級以上的直播活躍用戶，并且上傳數(shù)每年都在同比上漲。大主要體現(xiàn)在流量規(guī)模?？焓脂F(xiàn)在的日活達到了3.87億，有千億級別的日均曝光，百億級別的日均播放，模型量級非常大，還要保證實時。并且快手的核心價值觀是平等普惠，即千萬級的用戶同時在線時，個性化請求時會推薦不同的內容。總結起來，數(shù)據(jù)處理的特點是既大，又要實時。2.推薦業(yè)務復雜免費下載資料掃碼關注公眾號免費下載資料頁碼：27/137一般的推薦業(yè)務架構如上圖所示，在視頻池里（比如有幾千萬的視頻）會經(jīng)過固定的四個階段：（1）召回：從幾千萬的視頻里召回幾萬或者幾千的視頻；（2）粗排：通過一個粗排漏斗，選出幾千的視頻3）精排：幾千的視頻又會通過精排，篩選top幾百的視頻4）重排：進入重排，給出模型打分，做模型校驗；（5）返回：加上一些機制和多樣化操作，最后選出幾十個結果返回給用戶，整個漏斗要求非常高。快手的業(yè)務類型比較多樣，主要可以分成大型業(yè)務和中小型業(yè)務。大型業(yè)務的樣本量級很大，像主站推薦一天的樣本可能有千億，存儲能達到p的級別。迭代主要用流式迭代，即在線迭代特征和模型，速度會非?？臁Ｈ绻x用批式迭代的話，回溯樣本要30天，需要的資源是流式迭代的幾十倍，快手大場景下的流量分配又比較多，所以傾向于做在線的流式迭代實驗，速度快，消耗資源量相對也少很多。中小業(yè)務，一天的樣本大約在百億級別，存儲大概幾十T。選擇流式迭代會需要頻繁上線迭代，而且流量分配也不夠。這種情況下一般盡量選用批式迭代，此時免費下載資料掃碼關注公眾號免費下載資料頁碼：28/137需要很大量級的計算樣本，比如要回溯至少60天以上，回溯樣本能達到p級別。因為對于大模型來說，如果數(shù)據(jù)量不夠，模型訓練不充分，效果就會相應地下降。所以在這種小的業(yè)務場景里，還是傾向于批式迭代，回溯更多天的樣本，以使模型達到一個更穩(wěn)定的狀態(tài)。在這種場景下面，會傾向于批次迭代實驗。3.推薦模型的數(shù)據(jù)量這里是之前在快手發(fā)布的一個萬億級別模型文章里的截圖，快手是個性化模型，所以參數(shù)量非常大。從圖中對比來看，OpenAI的GPT3參數(shù)量是175B，但快手參數(shù)量1900B，已經(jīng)到萬億級別了。主要是因為快手選用的是SIM長序列模型，需要用戶長期的興趣，然后把該序列輸入到模型?？焓钟袃|級用戶，life-long興趣需10萬以上序列，再加上千億級的樣本的疊加，因此參數(shù)量非常大，能達到1.9萬億。雖然這1.9萬億參數(shù)跟OpenAI的GPT3模型的參數(shù)類型不一樣，計算量也不太一樣。但從參數(shù)量級上來看，快手推薦是非常大4.語言模型的演進免費下載資料掃碼關注公眾號免費下載資料頁碼：29/137推薦模型跟語言模型緊密相關，一般新模型都會在語言模型上去做迭代，成功之后就會引入推薦模型，比如DN、RNN、Transformer。上圖是亞馬遜3月份時發(fā)布的一個圖，主要介紹了語言模型的一些進展?？梢钥吹?，17年之前主要是RNN模型，RNN模型是按次序去順序遍歷數(shù)據(jù)后訓練，該模型對并行算力要求并不高，但模型收斂比較復雜，因為可能會存在梯度消失的問題。2017年出現(xiàn)Transformer之后，語言模型突破了原有的限制，可以做并發(fā)迭代，所以其算力大規(guī)模增長。圖中的樹分為三個部分1）紅線部分是encoder-only技術，最早是Bert模型2）綠線是encoder-decoder類型，Google主要選擇這一類型3）藍線主要是openAPI里ChatGPT選用的類型，這一類模型發(fā)展得最好，因為它足夠簡單，只需要考慮decoder，運算量小，而且模型效果也會很好。大規(guī)模模型數(shù)據(jù)處理免費下載資料掃碼關注公眾號免費下載資料頁碼：30/1371.背景-實效性快手對數(shù)據(jù)時效性要求很高，用戶看到視頻后會反饋到快手的log收集系統(tǒng)，該用戶的行為會實時地拼接推薦日志（推薦日志就是推薦服務落下來的特征特征流加上行為流成為樣本流進入后面的特征處理，然后進入模型訓練。模型訓練完成后實時更新到在線預估，在線預估會根據(jù)模型的更新推薦出最符合用戶需求的一些視頻。該鏈路要求延遲必須要在一秒內，需要將用戶行為盡快反饋到模型里，所以對于大數(shù)據(jù)處理的時效性要求是非常高的。2.大數(shù)據(jù)量處理免費下載資料掃碼關注公眾號免費下載資料頁碼：31/137快手有千萬級用戶在線，不考慮行為多樣性的情況下，QPS至少是千萬級的，如果區(qū)分到行為的多樣性，這個組合數(shù)量就更爆炸了，高峰期大概每秒需要處理30T左右的狀態(tài)。業(yè)界方案主要是采用Flink流式框架，但如果直接用Flink引入statejoin，在并發(fā)幾千的情況下會造成大量的慢節(jié)點。因為30T狀態(tài)如果1000并發(fā)的話，需要存30G的狀態(tài)，如果1萬并發(fā)也得存3G。3G在1萬并發(fā)下的慢節(jié)點的概率會非常大。在這種情況下如果出現(xiàn)慢節(jié)點，需要幾個小時恢復，這對于推薦系統(tǒng)肯定是不能忍受的。所以快手選擇了一個折中方案，把狀態(tài)下沉至高性能存儲上，然后采用無狀態(tài)hashjoin的方式來做一個實時join的狀態(tài)，只要用戶的行為和特征都到齊，就立即觸發(fā)樣本的下發(fā)，這樣就可以保證行為能夠及時地反饋到模型。雖然特征和行為來的順序不一樣，但通過外部的狀態(tài)，再加上Flink流式框架并行的操作，就能實現(xiàn)大規(guī)模高性能的join。3.復雜特征計算免費下載資料掃碼關注公眾號免費下載資料頁碼：32/137在上述處理完成之后，是特征計算場景，主要有兩種計算，標量計算和向量計算。標量計算類似于特征處理，比如要把某些值求和、求平均。在向量計算里，會對一批樣本同一列進行一個同樣的操作，放在GPU通過cuda計算。這樣，通過使用GPU和CPU協(xié)同的方式實現(xiàn)高性能計算，一些標量操作在CPU上計算，內存訪問也會在CPU上進行，然后傳輸?shù)紾PU上去做高性能的GPU計為了保證算法迭代的靈活性，采用了DSL抽象。因為SQL不能完全描述所有的特征處理場景。比如有一些在時間窗口的操作，如果通過SQL去做需要寫一些自定義的UDF，這樣很不利于迭代。所以我們的DSL是用Python描述的，用戶可以通過Python直接調用下層的高效執(zhí)行算子。第一步先寫計算層，使用C++實現(xiàn)一些高效的operator，包括cuda和CPU相關的計算也都是通過C++庫去做的。在runtime下面采用Flink的分布式框架加上GNI的方式去調用C++的這些算子，以達到高性能、高吞吐的處理。4.推薦場景特點免費下載資料掃碼關注公眾號免費下載資料頁碼：33/137推薦場景下有兩個特點，一個是批流一體，另一個是潮汐。批式調研和在線實驗這兩種場景會需要有批流一體，因為在批場景里調研特征或調研模型結構完成之后，需要到在線去做上線，因此需要有一個批流一體的統(tǒng)一描述語言加上統(tǒng)一的執(zhí)行引擎。用戶在批式上調研，會使用DSL、Hadoop和Spark把所有的數(shù)據(jù)計算出來，做模型迭代。模型迭代成功之后做特征上線，上線到流式通用特征處理框架上，或是上線到流式特征框架特化的一個處理框架上。這里之所以會分出兩個節(jié)點，主要是因為有一些特征是所有模型公用的，所以可能在通用的框架下面，這樣只需要計算一次。而在特化的算子下面則是一些模型所特有的特征，因此分開處理。但這兩個計算引擎和語言描述其實是一樣的。同樣地，這些通用處理的數(shù)據(jù)需要落盤到批場景下。批場景下有很多是基于base的特征去迭代，會加入它自己的性價特征，所以在批次場景下面計算的也是Delta。上線完之后就會到在線服務，這里會有一個高性能的存儲和計算庫去承接，這一點在后文中還會講到。在流式場景下，注重的是高吞吐、低延遲和高可用。在批免費下載資料掃碼關注公眾號免費下載資料頁碼：34/137場景下，主要關注高吞吐、高可靠。另外一個特點就是請求潮汐。上圖是請求潮汐的示意圖（并不是快手的真實流量）。從圖中可以看到，有早高峰和晚高峰兩個高峰。在高峰期需要給足在線的算力，在低峰期則要把冗余的算力利用起來。在這種情況下，快手的大數(shù)據(jù)處理框架以及在線所有的模塊需要針對潮汐的特點，去做云原生架構的一些改造，比如快速恢復、自動伸縮、快速伸縮?？焖偕炜s主要是因為在自動伸縮的時候并不能保證是高效的，比如一次自動伸縮需要耗一小時或者幾個小時之久，那么在線的請求在這幾個小時之間會有比較大的損失。另外，還需要把在線服務的資源池和大數(shù)據(jù)處理的資源池統(tǒng)一起來，這樣所有資源在低峰期時可以把冗余算力給批式場景、大模型預訓練場景或者大模型批量預估的場景，使資源得以利用?？焓脂F(xiàn)在所有的架構都在向云原生架構演進。大規(guī)模模型數(shù)據(jù)存儲免費下載資料掃碼關注公眾號免費下載資料頁碼：35/1371.存儲特點大規(guī)模數(shù)據(jù)存儲的第一個特點就是超低延遲，因為存儲節(jié)點存儲的都是狀態(tài)，一些計算節(jié)點需要很多的狀態(tài)信息才能去計算，所以存儲節(jié)點大部分時間都是在葉子節(jié)點，而且推薦的在線實驗有上千個模塊，每一個模塊只能給十毫秒以內或者最多幾十毫秒的超時時間，因此要保證所有存儲節(jié)點都是低延遲、高吞吐并且高可用的。推薦實驗和推薦服務base之間有一個互相切換的過程。一般并行的實驗數(shù)量非常多，實驗完成之后會去切換成一個在線的base，這樣它承擔的流量就會非常大。比如在訓練服務base里會有召回的base、粗排的base和精排的base，各個base都需要去承擔千萬級的QPS，而且要提供超高的可靠性。所以在線存儲部分，大量選用的是全內存架構。免費下載資料掃碼關注公眾號免費下載資料頁碼：36/137其次，快手有超大存儲的需求。前文中提到，快手大模型有1.9萬億的參數(shù)量，如果換成普通八維的float，需要的存儲也要有64T，而且還有一個全用戶的行為序列，有180T左右的狀態(tài)信息。如果要采用全內存的存儲，將會需要2000多臺機器。而且所有的狀態(tài)需要在30分鐘內恢復，因為推薦系統(tǒng)如果超過30分鐘不恢復，會對線上產(chǎn)生非常大的影響，用戶體驗會很差。針對上述需求，我們的方案主要有以下幾個：（1）特征score的準入：特征score可以理解為特征重要性，即將一些重要性比較低，對預估效果影響也微乎其微的特征不放在在線存儲上；（2）LRU和LFU的淘汰：因為是在線的模型，需要保證可靠性，即內存需要維持在一個穩(wěn)定范圍內，不能一直增長。因此我們將最遠更新的優(yōu)先淘汰，最先訪問的優(yōu)先保留；（3）NVM新硬件技術：全內存架構的資源消耗也是一個非常大的問題。我們引入了NVM硬件技術。NVM是一個持久化存儲，是Intel新發(fā)布的一個硬件，它會在DR和SSD之間，有接近于內存的速度，同時有接近于SSD的存免費下載資料掃碼關注公眾號免費下載資料頁碼：37/137儲空間，既能兼顧存儲也能兼顧性能。2.存儲方案-NVMTable存儲方案是NVMTable，分成異構存儲的三層：物理層提供底層存儲的API，包括NVM存儲和memory存儲；中間memorypool封裝統(tǒng)一的管理功能，把NVM和memory的模塊都管理起來；上層業(yè)務通過memorypool的一個API去調用下層的NVM和memory，提供統(tǒng)一的查詢邏輯。在數(shù)據(jù)結構布局方面，memorypool采用的是block接口抽象。將NVM和memory分成若干不同的、可通過全局統(tǒng)一地址來訪問的block，這樣就可以實現(xiàn)zerocopy的訪問自由化。對于一些頻繁訪問的key，會放到mem-key上。不常訪問的key會放在到NVM上。一些索引的key會頻繁訪問，但查找到key之后，其value在最后要返回給上游的時候才會用到，并且量級較大，所以將value放到持久化的存儲。Key查詢比較多，同時也比較小，所以放在內存，這樣就實現(xiàn)了內存和NVM的零拷貝技術。這里的哈希表采用了業(yè)界領先的無鎖技術，以減少臨界區(qū)的競爭，完成高效存儲。免費下載資料掃碼關注公眾號免費下載資料頁碼：38/137從NVMTable的一個場景測試數(shù)據(jù)可以看出，其網(wǎng)絡的極限吞吐與JIRA是相當?shù)摹？缇W(wǎng)絡訪問一般是網(wǎng)絡達到極限，所以NVM帶寬可以完全覆蓋網(wǎng)絡帶寬，瓶頸主要在網(wǎng)絡上，這樣就能保證NVM既有成本上的收益，也有大存儲和高吞吐的收益。另一方面，恢復時間也下降了120倍。最開始恢復T的數(shù)據(jù)需要兩個小時，采用NVM之后只需要2分鐘。3.存儲方案-強一致性存儲方面，還有強一致性的需求，主要是因為在推薦場景里也有一些廣告和電商免費下載資料掃碼關注公眾號免費下載資料頁碼：39/137的推薦，需要存儲的副本特別多。因為當一些新的短視頻或者新物料進來時，下游所有模塊會有一個并發(fā)分發(fā)，需要保證這些視頻在10秒內到達所有的推薦服務，且所有推薦服務里的狀態(tài)需要保證一致。否則對于模型的效果影響很大。我們采用了Raft協(xié)議加BT的模式。Raft協(xié)議主要負責選組和同步數(shù)據(jù)，BT的模式主要是改造BT同步的模式，比如在幾千上萬臺機器規(guī)模下的同步，如果同時用主從同步的話，主節(jié)點的出口帶寬可能會是從節(jié)點的千倍以上，帶寬就會成為瓶頸，下發(fā)的狀態(tài)就會非常少，高吞吐和數(shù)據(jù)同步會受到影響。我們的方案是分布式的平衡樹分發(fā)，構造一個平衡二叉樹，把所有主從節(jié)點進行組織，每個節(jié)點只管有限個從節(jié)點，從而保證從主節(jié)點同步到葉子節(jié)點所需要的帶寬不變，但是單節(jié)點的帶寬限制為小于等于2，這樣在全局下既能做到一次性，也能做到高效地同步，10秒內即可將所有視頻狀態(tài)分發(fā)到每個節(jié)點。展望免費下載資料掃碼關注公眾號免費下載資料頁碼：40/137推薦模型的發(fā)展跟語言模型是相關的，從DNN模型到Wide&Transformer，再到SIM長序列及生成式模型，模型增長了很多倍。除了模型的增長，算力增長也會隨視頻的增長和用戶的增長，呈現(xiàn)出指數(shù)級的上升。從統(tǒng)計數(shù)據(jù)來看，最近兩年推薦模型的算力增長接近10倍，我們的方案主要是優(yōu)化工程架構和新的硬件技術。生成式模型會帶來計算量的爆炸，因為它是一個token-based的推薦，每次推薦需要之前所有的token作為context，在這種情況下生成的效果才會最好。如果沒有token-based，那么與算力不會呈指數(shù)級增長。因此，推薦的壓力，將主要來自狀態(tài)存儲的大規(guī)模提升，因為目前的推薦模型主要是pointwise的推薦，對于長序列推薦模型算力也是有限的。如果全部采用深層次模型推薦，其狀態(tài)存儲還將再增長10倍，挑戰(zhàn)會非常大。因此我們需要通過一些新硬件，比如CXL、NVM以及新推出的Grace架構，再加上工程上的優(yōu)化，比如狀態(tài)做差分、傳輸計算等等，來應對未來的挑戰(zhàn)。頁碼：41/137掃碼關注公眾號免費下載資料嗶哩嗶哩基于Iceberg的智能數(shù)據(jù)組織優(yōu)化實踐導讀：隨著數(shù)據(jù)存儲規(guī)模的增長和查詢環(huán)境的復雜化，數(shù)倉面臨著查詢性能與穩(wěn)定性的挑戰(zhàn)。為了實現(xiàn)查詢加速，嗶哩嗶哩在Iceberg基礎上進行了功能拓展，包括多維排序、多種索引和預計算等。然而，現(xiàn)有優(yōu)化手段對用戶的技術門檻較高，需要手動配置或組織培訓提供指導，限制了優(yōu)化技術的推廣使用。因此，采用了智能優(yōu)化技術，通過自動分析用戶歷史查詢數(shù)據(jù)，為數(shù)據(jù)存儲和查詢配置合理的優(yōu)化手段，提升了數(shù)倉的整體查詢效率。今天的分享將主要包括三個主要內容。首先，我們將介紹智能優(yōu)化項目的背景，然后我們會詳細介紹智能優(yōu)化的整體實踐方案。最后，我們將展示目前智能優(yōu)化所取得的成果，以及未來的規(guī)劃。本次分享主要內容包括：1.智能優(yōu)化背景2.智能優(yōu)化實踐方案3.智能優(yōu)化成果及規(guī)劃分享嘉賓｜楊金德嗶哩嗶哩高級開發(fā)工程師編輯整理｜張陽內容校對｜李瑤出品社區(qū)｜DataFun頁碼：42/137掃碼關注公眾號免費下載資料智能優(yōu)化背景首先來介紹一下智能優(yōu)化的背景。1.湖倉一體架構與現(xiàn)狀我們的湖倉一體平臺使用Iceberg作為數(shù)據(jù)的存儲格式，數(shù)據(jù)存儲于HDFS，入湖主要有3條鏈路：離線場景使用Spark寫入數(shù)據(jù)，實時場景則使用Flink或我們提供的JavaSDK進行寫入。交互式分析采用Trino查詢引擎，并利用Alluxio對數(shù)據(jù)進行緩存加速。此外，平臺也有一獨立的服務Magnus負責Iceberg表的數(shù)據(jù)優(yōu)化，將在本次介紹中重點提及。對于寫入Iceberg的數(shù)據(jù)，一部分會繼續(xù)寫入下游的Iceberg表，而在某些對查詢性能和穩(wěn)定性要求較高的場景，需要毫秒級響應時間，這時數(shù)據(jù)會被導出到ClickHouse或ES。目前，平臺包含大約2000張Iceberg表，總數(shù)據(jù)量達到40PB，100TB。Trino的日查詢量超過400萬次，P99的響應時間大約為3秒。2.OLAP場景查詢加速免費下載資料掃碼關注公眾號免費下載資料頁碼：43/137目前的業(yè)務場景主要包括BI報表、指標服務、A/BTest人群篩選以及日志處理。針對這些場景，我們在Iceberg基礎上進行了功能拓展，以滿足用戶對查詢加速的需求。除了Iceberg原有的數(shù)據(jù)組織分布能力外，還增加了支持多維排序的功能，比如Z-order和HilbertCurve，并且提供了多種索引類型，包括通用的BloomFilter、Bitmap以及針對日志場景的特殊索引。此外，我們還開發(fā)了預計算功能，主要用于加速聚合計算的查詢。3.用戶使用門檻高免費下載資料掃碼關注公眾號免費下載資料頁碼：44/137我們支持的這些查詢加速手段能夠為查詢帶來數(shù)倍到數(shù)十倍的性能提升。然而，實際落地時會遇到一個問題，即這些優(yōu)化手段對用戶的使用門檻較高，要求用戶對業(yè)務的查詢模式有清晰的認知，并了解相關的基礎知識才能進行合理配置。因此，通常需要我們手動為用戶配置，或者通過組織培訓提供指導。這限制了查詢優(yōu)化技術的推廣使用。我們希望通過自動化、智能化的方式解決用戶使用門檻的問題。這也是智能優(yōu)化的目標，我們希望它能夠自動分析用戶的歷史查詢，為Iceberg表配置合理的優(yōu)化手段，從而實現(xiàn)后續(xù)用戶查詢的加速。智能優(yōu)化實踐方案接下來將介紹智能優(yōu)化的整體實踐方案。1.整體方案設計整個智能優(yōu)化流程涉及兩個計算引擎，一個是交互式分析的Trino引擎，另一頁碼：45/137個是執(zhí)行數(shù)據(jù)優(yōu)化的Spark引擎。還包括兩個服務，一個是查詢采集服務，另一個是負責分析推薦和數(shù)據(jù)優(yōu)化調度的Magnus服務。用戶提交查詢后，查詢Iceberg表。Magnus的分析推薦模塊定期從查詢明細表獲取查詢信息，分析查詢模式，生成推薦的數(shù)據(jù)組織配置，然后應用到Iceberg表中。這時推薦的配置并未實際生效，需要數(shù)據(jù)優(yōu)化模塊在Iceberg表數(shù)據(jù)寫入后異步提交優(yōu)化任務，由Spark完成數(shù)據(jù)優(yōu)化。接下來會詳細介紹查詢采集、分析推薦以及數(shù)據(jù)優(yōu)化三個模塊的一些細節(jié)。2.查詢信息采集查詢采集模塊需要采集四類查詢信息。首先是基本信息，包括時間、狀態(tài)、查詢SQL、以及用戶身份等。接著是反映查詢性能的關鍵指標，如查詢耗時和掃描數(shù)據(jù)量，這些指標直接影響交互式分析的用戶體驗和查詢優(yōu)化效果。第三個部分是查詢模式，包括查詢的過濾條件、Orderby條件以及聚合模型。這些信息理論上可以通過直接分析查詢SQL得到，但我們選擇將提取查詢模式的工作放到免費下載資料掃碼關注公眾號免費下載資料頁碼：46/137Trino中實現(xiàn)，通過查詢信息方式暴露出來，從而降低開發(fā)成本。最后是數(shù)據(jù)過濾的指標，我們在Trino統(tǒng)計了排序等優(yōu)化手段在查詢中的過濾效果，這些指標可以幫助我們跟蹤和分析Iceberg表的優(yōu)化效果，對推薦策略進行調整。3.分析推薦分析推薦模塊是根據(jù)查詢以及Iceberg表的統(tǒng)計信息進行推薦的。我們的推薦策略是由一系列基于優(yōu)化原理和實踐經(jīng)驗的規(guī)則構成的。因此，在實現(xiàn)上相對比較簡單，并且對于不是特別復雜的查詢模式，也會有較好的推薦效果。分析推薦任務是定期執(zhí)行的，比如每周執(zhí)行一次針對每張Iceberg表的分析推薦任務。當用戶的查詢場景發(fā)生變化時，推薦配置也可以相應調整，以達到最佳優(yōu)化效果。不同優(yōu)化手段的分析對象和推薦依據(jù)是有區(qū)別的，下面將簡要介紹各個優(yōu)化手段的分析和推薦邏輯。免費下載資料掃碼關注公眾號免費下載資料頁碼：47/137進行數(shù)據(jù)分析時，一個重要的優(yōu)化策略是通過調整Iceberg表的分布來提高數(shù)據(jù)在特定字段上的聚集性。在查詢過程中，引擎可以利用Iceberg表文件級別的最大值和最小值統(tǒng)計信息來過濾文件，實現(xiàn)查詢加速。舉個例子，假設一張表有四個文件，第一個文件在字段a上的最小值是0，最大值是10。如果查詢條件是a等于11，由于11不在0到10的范圍內，該文件就無需被讀取。相反，如果查詢條件是a等于2，而沒有進行數(shù)據(jù)分布優(yōu)化，就需要讀取所有文件，因為每個文件在字段a上的最小值和最大值范圍都包括2。對表按照字段a進行線性分布優(yōu)化后，可以看到整個表在字段a上的聚集性得到改善。這樣一來，只需讀取第二個文件即可完成查詢，其他文件則被直接過濾掉。在進行數(shù)據(jù)分布優(yōu)化時，主要考慮常用的過濾字段，根據(jù)查詢條件統(tǒng)計出每個字段出現(xiàn)在過濾條件中的查詢占比，推薦優(yōu)化策略更傾向于選擇占比較高的字段。同時，也會考慮字段基數(shù)和分區(qū)文件數(shù)等因素。字段基數(shù)越高，分布效果就會更好。舉個例子，如果將字段a的基數(shù)改為2，即只有0和2兩個取值各占一半，即使按照字段a進行分布優(yōu)化，也至少需要讀取兩個文件。同理，如免費下載資料掃碼關注公眾號免費下載資料頁碼：48/137果分區(qū)文件數(shù)過少，分布優(yōu)化效果也會變差。在分布優(yōu)化推薦中，有幾種常見情況可以作為例子。首先，如果有90%的查詢是針對a字段進行過濾，而只有10%的查詢是針對b字段進行過濾，這種情況下推薦按照a字段進行線性分布。其次，如果有50%的查詢是針對a字段進行過濾，而另外50%的查詢同時針對a和b字段進行過濾，那么建議按照a和b字段的順序進行線性分布，可以較好地過濾兩類查詢。第三種情況是50%的查詢對a字段過濾，另外50%的查詢對b字段過濾。在這種情況下，如果按照a或b字段線性分布，則對另一類查詢都不會有很好的過濾效果。這時候可以考慮采用HilbertCurve這種多維分布方式，它能夠在多個字段上實現(xiàn)較好的聚集效果，提升不同字段過濾查詢的性能表現(xiàn)。免費下載資料掃碼關注公眾號免費下載資料頁碼：49/137索引是用于實現(xiàn)查詢加速的一種重要技術，它和分布優(yōu)化一樣通過文件級別的數(shù)據(jù)過濾加速查詢。索引提供了更為詳盡的記錄，因此其過濾性能更佳，能夠處理一些分布優(yōu)化效果不好的場景。例如當查詢條件改為“ain(3,6,9)”時，盡管做了分布優(yōu)化，仍需讀取三個文件，實際上只需讀取其中一個文件，這時就需使用索引來實現(xiàn)優(yōu)化。此外，當參與分布的字段過多時，分布的效果可能較差，因此選擇少量字段用于分布，而對其他字段進行索引構建，也是常見的優(yōu)化策略。不同類型的索引適用于不同的場景，需要綜合考慮字段的過濾查詢占比和不同類型的過濾條件，如等值過濾和范圍過濾。BloomFilter適用于等值過濾，而針對范圍過濾的查詢，需使用bitmap索引。此外，字段基數(shù)也是重要的推薦依據(jù)，對于基數(shù)較高的字段，使用BloomFilter索引效果較好，而構建bitmap索引可能會因為索引過大，導致性能回退。免費下載資料掃碼關注公眾號免費下載資料頁碼：50/137文件內排序也是查詢優(yōu)化的常見手段，可以加速TopN查詢。TopN查詢在計算引擎中執(zhí)行時一般會分為局部排序和全局排序兩個階段。通過事先對Iceberg表文件內部進行排序，就可以節(jié)省局部排序的計算成本，同時減少掃描的數(shù)據(jù)量。Orderby條件在查詢中的占比來生成推薦。此外，需要注意同一種排序定義是可以響應多種Orderby條件的查詢的。舉個例子，如果按照字段a、b進行排序，既可以響應按a、b排序的查詢，也可以響應按照a排序的查詢。這個因素在推薦的時候也是需要考慮的。免費下載資料掃碼關注公眾號免費下載資料頁碼：51/137我們實現(xiàn)的預計算是一種針對聚合計算的優(yōu)化手段。該手段通過提前按照指定的聚合模型對每個數(shù)據(jù)文件生成預聚合文件，在查詢時直接讀取這些預聚合文件，從而減少需要讀取的數(shù)據(jù)量。預計算的分析過程相對復雜，首先需要定義聚合模型，然后計算每個模型在查詢中的占比。聚合模型包括維度字段和聚合函數(shù)，對于涉及多表關聯(lián)的場景，還需要考慮關聯(lián)信息。另外，預計算的聚合效果也是重要的考量因素。如果一個文件經(jīng)過聚合后仍然保留了大部分數(shù)據(jù)，那么預計算的意義就不大，同時還會浪費存儲空間。這個指標通常無法從表的統(tǒng)計信息中獲得，而需要通過額外的計算方法，比如通過Trino的查詢來獲取聚合效果。免費下載資料掃碼關注公眾號免費下載資料頁碼：52/137推薦完成后，服務會將推薦結果配置到Iceberg表中。我們還做了推薦結果的持久化和前端展示，這樣方便我們和用戶查看。在生成的生產(chǎn)表的推薦記錄中，展示了推薦的排序和分布信息。這個展示內容還包括推薦結果和當前配置的對比。例如，在Distribution這個部分，黑色字段表示保持不變，綠色字段表示新增，紅色字段表示移除。通過這樣的展示和對比，用戶可以清晰地了解推薦結果和當前配置的變化。4.數(shù)據(jù)優(yōu)化免費下載資料掃碼關注公眾號免費下載資料頁碼：53/137推薦結果配置到Iceberg表之后，并不會立即生效，需要通過數(shù)據(jù)優(yōu)化模塊，異步提交Spark任務完成數(shù)據(jù)優(yōu)化。數(shù)據(jù)優(yōu)化的流程如上圖，當任務向Iceberg表寫入數(shù)據(jù)時，會發(fā)送一個CommitEvent。通過CommitEvent，調度器可以獲取這次寫入操作修改了哪些分區(qū)，寫入了多少文件以及每個文件的數(shù)據(jù)量等信息?；谶@些信息，以及Iceberg表的元數(shù)據(jù)信息，調度器會調度優(yōu)化任務到Spark完成優(yōu)化。對于異步的數(shù)據(jù)優(yōu)化，延遲是重要的考量指標。以小時分區(qū)的實時表為例，如果在分區(qū)所有數(shù)據(jù)寫入完成再進行優(yōu)化，可能導致超過一小時的延遲。用戶查詢過去15分鐘至半小時內的數(shù)據(jù)時，性能就會比較差。為降低實時優(yōu)化延遲，我們采用了基于快照的分級優(yōu)化調度策略。Iceberg表的快照是表在某個時間點的副本，每次提交時會生成一個快照，其中包含已存在的數(shù)據(jù)文件、本次提交的增量數(shù)據(jù)文件以及刪除的數(shù)據(jù)文件。我們的策略是只優(yōu)化指定快照中新增的數(shù)據(jù)，當某分區(qū)的小文件數(shù)量累積較多時，將觸發(fā)minor優(yōu)化以合并小文件。當累積未優(yōu)化文件數(shù)據(jù)量達到閾值（如2GB），將觸發(fā)major優(yōu)化，包括排序、分布以頁碼：54/137及索引創(chuàng)建等操作。這種策略將整個分區(qū)的優(yōu)化拆分成多階段優(yōu)化，用戶在查詢時能享受到階段性優(yōu)化帶來的加速效果。為了降低優(yōu)化延遲，我們還做了其他優(yōu)化。一是任務合并，將同一張表的多個優(yōu)化任務打包提交，減少Spark任務調度開銷；二是通過優(yōu)先級調度防止歷史數(shù)據(jù)回刷對實時數(shù)據(jù)優(yōu)化造成影響。此外，我們還針對優(yōu)化任務進行了一些資源管理控制，如限制總體計算資源和單表的并發(fā)控制等。目前在高并發(fā)提交場景下，Iceberg表存在性能問題，因此需要對每個表同時運行的任務數(shù)量進行限制。頁碼：55/137我們還有一個前端頁面，用來展示Iceberg表的分區(qū)級別的統(tǒng)計信息。除了數(shù)據(jù)量、文件數(shù)等基本信息，頁面還展示最后寫入時間以及各種優(yōu)化手段的實際優(yōu)化比例，比如排序和分布等，以便進行問題排查。智能優(yōu)化成果及規(guī)劃最后介紹一下智能優(yōu)化現(xiàn)階段的成果以及未來的規(guī)劃。1.成果免費下載資料掃碼關注公眾號免費下載資料頁碼：56/137我們目前針對一些沒有進行任何優(yōu)化配置的Iceberg表，開放了智能優(yōu)化功能。截至目前為止，已經(jīng)對30多張表進行了優(yōu)化。在這30多張表經(jīng)過優(yōu)化后的30天總體掃描數(shù)據(jù)量減少了28%。其中有超過60%的表掃描量減少了30%以上。目前項目的推薦策略還相對比較保守。在實際的生產(chǎn)環(huán)境中，有許多表已經(jīng)由用戶配置了一些優(yōu)化手段，但由于配置不夠合理，所以無法達到良好的加速效果。對這部分表開啟智能優(yōu)化功能，查詢加速的收益會更高。2.未來規(guī)劃免費下載資料掃碼關注公眾號免費下載資料頁碼：57/137在接下來的工作中，我們將持續(xù)改進并推廣智能優(yōu)化功能。其中一項改進是增加推薦準確性。比如分布和索引的推薦，影響推薦準確率的關鍵因素之一是過濾效果的判斷，因此我們會考慮使用更詳細的統(tǒng)計信息，如實際數(shù)據(jù)分布，來輔助推薦決策。隨著參考統(tǒng)計信息的增加，決策模型的參數(shù)將變得更加復雜，我們也將考慮利用機器學習或人工智能算法來進一步提高推薦準確性。另一個改進方向是支持更多的查詢場景。目前索引和預計算推薦在日志場景和多表關聯(lián)預計算推薦方面仍有不足，我們將逐步完善這些場景。最終，我們還將把智能優(yōu)化推廣應用到更多的生產(chǎn)表中，以優(yōu)化用戶配置并提供更好的查詢體驗。頁碼：58/137掃碼關注公眾號免費下載資料京東零售數(shù)據(jù)可視化平臺產(chǎn)品實踐與思考導讀：本次分享題目為京東零售數(shù)據(jù)可視化平臺產(chǎn)品實踐與思考。主要包括以下四個部分：1.平臺產(chǎn)品能力介紹2.業(yè)務賦能案例分享3.平臺建設挑戰(zhàn)與展望4.Q&A分享嘉賓｜梁臣京東數(shù)據(jù)產(chǎn)品架構師編輯整理｜梁英琪內容校對｜李瑤出品社區(qū)｜DataFun平臺產(chǎn)品能力介紹1.產(chǎn)品矩陣免費下載資料掃碼關注公眾號免費下載資料頁碼：59/137數(shù)據(jù)可視化產(chǎn)品是一種利用數(shù)據(jù)分析和可視化技術，幫助企業(yè)從大量數(shù)據(jù)中提取具有價值的信息和洞察的工具，主要作用有以下幾點：n可視化呈現(xiàn)與報告。將數(shù)據(jù)以圖表、儀表盤、報告等形式進行可視化呈現(xiàn)，讓用戶更加直觀地理解數(shù)據(jù)，快速識別關鍵指標。n數(shù)據(jù)分析與探索。通過對數(shù)據(jù)進行多維度切片和鉆取來進行分析。用戶也可以通過交互式界面對數(shù)據(jù)進行探索，發(fā)現(xiàn)數(shù)據(jù)中的模式、趨勢和關聯(lián)性。n實時監(jiān)控和預警。通過實時監(jiān)控及時洞悉關鍵業(yè)務指標和數(shù)據(jù)變化，通過報警和通知來提醒用戶異常情況的發(fā)生。n業(yè)務的監(jiān)測和評估。通過該產(chǎn)品可以監(jiān)測評估業(yè)績，并跟蹤關鍵業(yè)務指標的變化趨勢。n數(shù)據(jù)驅動決策。幫助決策層、管理層做出更明智的決策，降低決策風險，優(yōu)化業(yè)務的運營。數(shù)據(jù)可視化產(chǎn)品可以幫助企業(yè)更好地利用數(shù)據(jù)進行決策和業(yè)務洞察，加強數(shù)據(jù)驅動的決策文化，促進業(yè)務的增長和創(chuàng)新。免費下載資料掃碼關注公眾號免費下載資料頁碼：60/137京東數(shù)據(jù)可視化的產(chǎn)品矩陣主要有：智能BI平臺，數(shù)據(jù)大屏平臺，低代碼平臺和交互分析平臺。數(shù)據(jù)可視化平臺的產(chǎn)品有多種典型應用場景。比如將來自企業(yè)內部的業(yè)務數(shù)據(jù)通過數(shù)據(jù)抽取、清理加工，進行數(shù)倉的分層存儲，通過數(shù)據(jù)集市提供給用戶進行分析處理?；蛲ㄟ^消息管道的方式，利用Flink等引擎進行實時的數(shù)據(jù)計算，再通過OLAP數(shù)據(jù)庫進行數(shù)據(jù)查詢和使用，等等。根據(jù)不同的業(yè)務場景，有不同的產(chǎn)品使用鏈路。下面主要介紹如下三個京東內部的可視化產(chǎn)品平臺：nEasyBI定位于拖拽式的可視化報表搭建平臺，面向京東域內提供報表搭建能n低代碼平臺定位于低代碼的可視化編排系統(tǒng)，提供多種場景化的數(shù)據(jù)組件，進行代碼配置。nJDV大屏定位于自助式的可視化大屏搭建工具，比如618、雙11的可視化大屏都是通過JDV大屏來搭建和呈現(xiàn)的。頁碼：61/137接下來將詳細介紹這幾款產(chǎn)品的功能。2.EasyBIEasyBI是京東推出的一款自助式數(shù)據(jù)報表與可視化分析工具，面對不同的業(yè)務場景，以數(shù)據(jù)驅動價值，幫助用戶快速地分析和洞察數(shù)據(jù)。整體架構分為四層：數(shù)據(jù)連接層，支持MySQL、Presto、ClickHouse、ElasticSearch、API等數(shù)據(jù)的接入，還支持本地上傳以及數(shù)據(jù)填報等，滿足不同場景的數(shù)據(jù)接入與集成。第二層為數(shù)據(jù)建模，可進行輕量級數(shù)據(jù)建模，包括表與表之間的關聯(lián)，表條件的過濾，表權限的配置和設置，實現(xiàn)了類似數(shù)據(jù)視圖的功能。第三層是可視化配置，包括大量自研的可視化組件和配置能力，目前支持insight等不同畫布模式，通過不同的圖層設計、可視化組件編排，以及相應的篩選器、組件參數(shù)配置等形成整體的可視化看板。最上面是數(shù)據(jù)看板應用的發(fā)布與管理，支持郵件訂閱、看板智能預警，支持配置不同主題，加入第三方組件，也可以無縫嵌入其它業(yè)務平臺，支持報表、門戶等免費下載資料掃碼關注公眾號免費下載資料頁碼：62/137不同功能。這款產(chǎn)品目前賦能于京東各個集團及海內外業(yè)務，在報表開發(fā)者數(shù)量、日常使用者數(shù)量、嵌入式支持系統(tǒng)的數(shù)量、已開發(fā)報表數(shù)量和外嵌報表數(shù)量等方面均取得了較為領先的數(shù)據(jù)規(guī)模。EasyBI的核心功能包括，支持多源數(shù)據(jù)的接入，可以用于搭建企業(yè)級數(shù)據(jù)門戶，支持智能分析，允許用戶深度追蹤和挖掘數(shù)據(jù)，包含內置算法，可提供數(shù)據(jù)診斷分析、時間序列分析等等，幫助用戶做智能數(shù)據(jù)分析和決策。場景模板功能，是基于京東零售在數(shù)據(jù)分析領域內多年的積累和沉淀，將方法論模板化，形成開箱即用的場景化模板。此外還有豐富的數(shù)據(jù)可視化組件，交互分析能力，權限管控能力和數(shù)據(jù)抽取能力等核心功能。在數(shù)據(jù)看板消費者端，我們做了很多工作，比如性能查詢的提升，通過數(shù)據(jù)查詢全鏈路的監(jiān)控分析、緩存性能的優(yōu)化提升、SQL語法的識別分析、SQL全表掃描的查詢優(yōu)化、性能診斷工具等能力，為用戶查詢體驗保駕護航。免費下載資料掃碼關注公眾號免費下載資料頁碼：63/137EasyBI產(chǎn)品的核心優(yōu)勢包括：支持零代碼拖拽，可以靈活嵌入到各種不同的業(yè)務系統(tǒng)中，做到無縫嵌入，還有數(shù)據(jù)找人的智能預警功能、引擎?zhèn)鹊膬?yōu)化，以及安全管控體系的優(yōu)化等等。3.低代碼平臺低代碼平臺的產(chǎn)生背景有三個方面，首先在業(yè)務上，京東有一套成熟的數(shù)據(jù)BP陪跑模式，會深入到業(yè)務一線戰(zhàn)場做業(yè)務的數(shù)據(jù)分析，從而對場景化分析提出了較高要求；第二是在研發(fā)資源上，希望在有限的人力下，通過技術能力提升，改免費下載資料掃碼關注公眾號免費下載