一、背景

?

斗魚是一家面向大眾用戶的在線直播平臺，每天都有超大量的終端用戶在使用斗魚各客戶端參與線上互動。伴隨業(yè)務(wù)的迅猛發(fā)展，斗魚需要對客戶端采集到的性能數(shù)據(jù)進行統(tǒng)計和分析，開發(fā)出具有多維度分析圖表和數(shù)據(jù)監(jiān)控的 APM （Application Performance Monitoring，應(yīng)用性能監(jiān)控） 平臺。

?

針對不同的客戶端采集的不同數(shù)據(jù)，我們需要將各種維度之間相互組合并聚合，最終產(chǎn)出的數(shù)據(jù)變成指標(biāo)在圖表中展示。例如：對在時間、地域、網(wǎng)絡(luò)環(huán)境、客戶端以及 CDN 廠商等維度聚合下的各項指標(biāo)情況進行多維度分析，包括客戶端網(wǎng)絡(luò)性能（包含完整請求耗時，請求耗時，響應(yīng)耗時，DNS 耗時，TCP 耗時，TLS 耗時等等指標(biāo)）各類錯誤時間段內(nèi)的占比以及詳細(xì)數(shù)量、狀態(tài)碼分布等等。圖一和圖二分別是兩個示例：

△ 圖一

△ 圖二

?

我們最初的 APM 平臺采用了市面上非常流行的?Elasticsearch （簡稱 ES）實時聚合實現(xiàn)。配合自研多數(shù)據(jù)源統(tǒng)一接口（EST 多數(shù)據(jù)源統(tǒng)一接口平臺）框架，能夠?qū)崿F(xiàn)維度指標(biāo)的自由組合查詢。數(shù)據(jù)采用 storm 實時消費 kafka 寫入 ES，做到了數(shù)據(jù)的實時展示。告警采用定時查詢 ES 的方式。

?

不過運行一段時間后，我們發(fā)現(xiàn)基于 ES 的方案存在問題：采用 ES 實時聚合的方式，大多數(shù)時候?qū)蝹€字段的聚合查詢是非常快的，一旦遇到較為復(fù)雜的多維度組合查詢并且聚合的數(shù)據(jù)量比較大（如數(shù)十億），就可能會產(chǎn)生大量的分組，對 ES 的性能壓力很大，查詢時間很長（幾十秒到數(shù)分鐘）導(dǎo)致用戶難以等待，還可能會遇到數(shù)據(jù)精度丟失的問題。因此為了支撐業(yè)務(wù)發(fā)展，考慮再三我們決定尋找替代方案，注意到 Apache Kylin 在大數(shù)據(jù) OLAP 分析方面非常有優(yōu)勢，于是決定采用?Kylin 替換 Elasticsearch， 對斗魚 APM 平臺中存在的問題進行優(yōu)化。不試不知道，一試嚇一跳，效果還真的不錯。

?

二、使用 Kylin 的挑戰(zhàn)和解決方案

我們使用 Kylin 的過程也不是一帆風(fēng)順的，期間不斷學(xué)習(xí)、摸索、踩坑，積累了一定的經(jīng)驗。這里分享一下我們遇到的一些挑戰(zhàn)，以及找到的解決辦法。

?

1. Kylin 集群的搭建

由于是第一次使用 Kylin，而 Kylin 依賴 Hadoop，其集群的搭建便是第一道難題。作為獨立業(yè)務(wù)使用，為了保證業(yè)務(wù)的穩(wěn)定性，不能依賴于公司的 Hadoop 主集群，所以需要單獨搭建一整套供 Kylin 使用的運行環(huán)境。

?

Kylin 支持主流的 Hadoop 版本。圖三是 Kylin 官網(wǎng)介紹的 Kylin 對各組件的版本依賴，可以看到還是比較容易滿足的。

△ 圖三

?

Hadoop 集群我們選擇了主流的 Cloudera CDH 5.14.4，Kylin 2.4.1。采用 CM 的模式搭建，目前集群共17臺機器，其中 CM 節(jié)點3臺，角色包含 HDFS，YARN，Zookeeper，Hive，HBase，Kafka（主要是消費使用），Spark 2 等。其中 4 臺機器上部署了 Kylin 服務(wù)，采用了 1 個 “all“ 節(jié)點，1 個 “job“ 節(jié)點，2個 “query“ 節(jié)點的模式，確保了查詢節(jié)點和任務(wù)節(jié)點都互有備份，滿足服務(wù)的高可用。

