導讀 本文根據京東集團資料計算平台部産品規劃負責人王威講座整理，本次分享題目為《京東實時資料産品應用實踐》。
文章主要從以下四個方面介紹：
1. 京東實時産品概況
2. 低代碼實時平台建設
3. 流批一體化産品體系
4. 産品營運：實時資料鍊路三道防線
分享嘉賓｜王威 京東 資料計算平台部産品規劃負責人
編輯整理｜楊康 南京大學
出品社群｜DataFun
01
京東實時産品概況
1. 實時資料産品支撐業務場景
京東實時産品的應用涵蓋集團範圍内的各個體系，包括零售、物流、健康等都有實時資料的應用場景，例如實時數倉、實時資料大屏、實時推薦、報表、風控、監控等等。
實時數倉主要是為了滿足業務部門的資料分析師、BI 工程師等的實時資料分析需求，基于實時資料去解決一些業務當中需要快速決策或者是需要快速去看到一些效果的資料應用場景。
實時大屏之前主要應用在大促場景當中，而後在一些日常營運中，也應用得越來越廣泛，包括面向一些第三方賣家，為他們提供日常操盤營運的支援。
另外還有通過配置化工具來實作的實時報表，因為實時大屏主要是來做監控的，以靜态展示為主，如果想基于實時資料做互動分析，實時地去看不同類目、不同品類或者是不同場景的一些資料，下載下傳最新的資料等，就需要實時報表。
實時推薦比較好了解，打開京東 App，首頁裡面很多頻道都是基于實時推薦，包括秒殺、發現好貨或者是猜你喜歡等等，這些産品的呈現都是需要基于我們實時資料計算，以及關聯到一些推薦的政策。
實時風控這一塊可能相對比較神秘一些，比如在京東上搶茅台的時候，其實在内部需要做一些風控政策去防止黃牛或其它一些風控場景。
還有實時監控，比如實時地去監控營銷、廣告效果以及 ROI 的情況，通過實時監控一些名額去決策投放效果是否可行，或者轉化效果怎麼樣，以便随時地去做營運政策調整。這些都是實時應用的一些場景。
2. 發展曆程
簡單回顧京東做實時資料産品的曆程，我們是在 2014 年才開始建設第一代實時資料産品。當時是基于 storm 做實時計算，主要是針對 618、雙 11 這樣的大促場景。産品化方面，當時隻是提供了簡單的實時開發的工具，而且主要是用 Java 語言來開發，門檻相對比較高，應用場景也比較有限。2017 年的時候，開始基于 Kafka 自建了一些實時的消息平台，這個時候才開始把實時消息平台做了一個初步的産品化。
到了 2019 年的時候，我們開始支援 SQL 化的實時資料開發，這些演進跟技術的變化也是分不開的。2021 年我們主要在做一些低代碼資料平台的工作，盡管實時資料開發門檻還是非常高，但是通過梳理應用場景，再把場景标準化、子產品化的梳理，然後在産品層面做配置化來實作低代碼的實時資料開發。到了今年，考慮到降低成本、增加人效，我們主要把精力聚焦在流批一體化産品建設中。
3. 使用者分布
目前實時産品主要使用者中，軟體開發工程師、算法工程師加起來超過 50%，其次是産品經理、資料分析師，還有一些資料挖掘工程師等等。但是對于這些實時資料産品的應用需求往往來自于業務部門的資料分析師、産品經理，比如要快速地擷取到今天的大促效果資料，但由于這塊門檻比較高，是以他們需要找到算法工程師或者是軟體開發工程師去解決他們的問題，是以導緻現在這樣一個使用者構成。其實這也說明了做一個低門檻的開發平台的重要性，就像很多離線資料開發工具一樣，讓很多産品經理或者分析師通過配置的方式不用寫代碼就能擷取到他們想要的實時資料，這是我們要繼續努力的一個方向。
4. 目前問題
在做實時資料産品的過程當中，也面臨一些問題，除了上面提到的門檻比較高之外，還有就是離線跟實時資料的割裂，無論是存儲方面還是代碼層面，導緻在一些涉及到實時和離線資料融合的場景時，使用還比較困難。第三個方面，實時資料産品的高門檻，就導緻人力資源、IT 資源的成本相對來講也是比較高的。鑒于在做實時資料産品過程中遇到的問題，低代碼方向的實施建設迫在眉睫。
--
02
低代碼實時平台建設
1. 挑戰
然而在做低代碼産品過程中面臨的一個挑戰是，業務場景是非常複雜的，技術功能也是非常複雜的，但我們希望産品模式盡可能簡單，盡量把一些技術點給屏蔽掉，這就需要去做平衡。
要解決這個問題，我們對資料使用場景進行了系統梳理，再對這些場景所涉及到的一些問題以及解決方案進行标準化。标準化之後再進行子產品化，隻有通過子產品化才能在産品界面上實作低代碼。
2. 業務場景拆分
具體來講，我們劃分了三個主要應用場景：
一個是統計型的實時資料應用。這一塊主要是把實時的資料效果應用在我們的實時資料營運當中，包括一些可視化的看闆或者是實時的一些分析報表等。
第二類是明細型資料業務，就是要把實時資料計算的結果，作為明細存儲在資料倉庫裡，以及結合離線資料進行關聯分析計算，這塊主要是應用在實時和離線的數倉建構場景當中。
第三個場景是一些複雜事件處理業務場景，這種場景對我們來講也是挑戰最大的，包括複雜的實時算法場景應用、标簽還有一些複雜的實時風控政策、監控告警等等，這些場景往往需要多個實時資料的處理規則去綜合地應用。
劃分完場景後會進行标準化拆分：
- 資料源頭的标準化，就是我們輸入的資料源都有哪些；
- 模型加工的标準化，是對于一些資料處理的邏輯進行标準化的分類；
- 實時計算結果輸出模式的标準化。在标準化完成之後，就需要形成一個固定的子產品化的産品功能，這就是我們建構低代碼實時資料産品的過程，或者說是方法論。
3. 資料處理模型
我們的産品邏輯就是把技術架構或者說資料處理邏輯給封裝起來。實時開發平台的上遊就是我們的資料輸入源，這一塊包括一些業務系統實時産生的資料、消息隊列，或者是實時資料要結合的一些數倉裡面的離線資料，比如實時資料計算需要結合離線的一些維表做一些關聯。
源頭消息接入之後，就是場景化規則拆分。對于這些實時的消息，我們要根據不同的應用場景去做規則分類，形成一個實時資料計算規則引擎，例如對于統計型的常見的一些函數要封裝進去。
不同場景的計算結果會根據下遊業務場景應用，把資料按照這種分鐘級、小時級、天級将計算結果儲存下來，一些明細資料會存到實時數倉裡面去，這些資料綁定下來之後，根據下遊的業務場景去做應用。
4. 産品特點
總結起來低代碼産品特點有三個，第一個比較好了解，就是以低代碼這種方式，通過簡單配置開發來實作實時的資料開發；第二個特點是這種一體化的生态，主要指的是通過實時資料産品和下遊報表開發平台、名額應用平台、算法平台的打通去面向下遊做實時資料的輸出；最後就是技術化賦能，主要指實時資料産品配置化的能力，可以以 API 的方式開放給其他系統，其他系統包括一些風控或是搜尋推薦在做實時資料計算的時候，也可以以低代碼的方式在其産品界面裡面配置。
以實時大屏為例，之前可能開發一個實時大屏，尤其是在資料準備這個階段，可能要花上幾周甚至超過一個月的這種時間，主要複雜在實時資料的開發以及後面的一個測試聯調中。現在這種低代碼的方式來去實作實時資料開發之後效率提升還是非常明顯的，像我們現在幾個小時就可以完成一個這種實時資料大屏的開發。
--
03
流批一體化産品體系
1. 什麼是流批一體
在技術層流批一體很早就實作了，也就是 lambda 架構。那麼基于統一的 Flink 把實時資料處理和離線資料處理基于同一套引擎去完成。當需要流式實時結果的時候跑流式計算，把實時計算結果擷取到；當需要跑批的時候，把批處理的任務提起來之後再去跑批。
但是這個過程中存在一個問題，盡管基于同一套引擎，但由于下遊存儲的媒體是不一樣的，是以需要兩套代碼去維護流批一體架構，這種情況對營運和維護來講成本都是比較高的。出于降本增效的要求，我們定義了業務層的流批一體，就是統一基于 Flink 去開發一套腳本去實作流計算這個流的實時計算和跑批計算，然後再把結果統一存儲到湖倉一體這樣的存儲媒體當中去。這時從開發角度隻需要開發一套腳本。
流批一體從平台能力的角度出發，解決目前資料平台 Lambda 架構下兩套資料鍊路在面臨使用者資料需求時的痛點，包括：叢集維護成本、開發成本、人力成本、一緻性問題，統一了不同媒體資料的業務模型以及加工計算口徑和邏輯，此外還減少了備援資料鍊路，提高了資源使用率。
兩個具體的應用場景，第一個案例就是實時數倉的建設。實時數倉主要是為了去對應離線數倉的通用明細資料層和通用資料彙總層，把這兩層裡面一些相對來講比較核心的資料主題，比如說我們的訂單、流量、使用者等建立一個這種實時的數倉。通過實時通用資料層 RDDM 建設來服務黃金眼/商智、JDV、廣告算法、搜推算法等核心業務。
第二個案例是風控輿情場景，它的業務特點是需要端到端地去做實時的輿情判斷。現在通過流批一體的方式，統一用 Flink 引擎做計算，在整個端到端過程的延時可以控制在一分鐘左右，開發跟維護的成本可以降低大概 30% 以上。
--
04
産品營運：實時資料鍊路三道防線
1. 聯合模組化需求場景
為什麼要講營運呢？因為實時産品的使用，比如在我們的一個大促場景中，它的鍊路非常廣，它的下遊應用場景也非常多，包括實時的資料大屏、實時的資料榜單、實時促銷政策資料效果等，是以保障鍊路的穩定性是前提，同時也是很大的一個痛點，每一個環節出問題對我們來講可能都會有影響。
第二個痛點是這樣一個鍊路裡面各個環節有很多的監控報警資訊，但是都又都比較分散，當出了問題之後排查定位和解決難度很大。
第三個方面就是系統穩定運作主要依賴于研發人員各自的經驗。是以，我們需要形成一套系統化的保障，實時産品就需要一套穩定性營運機制。
這種穩定性營運機制可以總結為三道防線。所謂三道防線，就是分别從事前、事中和事後去保障實時資料計算和應用的穩定性。
第一道防線主要在事前去做風險排查和風險治理，主要通過混沌工程、軍演壓測和業務加強。
第二個防線實際上是針對事中的，就是建構一個比較完整的應用健康度檢測機制。包括故障歸因分析、彈性擴容、應急預案等。那麼最後真正出了問題怎麼辦？那就需要有第三道防線去做事後的處理，主要是通過自動恢複機制去完成。
在三道防線上我們設定了三個名額，分别是故障發生率、故障恢複的時間和備戰時長。通過這三個名額去衡量營運效果的好壞。
未來我們對于實時産品的規劃主要包括三個方面：
- 一方面我們要把低代碼能力覆寫的應用場景再拓展，去适配一些更複雜事件處理場景。
- 第二個方面會去做實時 ETL 工具建設，在實時資料采集、推送等各個方面去實作實時一體化能力，最終形成流批一體 ETL 産品體系。
- 第三個方面就是完善全鍊路自動診斷調優，提升我們診斷以及運維的能力，持續地去降低實時産品的營運維護成本。
今天的分享就到這裡，謝謝大家。
｜分享嘉賓｜
王威｜京東 資料計算平台部産品規劃負責人
畢業于中國傳媒大學，2011年加入京東，先後從事資料開發、資料分析、産品規劃營運等方面工作，目前負責京東大資料平台産品體系建設。
｜DataFun新媒體矩陣｜
｜關于DataFun｜
專注于大資料、人工智能技術應用的分享與交流。發起于2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請超過2000位專家和學者參與分享。其公衆号 DataFunTalk 累計生産原創文章900+，百萬+閱讀，16萬+精準粉絲。