京東 OLAP 實踐之路

分享嘉賓：李陽 京東 資深研發工程師

編輯整理：連志鵬

出品社區：DataFunTalk

導讀**：**本文主要介紹京東在構建 OLAP 從無到有各環節考慮的重點，由需求場景出發，剖析當前存在的問題，並提供解決方案，最後介紹 OLAP 的發展過程。

▌需求場景

1. 京東數據入口

① 業務數據：訂單

京東作爲一家電商企業，擁有自營商品銷售平臺和全鏈路物流通道。首先第一數據入口就是訂單，針對不同訂單進行多維度分析，比如：對訂單分析、對店鋪分析、對商品品類分析等等。

展開對訂單維度來說，因爲我們作爲電商，訂單是非常重要的一個維度分析和數據支撐，所以常結合訂單 SKU，計算品類下單轉化率。

② 行爲數據：點擊和搜索

用戶在京東商城的操作，比如點擊和搜索，我們會將用戶的這些行爲結合訂單信息，來做一些分析，比如分析商品的熱銷和滯銷程度，以及轉化情況，最常見的就是漏斗分析，來計算轉化率。

③ 廣告和推薦

基於用戶下單情況，我們會推送廣告和推薦給到用戶，然後進行計算，分析廣告觸達相關情況。

④ 監控指標

對於監控指標，是我們一個巨大的場景，因爲在我們這裏，除了用戶行爲數據，還有很多運維的數據也需要管理起來。

2. 京東數據出口

京東的數據出口，主要分類兩大類：離線和實時

① 離線

典型離線場景：財務報表經常需要月報週報。

• 機器學習

會用到大量的一些訓練數據，這些數據的生成也會用到 OLAP 的一些特性來把數據進行分析，產生一些訓練的數據。

② 實時

• 交互式查詢

非研發同事，比如營運分析人員，經常需要臨時查詢業務數據，比如查詢最近一週訂單的彙總以及明細數據，對這些數據進行分析，輔助決策。

• 實時大屏展示

平臺做大促或者實時監控運營情況，會依照大屏的指標，實時動態調整資源。比如營銷策略、廣告費投入、供應鏈庫存。尤其重要的是，在大促銷的時候，可以進行動態資源的調整，比如車輛資源調度、根據促銷效果決策活動是否需要進行調整等。

▌問題與解決方案

以上是京東的部分業務場景，和大多數闡述數據架構不同，我們本次將數據搭建的過程分爲 4 個方面：數據怎麼寫進來；寫進來以後怎麼進行存儲；存儲以後又怎麼進行取用；最後是如何管理前 3 個環節。

1. 寫

① 數據源及數據結構多樣性

現狀：

數據源來源多樣化：文件系統（本地文件 & 分佈式系統文件）& MQ

• 本地文件，比如說服務器本地的數據，直接導入進來

• 數據量比較大時，在用戶本地存不了這麼大的數據量，會將數據存儲在 HDFS 上

• Kafka 或者 MQ 數據，上游將產生的數據直接存儲到消息隊列中，在京東內部，這種 MQ 的系統有多個，但是我們需要統一進行接入

• 數據結構的多樣化，最常見：CSV、TSV、JSON、AVRO、PARQUET、BINLOG 等

問題：

多種數據源及數據類型，對於開發人員來說，進行數據分析的成本相對比較高，我們希望分析人員，只需要專注於業務邏輯本身，直接進行 SQL 查詢，而無需關心數據來源。

解決方案：

• 選擇數據源的 topic

• 指定導入的目標源

• 選擇數據格式

• 選擇對應的數據字段類型等等

② 數據的時效性

現狀：

實時的數據需要實時進行計算和展示；離線的數據，可以定時的推送並計算一次，對時效的要求比較低。

問題：

如何保證實時和離線數據的時效性，且不會相互影響？

解決方案：

對實時集羣和離線集羣進行物理隔離，防止互相干擾，這樣做的好處有：

實時和離線對於資源的需求不同，實時數據寫入非常頻繁，而離線的數據只是在指定運行的時間點比較多，區分開便於管理。

③ 數據的更新和刪除

問題：

對於 OLAP 的架構來說，如何做到既要查詢搜索又要更新呢？

解決方案：

• 數據更新，採用覆蓋寫的方案。以訂單爲例，用戶下了一個訂單 1，此時下單狀態爲 1，後面用戶進行了支付操作，訂單狀態爲 2，那麼我們會重新推送一條全量的數據，只是狀態的字段值發生看變化。