?

2. 構(gòu)建實時 Cube 中的問題

斗魚客戶端收集到的 APM 數(shù)據(jù)會先暫存于 Kafka 消息隊列中，Kylin 支持直接從 Kafka topic 中攝入數(shù)據(jù)而不用先落 Hive，于是我們選擇了這種直連 Kafka 的方式來構(gòu)建實時 Cube。

?

1）Kafka 數(shù)據(jù)格式要求

Kylin 的實時 Cube 需要配置基于 Kafka topic 的 Streaming Table (將 Kafka topic 映射成一張普通表）。這一步不同于基于 Hive 的數(shù)據(jù)表（Kylin 可以直接從 Hive metastore 獲取表的字段信息），需要管理員進行一定的手工配置，才能將 Kafka 中的 JSON 消息映射成表格中的行。這一步對 Kafka 中的數(shù)據(jù)格式和字段有一定的要求，起初因為不了解這些要求，我們配置的 Cube 在構(gòu)建時經(jīng)常失敗，只有少數(shù) Cube 構(gòu)建成功。也有的 Cube 很多次都構(gòu)建成功，但偶爾會有失敗。針對這些問題我們進行了一系列的排查和改進。

?

a. 由于我們原始數(shù)據(jù)在 kafka 中的存放格式為數(shù)組格式（JSON 字符串），所以在創(chuàng)建 Streaming Table 的時候會遇到下面的問題：

Kylin 會將數(shù)組中識別的字段默認(rèn)加上數(shù)組下標(biāo)，例如圖中的 0_a，0_b 等，與我們的預(yù)期不符，所以需要對數(shù)組數(shù)據(jù)進行拆分。也就是說，Kylin 期望一條消息就是一個 JSON 對象（而非數(shù)組）。

?

b. 我們原始數(shù)據(jù)中還有嵌套的對象類型的字段，這種類型在 Kylin Streaming Table 識別的時候也可能會有問題，同樣需要規(guī)整。如 Kylin 會把嵌套格式如 "{A: {B: value}}" 識別為 A_B 的字段，如下圖，所以使用起來同樣也可以，這個根據(jù)業(yè)務(wù)的不同可以自由選擇，我們采用了將嵌套字段鋪平來規(guī)避后面可能出現(xiàn)的問題。

c. 這個是比較難發(fā)現(xiàn)的一個問題，就是在設(shè)計好 Cube 之后，有時會有 Cube 構(gòu)建失敗的情況，經(jīng)過排查之后發(fā)現(xiàn)，是由于公司業(yè)務(wù)數(shù)據(jù)來源的特殊性（來自于客戶端上報），所以可能會出現(xiàn) Kafka 中字段不一致的情況。一旦出現(xiàn)極少數(shù)字段不一樣的數(shù)據(jù)混在 Kafka 中，便極有可能讓這一次的 Cube 構(gòu)建失敗。

?

基于以上幾點，我們總結(jié)，Kylin 在接入 Kafka 實時數(shù)據(jù)構(gòu)建之前，一定要做好數(shù)據(jù)清洗和規(guī)整，這也是我們前期耗費大量時間踩坑的代價。數(shù)據(jù)的清洗和規(guī)整我們采用的是流處理（Storm/Flink）對 Kafka 中的數(shù)據(jù)進行對應(yīng)的處理，再寫入一個新的 Kafka topic 中供 Kylin 消費。

?

2）任務(wù)的定時調(diào)度

Cube 的構(gòu)建任務(wù)需要調(diào)用 API，如何定時消費 kafka 的數(shù)據(jù)進行構(gòu)建，以及消費 kafka 的機制究竟如何。由于對 Kylin 理解的不夠，一開始建出來的 Cube 消耗性能十分嚴(yán)重，需要對所建的 Cube 配合業(yè)務(wù)進行剪枝和優(yōu)化。

?

構(gòu)建實時 Cube 和構(gòu)建基于 Hive 的離線 Cube 有很多不一樣的地方，我們在使用和摸索的過程中踩了很多坑，也有了一定的經(jīng)驗。

?

由于是近實時 Cube 構(gòu)建，需要每隔一小段時間就要構(gòu)建一次，采用服務(wù)器中 Kylin 主節(jié)點上部署 Crontab-job 的模式來實現(xiàn)。

?

調(diào)度的時間間隔也經(jīng)過了多次試驗，調(diào)度的時間短了，上一個任務(wù)還沒有執(zhí)行完，下一個就開始了，容易產(chǎn)生堆積，在高峰時期容易造成滾雪球式的崩塌；調(diào)度的時間長了，一次處理的數(shù)據(jù)量就會特別大，導(dǎo)致任務(wù)執(zhí)行的時間和消耗的資源也隨之增長（Kylin 取 Kafka的數(shù)據(jù)，是比較簡單粗暴的從上一次調(diào)度記錄的 offset 直接取到當(dāng)前最新的 offset，所以間隔時間越長，數(shù)據(jù)量越多），這是一個需要平衡的事情。經(jīng)過反復(fù)測試使用，以及官方相應(yīng)的介紹下，我們發(fā)現(xiàn)任務(wù)執(zhí)行時間在 10~20 分鐘為最優(yōu)解，當(dāng)然根據(jù)數(shù)據(jù)量的不同會有不同的調(diào)整。

?

3）Kylin 的剪枝與優(yōu)化

由于業(yè)務(wù)比較復(fù)雜，每個 Cube 的維度可能特別的多，隨著維度數(shù)目的增加 Cuboid 的數(shù)量會爆炸式的增長。例如 WEB 端網(wǎng)絡(luò)性能分析的 Cube 維度可能達到 47 個，如果采用全量構(gòu)建，每一個可能情況都需要的話，最多可能構(gòu)建 2 的 47 次方，也就是1.4 * 10^14 種組合，這肯定是不能接受的。所以在 Cube 設(shè)計的時候一定要結(jié)合業(yè)務(wù)進行優(yōu)化和剪枝。

?

首先是篩選，將原始數(shù)據(jù)中根據(jù)不同的業(yè)務(wù)，選擇不同的字段進行設(shè)計，以Ajax性能分析為例，選擇出需要使用的 25 種維度。（2^47 -> 2^25）

?

接下來是分組，將 25 種維度按照不同的場景進行分組，例如，地域相關(guān)的可以放在一起，瀏覽器相關(guān)的也能分為一組。我們將場景分為了 4 組，將指數(shù)增長拆分為多個維度組之和。好的分組可以有效的減少計算復(fù)雜度，但是沒有設(shè)計好的分組，很可能會由于設(shè)計問題沒有覆蓋好各種場景，導(dǎo)致查詢的時候需要二次聚合，導(dǎo)致查詢的性能很差，這里需要重點注意。（2^25 -> 2^12 + 2^13 + 2^14 + 2^13）

?

然后是層級維度（Hierarchy Dimensions）、聯(lián)合維度（Joint Dimensions）和必要維度（Mandatory Dimensions）的設(shè)置。這三個官網(wǎng)和網(wǎng)上都有大量的說明，這里不加贅述。最終實現(xiàn) Kylin 的剪枝，來減少計算的成本。

?

最后是 Kylin 本身一系列的配置上的優(yōu)化，這些針對各自業(yè)務(wù)和集群可以參照官方文檔進行調(diào)參優(yōu)化。

?

3. Kylin 集群相關(guān)優(yōu)化

起初我們?yōu)?Kylin 集群申請的機器類型是計算密集型，沒有足夠的本地存儲空間。Kylin 在運行的過程中磁盤經(jīng)常滿了，常常需要手動清理機器。同時在前期運行的過程中時不時會出現(xiàn)「Kylin 服務(wù)掛了（或者管理端登不上）」，「HBase 掛了」等等情況，針對遇到的這幾個問題，我們有一些解決的措施。

