京東實時資料產品應用實踐

分享嘉賓｜王威 京東 資料計算平臺部產品規劃負責人

編輯整理｜楊康 南京大學

出品社群｜DataFun

京東實時產品的應用涵蓋集團範圍內的各個體系，包括零售、物流、健康等都有實時資料的應用場景，例如實時數倉、實時資料大屏、實時推薦、報表、風控、監控等等。

實時數倉主要是為了滿足業務部門的資料分析師、BI 工程師等的實時資料分析需求，基於實時資料去解決一些業務當中需要快速決策或者是需要快速去看到一些效果的資料應用場景。

實時大屏之前主要應用在大促場景當中，而後在一些日常運營中，也應用得越來越廣泛，包括面向一些第三方賣家，為他們提供日常操盤運營的支援。

另外還有透過配置化工具來實現的實時報表，因為實時大屏主要是來做監控的，以靜態展示為主，如果想基於實時資料做互動分析，實時地去看不同類目、不同品類或者是不同場景的一些資料，下載最新的資料等，就需要實時報表。

實時推薦比較好理解，開啟京東 App，首頁裡面很多頻道都是基於實時推薦，包括秒殺、發現好貨或者是猜你喜歡等等，這些產品的呈現都是需要基於我們實時資料計算，以及關聯到一些推薦的策略。

實時風控這一塊可能相對比較神秘一些，比如在京東上搶茅臺的時候，其實在內部需要做一些風控策略去防止黃牛或其它一些風控場景。

還有實時監控，比如實時地去監控營銷、廣告效果以及 ROI 的情況，透過實時監控一些指標去決策投放效果是否可行，或者轉化效果怎麼樣，以便隨時地去做運營策略調整。這些都是實時應用的一些場景。

2. 發展歷程

簡單回顧京東做實時資料產品的歷程，我們是在 2014 年才開始建設第一代實時資料產品。當時是基於 storm 做實時計算，主要是針對 618、雙 11 這樣的大促場景。產品化方面，當時只是提供了簡單的實時開發的工具，而且主要是用 Java 語言來開發，門檻相對比較高，應用場景也比較有限。2017 年的時候，開始基於 Kafka 自建了一些實時的訊息平臺，這個時候才開始把實時訊息平臺做了一個初步的產品化。

到了 2019 年的時候，我們開始支援 SQL 化的實時資料開發，這些演進跟技術的變化也是分不開的。2021 年我們主要在做一些低程式碼資料平臺的工作，儘管實時資料開發門檻還是非常高，但是透過梳理應用場景，再把場景標準化、模組化的梳理，然後在產品層面做配置化來實現低程式碼的實時資料開發。到了今年，考慮到降低成本、增加人效，我們主要把精力聚焦在流批一體化產品建設中。

3. 使用者分佈

目前實時產品主要使用者中，軟體開發工程師、演算法工程師加起來超過 50%，其次是產品經理、資料分析師，還有一些資料探勘工程師等等。但是對於這些實時資料產品的應用需求往往來自於業務部門的資料分析師、產品經理，比如要快速地獲取到今天的大促效果資料，但由於這塊門檻比較高，所以他們需要找到演算法工程師或者是軟體開發工程師去解決他們的問題，因此導致現在這樣一個使用者構成。其實這也說明了做一個低門檻的開發平臺的重要性，就像很多離線資料開發工具一樣，讓很多產品經理或者分析師透過配置的方式不用寫程式碼就能獲取到他們想要的實時資料，這是我們要繼續努力的一個方向。

4. 當前問題

在做實時資料產品的過程當中，也面臨一些問題，除了上面提到的門檻比較高之外，還有就是離線跟實時資料的割裂，無論是儲存方面還是程式碼層面，導致在一些涉及到實時和離線資料融合的場景時，使用還比較困難。第三個方面，實時資料產品的高門檻，就導致人力資源、IT 資源的成本相對來講也是比較高的。鑑於在做實時資料產品過程中遇到的問題，低程式碼方向的實施建設迫在眉睫。

1. 挑戰

然而在做低程式碼產品過程中面臨的一個挑戰是，業務場景是非常複雜的，技術功能也是非常複雜的，但我們希望產品模式儘可能簡單，儘量把一些技術點給遮蔽掉，這就需要去做平衡。

要解決這個問題，我們對資料使用場景進行了系統梳理，再對這些場景所涉及到的一些問題以及解決方案進行標準化。標準化之後再進行模組化，只有透過模組化才能在產品介面上實現低程式碼。

2. 業務場景拆分

具體來講，我們劃分了三個主要應用場景：

一個是統計型的實時資料應用。這一塊主要是把實時的資料效果應用在我們的實時資料運營當中，包括一些視覺化的看板或者是實時的一些分析報表等。

第二類是明細型資料業務，就是要把實時資料計算的結果，作為明細儲存在資料倉儲裡，以及結合離線資料進行關聯分析計算，這塊主要是應用在實時和離線的數倉構建場景當中。

第三個場景是一些複雜事件處理業務場景，這種場景對我們來講也是挑戰最大的，包括複雜的實時演算法場景應用、標籤還有一些複雜的實時風控策略、監控告警等等，這些場景往往需要多個實時資料的處理規則去綜合地應用。

劃分完場景後會進行標準化拆分：

• 資料來源頭的標準化，就是我們輸入的資料來源都有哪些；

• 模型加工的標準化，是對於一些資料處理的邏輯進行標準化的分類；

• 實時計算結果輸出模式的標準化。在標準化完成之後，就需要形成一個固定的模組化的產品功能，這就是我們構建低程式碼實時資料產品的過程，或者說是方法論。

3. 資料處理模型