• 數據刪除，採用刪除分區然後重新導入這個分區數據，或者採用版本管理方式，因爲通過新版本的數據會覆蓋原來的版本，起到刪除的作用。

③ 高吞吐

問題：

以京東現在的體量，每天的數據是很大的，如何解決高吞吐問題呢？

解決方案：

機房配置萬兆網絡，另外對於實時場景，配備 SSD；離線場景，配備 HDD。

2. 存

① 海量數據

問題：

• 採用分佈式解決大規模數據的問題。

• 爲了提高效率，採用了列式存儲，對後續指標的計算效率也有提升，其實在 OLAP 的架構中，大多數都是列式存儲。

• 採用不同類別的壓縮方式，比如 snappy 等。

② 容錯性

問題：

數據現在是科技類企業非常重要的資產，那麼如何保障數據的安全性性呢？

解決方案：

其一：多副本的容錯方式，我們的 OLAP 採用三副本的方式，所以其中 1 個或 2 個副本損壞或遷移時做擴容都比較容易處理。

其二：RAID 獨立磁盤冗餘陣列（RAID，redundant array of independent disks），因爲磁盤金屬機器經常會壞，加上有一些機器過保存在損壞的風險，所以我們也通過 raid 解決一部分數據容錯性的問題，防止磁盤壞掉之後整個機器不能提供服務的情況。

③ 一致性

解決方案：

解決數據的一致性的問題，需要使用到分佈式協調和本地事務機制。

• 分佈式協調，比如 zookeeper

• 本地事務機制：對於本地的提交，是否通過事務來保證數據的一致性

通過兩者的結合，來實現數據的一致性。

3. 讀

① 查詢速度

問題：

數據存儲到系統中以後，如何高效的進行取用呢？

解決方案：

• 通用方式，數據進行分區分片，在很多場景，對數據的分析都是按照時間進行分區，分區以後，再進行分片或者分桶。

  比如：訂單信息，我們可能按天查詢，那麼就可以按照實際日期進行分區；比如，存儲 10 年的數據，不可能全部查詢，我們按照統計則按月進行分區。

• 預聚合，提前進行預計算，減少一次性計算的數據量，提高性能。

• 索引，大部分場景下會使用索引，比如做明細查詢，可能會到 hash 索引、betree、範圍查詢或者倒排。

• 物化視圖，其實和預聚合的功能類似，數據進入到物化視圖中時，提前進行一些預計算。

② 易用性

問題：

如何實現系統的易用性？

解決方案：

• 需要 OLAP 系統兼容 JDBC 和 ODBC，同時支持標準的 SQL。

• 提供界面化的操作，這種方式可以避免所有的運營分析人員都具備 Mysql 等數據庫的環境，可以直接登入圖形化界面進行查詢的操作。

③ QPS

問題：

如何提高 QPS？

解決方案：

• 緩存，使用 doris 時，增加比如 partitioncache，或者結果級緩存，或者分區緩存機制來提升查詢效率。

• 多副本，設置多副本的方式，通過犧牲部分存儲空間，來提升 QPS，但是這個效果有限。

• 提升機器的規模。

4. 管理

現狀：

早期我們碰到磁盤壞了，搞得手忙腳亂，替換磁盤或者是下機器操作時間很長，而且這個操作完成之後還涉及重新平衡數據或者數據遷移，這個過程非常麻煩。

問題：

如何降低運維成本？

解決方案：

• 建設監控和報警機制，進行提前預防。

• 優化節點的下線，在京東系統中，有兩種方式：

  方式 1：通過黑名單的方式，如果監控到某個節點經常不健康，我們會把它納入黑名單，並將他踢下線了。

  方式 2：通過腳本操作，但是從最開始我們需要替換一個節點，估計從發現到替換完成得三小時，現在通過一些比較自動化的東西，現在大概十分鐘左右能做到一個節點的替換。

▌發展歷程

1.0 時代

1.0 時代的場景比較少，數據量也比較少，主要是訂單相關的一些數據，分析通過關係型數據庫就能搞定，比如說 oracle 或者 mysql。

可通過數據儲備同步到備庫做分析，或者 mysql 一個是 slave 庫，主庫做一些利用線上業務，然後備庫對存貨的一些分析和查詢。

2.0 時代