?

1）磁盤不足。因為 Kylin 在構(gòu)建 Cube 的時候，會產(chǎn)生大量的臨時文件，而且其中有部分臨時文件 Kylin 是不會主動刪除的，所以機器經(jīng)常會出現(xiàn)磁盤空間不足的問題（也跟我們計算型機器磁盤空間小有關(guān)）。

?

解決辦法：采用定時自動清除，和手動調(diào)動 API 清除臨時文件，擴容 2 臺大容量機器調(diào)整 Reblance 比例（這才徹底解決這個問題）。

?

2）服務(wù)不穩(wěn)定。剛開始的時候集群部分角色總是掛起（例如 HDFS、HBase 和 Kylin 等），排查發(fā)現(xiàn)是由于每臺機器存在多個角色，角色分配的內(nèi)存之和大于機器的可用內(nèi)存，當(dāng)構(gòu)建任務(wù)多時，可能導(dǎo)致角色由于內(nèi)存問題掛掉。

?

解決辦法：對集群中各個角色重新分配，通過擴容可以解決一切資源問題。添加及時的監(jiān)控，由于 Kylin 不在 CM 中管理，需要添加單獨的監(jiān)控來判斷 Kylin 進程是否掛掉或者卡住，一旦發(fā)現(xiàn)需要重啟 Kylin。要注意有 job 的節(jié)點重啟時需要設(shè)置好 kafka 安裝路徑。

