1. 使用 Kylin 的緣由

愛奇藝 OLAP 服務演變

愛奇藝大數據 OLAP 服務演變的過程可以用如下架構圖說明：

數據處理流程分為如下幾個層級：

• 最下方是采集平臺，收集業務的埋點和日志；
  
  

• 數據按時效性分為兩種類型：離線類型的灌入到 HDFS，實時數據灌入到 Kafka；
  
  

• 往上是各種分析引擎，Hive 用于 PB 級別的離線分析，Kylin 用于每日報表，針對相對固定的維度進行分析，Impala 用戶 Ad-hoc 場景，Kudu 支持實時更新和分析，Druid 針對的是實時事件流；
  
  

• 在這些引擎之上是統一的 SQL 引擎 -- Pilot，負責引擎和數據源的智能路由，基于此構建了 BI 分析平臺，工作流平臺，自定義 SQL 查詢平臺，實時分析平臺等。

愛奇藝發展的大體時間線，2015 年前以離線分析為主，技術上是經典的 Hive + MySQL 方案，但缺點是報表查詢比較慢，而且數據時效性差；2016 - 2018 年致力于將查詢耗時提升至交互式級別，分為兩大類：Kylin 針對固定報表，在維度比較有限的情況下，通過一個預處理，TB 級別數據延時能在秒級，而 Impala 則針對 Ad-hoc 類場景，可以查詢任意明細數據；2018 年以后從離線往實時去發力，其中 Kudu 支持實時插入和更新，Druid 支持事件流場景。

Kylin 典型需求

數據分析中一個典型場景是用戶行為分析，譬如用戶在 APP 上進行一次點擊，采集之后進行分析。下面為一個示例 SQL，分析首頁過去一天的展示次數。

SELECT?COUNT(1)?as?cnt FROM?hive_table_user_act WHERE?act_type?=?'display’ AND?page?=?'home' AND?dt?=?'2020-07-18';

此類查詢傳統是用 Hive 表去做分析，具有如下幾個特點：

• 維度固定：分析的模式每日變化不大；

• 時效不高：分析昨日（T+1）的使用情況；

• 交互延時：查詢延時要求比較高，通常在秒級；

• 數據量大：每日規模百億行的量級。

經典的技術架構如下圖所示：

即撰寫預計算的 SQL，通過 Spark 或 Hive 查詢，將結果集存入到 MySQL，用戶報表查詢直接 MySQL 里面去讀取。這個方案有以下幾個缺點：

• 預處理慢
  Hive/Spark 任務隨著預計算 SQL 數量的增加（因維度增加），耗時會隨之增加，甚至超過一天；
  
  

• 擴展性差
  當預計算結果集大到 MySQL 單機無法存下時，Cube 自身也面臨擴展性問題；
  
  

• 變更困難
  每當分析師有新的需求，均需工程師修改預處理 SQL，排期進行開發，迭代慢且開發量大；
  
  

• 資源浪費
  手動書寫的預計算 SQL 會有較多的重復計算，通常優化的不是特別好，在資源上也是有很大的浪費。

2. Kylin 在愛奇藝的現狀

Kylin 簡介

為了克服 Hive + MySQL 方案的上述缺點，愛奇藝引入了 Kylin 來進行固定報表分析。Kylin 是一款基于 Hadoop 產品針對固定報表的 SQL 分析引擎，核心思想是預計算，即提前將報表分析結果（Cube）算好存入到 HBase，報表查詢直接從 Cube 里讀取，查詢速度非常快。

以前文用戶行為分析為例，愛奇藝改用?Kylin?后取得了如下效果：

• 預處理快
  處理時間縮短至 1/10，從一天跑不完到 2.5 小時跑完；
  
  

• 擴展性好
  一個輸入量級在百億每天的表，構建 9 維 Cube 都比較輕松；
  
  

• 易于調整
  Kylin 在頁面拖拽即可調整分析的維度和度量，無需開發；
  
  