我們的產品邏輯就是把技術架構或者說資料處理邏輯給封裝起來。實時開發平臺的上游就是我們的資料輸入源，這一塊包括一些業務系統實時產生的資料、訊息佇列，或者是實時資料要結合的一些數倉裡面的離線資料，比如實時資料計算需要結合離線的一些維表做一些關聯。

源頭訊息接入之後，就是場景化規則拆分。對於這些實時的訊息，我們要根據不同的應用場景去做規則分類，形成一個實時資料計算規則引擎，例如對於統計型的常見的一些函式要封裝進去。

不同場景的計算結果會根據下游業務場景應用，把資料按照這種分鐘級、小時級、天級將計算結果儲存下來，一些明細資料會存到實時數倉裡面去，這些資料繫結下來之後，根據下游的業務場景去做應用。

4. 產品特點

總結起來低程式碼產品特點有三個，第一個比較好理解，就是以低程式碼這種方式，透過簡單配置開發來實現實時的資料開發；第二個特點是這種一體化的生態，主要指的是透過實時資料產品和下游報表開發平臺、指標應用平臺、演算法平臺的打通去面向下游做實時資料的輸出；最後就是技術化賦能，主要指實時資料產品配置化的能力，可以以 API  的方式開放給其他系統，其他系統包括一些風控或是搜尋推薦在做實時資料計算的時候，也可以以低程式碼的方式在其產品介面裡面配置。

以實時大屏為例，之前可能開發一個實時大屏，尤其是在資料準備這個階段，可能要花上幾周甚至超過一個月的這種時間，主要複雜在實時資料的開發以及後面的一個測試聯調中。現在這種低程式碼的方式來去實現實時資料開發之後效率提升還是非常明顯的，像我們現在幾個小時就可以完成一個這種實時資料大屏的開發。

03

流批一體化產品體系

1. 什麼是流批一體

在技術層流批一體很早就實現了，也就是 lambda 架構。那麼基於統一的 Flink 把實時資料處理和離線資料處理基於同一套引擎去完成。當需要流式實時結果的時候跑流式計算，把實時計算結果獲取到；當需要跑批的時候，把批處理的任務提起來之後再去跑批。

但是這個過程中存在一個問題，儘管基於同一套引擎，但由於下游儲存的介質是不一樣的，所以需要兩套程式碼去維護流批一體架構，這種情況對運營和維護來講成本都是比較高的。出於降本增效的要求，我們定義了業務層的流批一體，就是統一基於 Flink 去開發一套指令碼去實現流計算這個流的實時計算和跑批計算，然後再把結果統一儲存到湖倉一體這樣的儲存介質當中去。這時從開發角度只需要開發一套指令碼。

流批一體從平臺能力的角度出發，解決當前資料平臺 Lambda 架構下兩套資料鏈路在面臨使用者資料需求時的痛點，包括：叢集維護成本、開發成本、人力成本、一致性問題，統一了不同介質資料的業務模型以及加工計算口徑和邏輯，此外還減少了冗餘資料鏈路，提高了資源利用率。

兩個具體的應用場景，第一個案例就是實時數倉的建設。實時數倉主要是為了去對應離線數倉的通用明細資料層和通用資料彙總層，把這兩層裡面一些相對來講比較核心的資料主題，比如說我們的訂單、流量、使用者等建立一個這種實時的數倉。透過實時通用資料層 RDDM 建設來服務黃金眼/商智、JDV、廣告演算法、搜推演算法等核心業務。

第二個案例是風控輿情場景，它的業務特點是需要端到端地去做實時的輿情判斷。現在透過流批一體的方式，統一用 Flink 引擎做計算，在整個端到端過程的延時可以控制在一分鐘左右，開發跟維護的成本可以降低大概 30% 以上。

產品運營：實時資料鏈路三道防線

1. 聯合建模需求場景

為什麼要講運營呢？因為實時產品的使用，比如在我們的一個大促場景中，它的鏈路非常廣，它的下游應用場景也非常多，包括實時的資料大屏、實時的資料榜單、實時促銷策略資料效果等，所以保障鏈路的穩定性是前提，同時也是很大的一個痛點，每一個環節出問題對我們來講可能都會有影響。

第二個痛點是這樣一個鏈路裡面各個環節有很多的監控報警資訊，但是都又都比較分散，當出了問題之後排查定位和解決難度很大。

第三個方面就是系統穩定執行主要依賴於研發人員各自的經驗。因此，我們需要形成一套系統化的保障，實時產品就需要一套穩定性運營機制。

這種穩定性運營機制可以總結為三道防線。所謂三道防線，就是分別從事前、事中和事後去保障實時資料計算和應用的穩定性。

第一道防線主要在事前去做風險排查和風險治理，主要透過混沌工程、軍演壓測和業務加固。

第二個防線實際上是針對事中的，就是構建一個比較完整的應用健康度檢測機制。包括故障歸因分析、彈性擴容、應急預案等。那麼最後真正出了問題怎麼辦？那就需要有第三道防線去做事後的處理，主要是透過自動恢復機制去完成。

在三道防線上我們設定了三個指標，分別是故障發生率、故障恢復的時間和備戰時長。透過這三個指標去衡量運營效果的好壞。

未來我們對於實時產品的規劃主要包括三個方面：

• 一方面我們要把低程式碼能力覆蓋的應用場景再擴充，去適配一些更復雜事件處理場景。

• 第二個方面會去做實時 ETL 工具建設，在實時資料採集、推送等各個方面去實現實時一體化能力，最終形成流批一體 ETL 產品體系。

• 第三個方面就是完善全鏈路自動診斷調優，提升我們診斷以及運維的能力，持續地去降低實時產品的運營維護成本。