?

4. HBase 超時優(yōu)化

Kylin 在后期維護中，經(jīng)常會有任務(wù)由于 operationTimeout 導(dǎo)致任務(wù)失敗。如圖：

這個報錯讓 Cube 構(gòu)建常常失敗，且一旦構(gòu)建失敗超過一定的次數(shù)，該 Cube 就不會繼續(xù)構(gòu)建了，影響到了業(yè)務(wù)的使用，針對此問題也進行了相應(yīng)的排查，發(fā)現(xiàn)是構(gòu)建的時候，可能會由于 HBase 連接超時或者是連接數(shù)不夠造成任務(wù)失敗。需要在 CM 中調(diào)整 HBase 相關(guān)參數(shù)。包括調(diào)整 hbase.rpc.timeout 和 hbase.client.operation.timeout 到 50000 等（之前是 30000，可以根據(jù)業(yè)務(wù)不不同自行調(diào)整，如果還有超時可以優(yōu)化或者繼續(xù)調(diào)整）。

?

5. 已有 Cube 的修改

由于業(yè)務(wù)的迭代，新增了幾個維度和指標(biāo)需要增加在已存在的Cube上，又例如原先 Cube 設(shè)計上有一些不足需要修改。在這方面例如 DataSource 沒有修改功能，新舊 Cube 如何切換，修改經(jīng)常沒有響應(yīng)等等問題讓我們十分為難。

?

已有 Cube 的修改是目前使用 Kylin 最為頭疼的地方。雖然 Kylin 支持 Hybrid model 來支持一定程度的修改，但是在使用的過程中因為各種各樣的原因，例如 Streaming Table 無法修改來新增字段等，還是未能修改成功。

?

目前采用的修改模式為，重新設(shè)計一整套從 DataSource 到 Model 再到 Cube，停止之前 Cube 的構(gòu)建任務(wù)，開始新 Cube 的構(gòu)建調(diào)度。使用修改我們 Java 代碼的方式動態(tài)的選擇查詢新 Cube 還是舊 Cube，等到一定的時間周期之后再廢棄舊 Cube。目前這種方式的弊端在于查詢時間段包含新舊時，需要在程序中拼接數(shù)據(jù)，十分麻煩且會造成統(tǒng)計數(shù)據(jù)不準(zhǔn)。所以在設(shè)計之初就要多考慮一下后面的擴展，可以先預(yù)留幾個擴展字段。

?

效果對比

這里我們從多個角度對比一下幾個方案的優(yōu)缺點：

?