• 節約成本
  實測下來節省了 50% 的計算資源。

下圖為當時選型的測試結果：

除了 Kylin，當時也調研了 Impala。Impala 相比 Hive 優勢明顯，查詢延時從十幾分鐘縮短到 1 分鐘以內，但畢竟要從原始數據開始查詢，帶寬等物理限制決定了查詢速度的上限，相比于 Kylin 預構建的模式來說速度還是有明顯差距。針對報表類交互式查詢，Kylin 是更為合適的。

Kylin 在愛奇藝落地

現在，Kylin 在愛奇藝被廣泛使用，已經在 20 多個業務落地，包括 BI、搜索、推薦。總計有 268 個 Cube，每天輸入數據在 4 千億行，每天構造出來的 Cube 有 3TB，Cube 總量在 800TB；查詢估計一天有上萬個，分析下來查詢耗時 P95 < 10 秒，能夠較好地滿足需求。

3. Kylin 在愛奇藝的優化

業務架構影響

采用 Kylin 對業務架構也起到了積極的作用，最直接的就是業務的使用成本降低了。以推薦為例，分析各個模型的推薦效果，會采用如下圖所示架構：

用戶點擊行為被存放于 Hive Pingback 表，而視頻特征被存放于 Hive 維度表，如果要分析 3 個維度，每個維度 3 個度量，則需要對每種維度和度量的組合，撰寫一個 SQL 去處理，總計 9 個預處理?SQL，Pingback?表和度量表被?JOIN?了 9?次，并且數量隨著分析的增加還會繼續膨脹。

而 Kylin 會將事實表和維度表處理成大寬表，后續的計算復用大寬表，從而 JOIN 的數量從 9 降低至 1，計算耗時、成本均大幅降低。此外 Kylin 還大幅降低需求變更的難度，原先增加一個維度/度量，需要改多個腳本，幾天的開發量；現在只需在頁面上調整，做一下測試，然后重新構建一下即可，小時內即可完成。除此之外，Kylin 還提供精確去重的功能，原先業務是自己在腳本里實現，依賴于腳本書寫的好壞，Kylin 提供了一個標準、精確的實現，對業務去重的精度也有提升。

獨立 HBase 集群

愛奇藝 Kylin Cube 的量級比較大，早期，我們按照社區的標準部署模式，也就是復用現有公共集群的 HBase，面臨了種種挑戰。

混布模式下，每一個 Hadoop 集群都有 HBase 服務，Kylin 把預處理的結果加載到本集群 HBase。這個模式有兩個痛點：

• 穩定性差
  HBase 集群上還有其他業務，若其他業務讀寫壓力較大，Kylin 查詢會受影響；反過來 Kylin 大量查詢時，也會對其他業務產生影響。當有很多個 HBase 集群時，任意 HBase 不穩定都有部分 Kylin 業務受影響；
  
  

• 資源浪費

  并非所有部署了 Hive 服務的集群都有 HBase，想在該集群使用 Kylin 還需在集群上部署 HBase 服務。

我們參考社區的建議，采用了獨立 HBase 集群的部署模式。即 Kylin 還是從 Hive 集群讀取數據，構建 Cube，最終結果跨集群加載到 Kylin 專用 HBase 集群。這個方案需要配置一下跨集群作業，參照社區的案例也不復雜；除了解決以上兩個痛點，還有一個額外的好處，就是該方案能對獨立 HBase 做針對性優化。因為 Kylin 專用 HBase 集群沒有寫入，而是通過 Bulkload 加載，故可針對讀進行優化。如把內存絕大部分用于讀緩存、讀寫線程池也偏向于讀、采用固定分裂策略，Cube 表不存在分裂或合并。

采用獨立 HBase 部署模式后效果明顯。穩定性上，查詢不可用時間相比于混布 HBase 降低至 25%。查詢速度上，平均下來有 30% 的提升。

Kylin?服務平臺

Kylin 服務平臺定位是統一收集、存儲各集群的信息，包括元信息、任務、查詢，用于診斷和優化。