到了 2.0 場景，不再是簡單處理訂單問題，還要處理物流、供應鏈、客服、支付等等場景。

場景大增，數據量也爆發式增長，從原來的 G 到現在的 TB 甚至 PB 級別。傳統關係性數據庫，已經不能滿足需求了。

這個時候我們開始搭建了離線數倉，在數倉中進行分析，主要用 Hive 和 Spark 進行計算，數據都是 T-1，臨時查詢數據的體驗非常差，需要耗時分鐘級別且還是昨天的數據。

3.0 時代

爲提升查詢數據的速度和數據的時效性，開始做實時查詢。我們現在使用統一 OLAP 服務，從最開始使用 Kylin 處理一些離線的業務，到現在我們用了 doris 和 clickhouse 結合起來，同時處理實時和離線，統一服務接口，對用戶和開發人員開放。

同時針對不同的業務，提供不同的計算引擎，我們現在提供一個整體打包解決方案，業務只需要在 OLAP 的服務上，進行統一部署到數據技術平臺即可，大大減少了開發成本。

未來規劃

① 管理平臺優化

• ClickHouse 的動態伸縮。

• 智能化運維。智能優化節點上下線或者數據均衡這些方面的工作。主要想要通過減少人工干預操作，降低時間的浪費。在京東的系統中，現在擁有上千臺的服務器，如果一直由人工來處理的話，那麼成本非常高。

② 優化查詢速度

• 優化實時計算緩存。在 doris 中，使用 partitioncacahe 或者 sqlcache 在離線場景中比較有效，後續將考慮在實時計算中引入緩存進行優化。

• 索引智能化管理。索引的引擎有非常多種，如果需要開發人員瞭解所有的引擎，學習成本是比較高的，我們能不能做成智能化的索引引擎呢？這樣的話用戶不需要再去關心類似的一個索引怎麼建的問題，而是我們在通過用戶的一些查詢行爲分析，自動的來給他做索引的創建，這樣簡化工作成本，讓開發人員有更多的心思去做好運營和分析。

▌問答環節

Q1：請問老師貴司有用過 druid 引擎嗎？

A1：沒有，我們調研發現，第一，druid 對 sql 的支持不是很友好；第二，druid 擅長於持續性的數據場景，但是京東訂單是一個頻繁發生狀態變化的一個場景，它是不太好處理的，所以當時我們也沒有選 druid。

Q2：clickhouse 和 doris 如何根據業務場景選型，有哪些坑？

A2：

第一，查詢性能：在查詢表不多即沒有太多表關聯情況下，clickhouse 查詢速度比較快，但是在做大表關聯查詢時，doris 的性能會好於 clickhouse。

第二，QPS：clickhouse 是在極限使用 CPU 的性能，但是 doris 的 QPS 性能在某些場景下會比 clickhouse 好。

第三，運維成本：doris 的運維成本會小於 clickhouse，至少現在對我們來看，因爲它會有節點自動上下線擴容收容會很方便，但是 clickhouse 做這個方面比較麻煩。

第四，數據更新：clickhouse 數據更新的引擎有三種，用戶在使用的時候比較麻煩，但是 doris，它直接進行數據覆蓋，就能做到一個更新，操作更方便。

Q3：doris 和 clickhouse 是自動選擇，還是需要用戶自己去選，如果是自動選的話，識別機制是什麼樣的？

A3：目前還沒有做到自動選。當前先整體提供解決方案，我們爲用戶提供技術支撐，未來可能會想着如何去打通統一化，因爲它的模型創建不太一樣，它的 sql 是有差異的。

Q4：數據接入 CK 方面，京東目前是什麼樣的方案？

A4：目前有兩條路線。

一個是用戶自己業務側接入，因爲有些歷史原因，用戶他已經用了很久的 clickhouse，他自己有比較成熟的一套接入系統。

一個是使用 clickhouse 來接入，不管是從離線還是從 kafka 中，這種方式是我們在平臺側，在平臺側開發了統一的 OLAP 服務，用戶可以上面操作。就如前面所說，用戶選擇數據源，再選一個目標源，點擊它執行導入，就可以完成。

今天的分享就到這裏，謝謝大家。 

分享嘉賓：

李陽

京東 | 資深研發工程師

京東資深研發工程師，擁有超過 10 年研發經驗，擅長 OLAP 相關服務研發及分佈式系統設計。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/VbmFwEi_RZ2xGLjfHLGJHw