條件	Apache Kylin	ES?實時聚合	Hive?離線任務(wù)再入 ?MySQL
查詢速度	較快，一般在亞秒級別。從 HBase 中選擇適合的維度，Cude 設(shè)計的好的話不存在二次聚合，也不會有速度方面的問題	慢，可能有幾分鐘。實時聚合，在復(fù)雜的情況下有嚴(yán)重的性能問題，查詢的時間可能到幾分鐘。	快，一般在毫秒級。計算好的數(shù)據(jù)基于 ?MySQL 查詢，一般不會有性能問題。
時效性	近實時，一般在30分鐘以內(nèi)。延遲主要取決于任務(wù)調(diào)度的時間，但是一般都會在10~30分鐘左右。	實時，一般延遲在秒級。ES的延遲是取決于上游數(shù)據(jù)的寫入延遲和數(shù)據(jù)刷新的時間，一般可以控制在秒級。	離線，一般是T+1延遲。離線數(shù)據(jù)由于同步和計算的關(guān)系，一般都是+1小時延遲或者是+1天延遲。
開發(fā)難度	較簡單。實時數(shù)據(jù)需要先進行一系列的清洗和規(guī)整，后面只需要配置即可，不過 Cube 設(shè)計有一定的難度。	簡單。只需要寫入數(shù)據(jù)即可，配合已有的EST框架可以任意組合滿足業(yè)務(wù)需要。	工作量極大。針對每一種維度組合，都需要手動開發(fā)任務(wù)來進行計算和存儲。
資源消耗	一般。單獨搭建的集群，不會對其他業(yè)務(wù)造成影響，但是集群資源需求還是比較大。	一般。查詢和寫入一旦量大復(fù)雜后對集群上其他的查詢會帶來影響。	一般。在大集群上跑 ?YARN 任務(wù)，對集群整體影響不大。
可擴展性	不太好擴展。針對已經(jīng)建好的 ?DataSource、Model 和 Cube 的修改比較不友好，但是有解決的辦法。	可擴展性較強。所有的修改只需修改Index模板，下一周期生效即可。	基本無法擴展。每次有新的業(yè)務(wù)需求需要重新開發(fā)任務(wù)。
容錯性	較差。對數(shù)據(jù)的格式和類型要求較為嚴(yán)格，容易導(dǎo)致構(gòu)建失敗。	較差。字段不一致會帶來沖突，導(dǎo)致字段無法聚合，且沖突一旦在索引中生成，該索引將無法解決，只有等待下一周期或刪除索引。	較好。對字段類型和數(shù)據(jù)字段有一定的容錯性。
數(shù)據(jù)查詢復(fù)雜度	十分簡單。Kylin?會根據(jù)條件自動識別就是在哪一個 Cuboid 中查詢數(shù)據(jù)，只需要使用 SQL 即可，跨 Cuboid 的查詢也可以自動二次聚合，SQL 也可以直接配合 EST 框架。	較為容易。配合 EST 框架查詢十分容易，但是由于索引有小時和天后綴，需要在程序中進行判斷，才能有效降低查詢量。	十分困難。由于每個維度存儲組合存儲的表都不一樣，導(dǎo)致存儲結(jié)構(gòu)十分復(fù)雜，查詢的時候需要自己判斷在那張表里面，難度很大。

?

總結(jié)

基于以上的探索和使用，我們在使用 Kylin 之后，帶來最大的改變就是在查詢速度上的提升,給斗魚 APM 系統(tǒng)的用戶體驗上帶來了極大的改善：之前 ES 實時聚合需要將近 90 秒的查詢，改為 Kylin 只需 2~3 秒即可展示，原來需要加載幾分鐘的儀表盤，現(xiàn)在僅用幾秒就能全部加載完成，提高多達 30 倍。

?

在開發(fā)效率上，切換至 Kylin 在前期不熟悉的情況下的確走了一些彎路，踩了不少坑（跟數(shù)據(jù)質(zhì)量、對 Kylin 原理的掌握等都有關(guān)）。但是后面在熟悉之后便可以有不遜色于 ES 的開發(fā)效率，用起來非常不錯。

?

目前版本的 Kylin 也有一些不足，例如數(shù)據(jù)的時效性，因為 Kylin 2.x 的流數(shù)據(jù)源只能達到準(zhǔn)實時（Near Real-time），準(zhǔn)實時延遲通常在十幾到幾十分鐘的，對 APM 系統(tǒng)中的實時告警模塊還不能滿足業(yè)務(wù)要求。所以目前實時告警這一塊走的還是ES，由于告警只需要對上個短暫周期（1~5 分鐘）內(nèi)的數(shù)據(jù)做聚合，數(shù)據(jù)量較小，ES 對此沒有性能問題倒能承受。對于海量歷史數(shù)據(jù)，通過 Kylin 來查詢的效果更好。

?

新系統(tǒng)于 2018 年 11 月正式上線，目前已經(jīng)穩(wěn)定運行近一年。我們也注意到 Kylin 3.0 已經(jīng)在實時統(tǒng)計上開始發(fā)力，能夠做到 ES 這樣的秒級延遲，我們會持續(xù)關(guān)注，希望 Kylin 可以發(fā)展的越來越好。

?

作者簡介：戴天力，斗魚高級大數(shù)據(jù)開發(fā)工程師，斗魚 Kylin 團隊主要負(fù)責(zé)人。

?

總結(jié)

以上是生活随笔為你收集整理的从 ES 到 Kylin，斗鱼客户端性能分析平台进化之旅的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。