Kylin 自身也具備一定排障能力，比如通過 Web UI 查看 Cube 大小、失敗任務等，但其信息是割裂的，部署幾十個實例后，不可能每天打開幾十個 Web 逐一分析。故此我們決定開發 Kylin 服務平臺，其架構如下圖所示：

基本思想是把需要的信息采集起來，統一存儲，提供 API 和統一的 Web 界面，并開發智能診斷的邏輯，包括 Cube 膨脹率過大、Job 失敗過多、查詢變慢等等。

Cube 生命周期管理

用戶平臺的一個落地場景是 Cube 生命周期管理。如果不做管理，Kylin 對 HBase 的壓力是很大的，包括表數量、Region 數量、超大 Cube，輕易即可壓垮 HBase 集群。原先都是集群異常后，我們再手動分析 Region 來源，推動業務優化。現在通過用戶平臺的診斷，很容易分析出常見的不合理場景：Cube 未配置 TTL、未配置 Merge 策略、膨脹率過高、Cube 過大等等。平臺也可基于歷史的查詢分析，判斷出多久的數據不被訪問，自動給出 TTL 的建議值。下圖為診斷的效果圖：

任務智能診斷

用戶平臺另一個落地是任務智能診斷。之前，業務構建任務失敗后通過 Kylin Web 能看到如下圖所示的失敗信息，但分析師很難理解錯誤的含義，只能提交一個運維工單，由 Kylin 運維人員進行修復。這個過程對雙方都很痛苦：分析師的錯誤響應很慢，而運維人員則需要處理大量的工單。

為此，我們開發了任務智能診斷模塊。我們總結了 18 種常見的錯誤，每一種錯誤都給出易于理解的原因，修復意見，并附有手冊詳細描述。平臺會采集任務的失敗信息，和常見的錯誤進行匹配，下圖是一個錯誤在平臺上看到的效果。用戶能基于診斷結果進行自助排障。

參數優化

1.? Hive 構建全局字典

在 Kylin 3.0 中引入，之前版本中構建全局字典是通過一個單線程完成，往往會成為 Cube 構建的瓶頸。下圖是優化后的效果，可以看到構建時間縮短至之前 1/3。

2. 高基數維度構建字典并發配置

即 Kylin 可以指定一個列是高基數維度，并指定其構建字典的并發度（kylin.engine.mr.uhc-reducer-count=5）。例如 Hive 表有 9 個維度列，其中 8 個基數小，1個基數大，則構建字典任務的 9 個 Reducer 會有一個特別慢。使用上述配置高基數維度會以 5 并發構建，有效地縮短了時間。

4. 未來展望

后續，我們計劃朝以下幾個方面發展：

1. 自動構建 Cube

當前落地的業務場景都是強需求，Cube 構建是業務主動來做。后續希望能夠分析現有的 Hive 查詢，自動發現內聚度高的表，構建 Cube 并代替掉原有的查詢；

2. 集群化

當前每個業務一個實例，稍微有一些大查詢就會引起性能波動。若給每個業務部署多個實例，則平時利用率又非常低。通過集群化部署的模式，每個用戶都能用到全部的實例，穩定性會大幅提升；

3. 平臺化

平臺化也會繼續深入，降低業務構建 Cube 的代價。通過平臺來托管，業務無需自行管理 Cube 的構建。

關于作者

林豪，愛奇藝資深研發工程師，任大數據服務 OLAP 組負責人，自 2016 年起推進公司內 OLAP 技術架構升級。

猜你喜歡

1、每個大數據工程師都應該知道的OLAP 核心知識點

2、Presto on Spark：擴展 Presto 以支持大規模 ETL

3、Spark SQL 分桶表在字節跳動的優化

4、Flink SQL 1.11 新功能與最佳實踐

過往記憶大數據微信群，請添加微信：fangzhen0219,備注【進群】

總結

以上是生活随笔為你收集整理的爱奇艺千亿级数据查询服务实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。