Kylin 作爲汽車之家的核心 OLAP 引擎，服務於多個業務線與商業數據產品，應用於流量、線索、用戶行爲、推薦效果等方面的數據分析場景。目前已有 500+ 個 Kylin Cube，存儲約 300 T，整體 Segment 數約1.6 萬；單個 Cube 原始數據過萬億，單個 Cube 最多 31 個維度；12萬 HBase region，查詢響應時間 TP 95 穩定在 2 秒以內。
本文導讀
1. Kylin 在汽車之家的發展歷程及現狀:
Kylin 簡介、架構與原理
使用現狀
發展歷程
2. Kylin 在商業化數據產品中的應用與實踐：
業務場景
技術選型（Kylin vs Druid vs ES）
戰略級數據產品-車智雲
開發流程
Kylin 的常規優化經驗（Cuboid 剪枝、查詢性能、最大維度組合、超大字典問題、精確去重....）
其他實踐
KylinSide系統-集羣信息統計、集羣管理
3. 集羣升級和遷移的一些經驗分享：
背景與挑戰
整體方案
整體架構
4. 未來的規劃：
實時 OLAP
雲原生
01
Kylin 在汽車之家的發展歷程及現狀
1. Kylin 簡介
Apache Kylin 是一個可擴展的超快的大數據分析型數據倉庫，它有友好的 web 界面，有交互式查詢能力，性能非常好，還有標準的 SQL 接口，支持 JDBC 查詢。Kylin 的原理是基於預計算模型，是多維立方體的模式，在 Kylin 3.0 之後已經支持實時 OLAP 了，同時 Kylin 可以和現有的 BI 工具無縫結合。
2. Kylin 架構
這是 Kylin 官網的一張圖，簡單給大家說一下，左邊是數據源，可以是 Hive 表，是可以離線的數據，也可以是 Kafka 裏面的一些實時數據，還可以是普通關係型數據庫裏面的數據，中間這一塊其實是核心的內容，最上層其實就是對外暴露的一些 REST 接口，REST API，除了 WEB 界面，還有 JDBC/ODBC 這些查詢也都是訪問的 REST 接口。再往下就是一個查詢引擎，Kylin 其實是基於 Apache Calcite 來實現的 SQL 解析，包括生成執行計劃。再往下是路由層，經過 SQL 解析後我們可以知道查詢到的哪個表，用到了哪幾個維度，用到哪些度量，根據這些信息就可以路由到提前構建好的 Cube 上，理想情況會精確命中到某一個維度組合上，來實現高效的查詢。
元數據這一塊包括 Hive 表的元數據和 Kylin 的元數據，Kylin 的元數據會包括 Project、Model、Cube、Segment 多種元數據信息，大多都會在內存中維護緩存。最下層其實是一個構建引擎，主要也是分兩塊，一塊離線的，一塊實時的，最終都會生成 HBase 表，存儲在 HBase 裏面，Kylin 大概的架構就是這樣的。
3. Cube 預計算原理
Cube 本身的中文含義是立方體，其實右邊這個圖就是很形象的說明了 Cube 的含義，假如說我們有一張表，這個表裏面有 ABCD 四個維度，所有的維度組合就構建出了這麼一個立方體，就是 Cube，然後每一種維度組合在 Kylin 的概念裏面就是 Cuboid，也就是對應圖裏面的一個點，ABCD 其實是一個最基礎的維度組合,也就是 BaseCuboid，是我們可以預聚合的最細粒度，然後下面包括 ABC、ABA 等這些更粗粒度的維度組合，其實都可以基於 ABCD 的預計算結果再去構建出來。
我們舉一個簡單的例子，剛纔說的這個表裏面有 ABCD 四個維度，假設A字段有值度是 A1，B 字段有 B1 和 B2，C 字段和 D 字段分別對應 C1 和 D1，這個時候就引入一個基數的概念，就是維度 A 它其實只有一個值，就是 A1，我們說他的基數就爲 1，維度B因爲有 B1 和 B2 兩個值，所以他的基數是 2。左邊下面這兩個表格對應的是字典，Kylin 爲了加速查詢，節省存儲空間，它會對每個維度上的值去做編碼，編碼是從 0 開始，所以 A1 對應的編碼爲 0，維度 B 的值是 B1 和 B2，對應的編碼就是 0 和 1。
我們來看一下最終的數據存儲到 HBase 裏面是什麼樣的，RowKey 中用綠色標註出來的四位數字，其實代表了四個維度，比如說黃色這一行數據是 1000，它其實代表的是 A 這個 Cuboid，也就是說維度爲 A，這個組合裏面只有 A 的這種情況。RowKey 首先是由四位數字標記出對應的 Cuboid 是哪一個，再後面這個 0 其實是維度 A 對應的值，這個例子裏 A 只有一個值 A1（對應的字典編碼爲0），所以最終只在 HBase 裏對應一行數據。
最後說下 Value，我們這個例子舉的是 Count 的例子，這個表裏面 A1 對應三條數據，所以 1000 這個 Cuboid 對應的 Count Value 就是3。
再看一下下面對應 AB 的這個 Cuboid，AB 這個組合，前兩位都是 1，後兩位 CD 是不包含的，所以是 0。因爲 A 對應的只有 A1，B 對應 B1、B2，所以他們構建出來的值只有兩行記錄，也就是 00 和 01，對應的 Count 的值就是 2 和 1。以上就是 Kylin 預計算的基本原理，這裏的 RowKey 是一個示意，和最終的 RowKey 會有些差別。
4. Kylin 的使用現狀
Kylin 作爲汽車之家的核心 OLAP 引擎，服務於多個業務線，支持多個商業數據產品，比如後面我們介紹的戰略級商業數據產品-車智雲，就是主要基於 Kylin 來建設的。
Kylin 在汽車之家支持包括流量、線索、用戶行爲、推薦效果等方面的數據分析場景。我們有 500 多個 Cube ，存儲在 300 T 左右，整體 Segment 數在 1.6 萬；單個 Cube 原始數據過萬億，單個 Cube 最多 31 個維度；12 萬 HBase region，查詢響應時間 TP 95 穩定在 2 秒以內。
5. Kylin 在汽車之家的發展歷程
2016 年：我們開始調研 Kylin，當時是 1.5.4 的版本，最初只是組內使用，支持一些統計場景。
2017 年：車智雲項目發起，此時我們藉助這個商業數據產品的契機，深度地使用了 Kylin，同時也升級到 1.6，這個階段 Cube 的規模在 100 多個，我們主要支持車智雲項目的需求，並在Kylin的外圍加了一些額外的監控和自動拉起的服務。
2018 年：主要是幫助業務團隊去優化模型，以及提升整體的Kylin的穩定性，這個時候 Cube 已經在 200 多個了，已經支持多個業務線了，同時部署了 3 個集羣。因爲支持了商業數據產品，對穩定性及可用性要求很高，所以增加了HBase災備的能力。
2019 年：我們升級到 2.6.3 這個版本，主要做了些集羣升級和機房遷移的工作。升級之後，很多 Cube 切換到 Spark 構建引擎上。同時之家內部有了自己的 BI 產品——AutoBI，也在逐步和 Kylin 做對接，使 Kylin 的應用場景更加豐富。
02
Kylin 在商業化數據產品中的應用與實踐
1. 業務及場景特點
汽車之家最就是以內容爲主的，汽車之家的內容通常是全網是最早發佈的，現在還融入了大量的自媒體以及小視頻等板塊。流量這一塊是大家最關注的，主要是提升運營這一塊，還有大量的用戶行爲數據和銷售線索數據，大體上是這幾類數據。
數據規模是千億級，穩定性是我們很看重的一點，響應時間是秒級或者是亞秒級，數據主要以離線爲主，還需要支持高併發。
2. 對比及選型
當時選型時，我們對比了 Kylin、Druid 還有 ES（Elasticsearch）。
性能：因爲 Kylin 和 Druid 都是基於預計算的，所以他們性能會比較好。
支持數據量級：因爲 Kylin 和 Druid 都是預計算，所以數據量級這一塊是沒有多大影響的，就算數據量級到萬億級也不需要去線性的擴展服務器，這一點是比較大的優勢，ES 就是需要做線性擴展的。
穩定性：這幾個都是比較成熟的開源產品，穩定性都是沒有問題的。
高併發：高併發其實是相對來說的，在 OLAP 場景裏面應該還沒有真正意義上的高併發，Kylin 是基於預計算的，相對來說併發支持比較好。
SQL：因爲 Kylin 原生就是支持 SQL 的，Druid 和 ES 早期都是不支持的。
易用性：Kylin 是有明顯優勢的，Kylin 有很友好的 Web 界面的，用戶可以在界面上去做建模和運維，同時權限這一塊原生就支持了。
明細查詢：Kylin 是不支持的，是比較弱的一塊。
經過試用和對比，我們最終選擇了 Kylin，能滿足我們大部分的場景。
3. 戰略級數據產品-車智雲
車智雲的定位主要是推動車企的戰略、營銷、研發等全價值鏈的升級。汽車之家有海量的用戶行爲數據和態度數據，我們最開始是論壇起家的，這上面有用戶針對每一個車型正面或者是負面的真實評價。數據規模佔線上汽車媒體 73%，這是一個很大的優勢，還融入了媒體、金融、電商、生活多維度的數據。我們首創了一個 UVN 的用戶分羣模型，並且以“用戶營銷漏斗”爲核心打造大數據產品。
作爲實時、智能的營銷數據平臺，車智雲提供一體化營銷閉環解決方案，爲車企研發、營銷、服務賦能，主要是從研發和營銷這兩個角度，未來還會在渠道方面，助力車企全面提升。
4. 面臨的挑戰
我們面臨的挑戰，首先是海量的數據。其次我們對查詢性能是有很高要求的，因爲我們最終要做商業化的數據產品。穩定性這一塊也是比較重要的，也是商業化的基本要求。
5. 一個備選方案
其實最開始和開發人員對接的時候，瞭解到他們也有一個備選的方案，最簡單的方案完全基於自研的：基於 Hive 表裏面的明細數據，也是提前預計算好各種所需要的指標，然後把他們存到 HBase 存儲裏面，然後通過這個 MR 去把這些結果寫到一個 HBase 存儲引擎裏面，在 Web 層去自己寫接口，去查詢這個結果數據。
這個方案其實有很多問題，首先是說開發成本是很高的，因爲如果是完全自研的話沒有界面操作，人肉去維護大量運行腳步，還需要編寫代碼，對代碼質量要求很高，還有自行開發排重指標，還有維度組合過多，這是難以維護的，還有 HBase 表後續也會很多，這個時候 Kylin 已經挺有名氣的了，很多公司已經在用了，經過一番對比最終我們選擇 Kylin 作爲核心 OLAP 分析引擎。
6. 基於 Kylin 開發，大大降低開發及運維成本
Kylin 開發流程的第一步就是在界面上去同步 Hive 表的元數據，然後基於這個元數據去創建模型，然後再進一步建 Cube 並構建，然後就可以用 JDBC 查詢數據了。
關於調度，我們寫了一個 Kylin 的調度的腳本，然後把調度腳本上傳到我們內部的調度系統上，並配置上游依賴就可以了。
使用 Kylin 開發的優勢其實很明顯，Kylin 直接基於 Hive 做建模，並且有完善易用的界面，我們不再需要寫代碼，普通數據開發人員就可以做數據的建模、構建及維護。同時構建過程可以是資源隔離的，可以用他們自己的隊列去做構建，不必擔心構建資源被其他業務搶佔。Kylin 完美支持 SQL 和 JDBC，對後端開發人員非常友好。Kylin 提供了豐富的配置，可以通過修改配置，提升構建及查詢性能。Kylin 還在 Cube 級別支持針對構建狀態設置報警，可以第一時間發現構建失敗的作業，並通知給 Cube 的負責人。Kylin 還會默認做慢查詢統計，開發人員可以針對這些明顯低效的查詢進行優化。
7. Kylin 的常規優化
再說一下 Kylin 的一些常規優化手段，其實這種多維立方體的模式下，對 Cuboid 的剪枝是非常重要的，最理想的情況就是需要查詢什麼，我們就提前預計算什麼，不查就不算，這從存儲和查詢的角度都是最優的，所以 Kylin 在 Cuboid 剪枝這一塊提供了豐富的優化手段。
首先是常規維度和衍生維度，因爲 Kylin 本身是支持星型模型的，維表裏面的維度都是衍生維度，其實這些維度是不參與 Cuboid 生成的，所以合理使用衍生維度是一個很好的優化手段。還有就是設置聚合組，這也是爲了精細化的去定義哪些維度組合是有必要的，哪些是沒必要的；還可以聲明必要維度、層級維度、聯合維度來確保在減少 Cuboid 個數的同時，儘量不影響查詢性能。
然後是查詢性能的優化，Kylin 原生提供了對字典的支持，通過對原始數據做編碼，不僅可以解決存儲空間，還可以用來過濾 segment 提升查詢性能；但是前面的例子裏面也提到了如果維度基數很高的話，字典也會很大，所以需要儘量避免高基維使用字典。最後是 RowKey 的順序，HBase 本身的特性決定了 RowKey 順序的重要性，通常是需要把常用的高頻的維度要放在前面的。Kylin 的優化手段網上有很多資料，這裏就不做過多的介紹了。
優化 1：最大維度組合
接下來說一下我們做的一些優化，第一個就是維度的最大組合數控制。當我們開始宣稱 Kylin 這個技術很牛，針對上千億的數據，可以秒級返回查詢結果時，一些運營人員就找過來了。他們說這個東西這麼牛，給我們分析流量用吧，我們這個表裏有幾十個維度，想要用 Kylin 加速查詢。用他們的話描述就是“需求很簡單”，只要支持任意維度做交叉 GROUP BY 統計就行。乍一聽幾十個維度，感覺這需求很難實現，但是稍微思考一下，他們每次查詢會用到幾個維度呢？通過了解下來，通常來說每次查詢最多也就用到三四個維度。拿我們的一個 17 個維度的 Cube 舉例，假設單次查詢最多就用到三個維度，我們不做任何優化的話，其實這個 Cuboid 維度組合的數量，其實是 2 的 17 次方，也就是 13 萬，這其實是一個很大的數字，Kylin 現在默認支持的最大 Cuboid 數是 32768（可以通過配置調整），也就是 2 的 15 次方，超過這個數就不允許構建了，需要藉助前面提到的剪枝手段做優化纔行。
這個場景下面我優化的思路就是我們設置一個最大可以同時查詢的維度的個數，然後結合必選維度，生成多個聚合組，來減少 Cuboid 的數量。這是最多構建三個維度的時候，Cuboid 的個數其實就是 C（17，3），即Cuboid數目爲4080個，通常會有一個時間維度是必選字段，其實就只有C（16，3），即Cuboid數目爲 3360，這個優化效果是很明顯的。新版 Kylin 中已經完美的支持了這一特性，可直接在cube中設置“Max Dimension Combination” 。
注：函數C(維度數量，MDX)的結果含義爲通過MDX來剪枝得到的最終cuboid數量。
優化 2：優化 Segment 過濾，解決超大字典問題
我們早期沒有限制高基數維度對字典的使用，而且業務開發是由另外一個業務團隊負責的，他們也沒有關注高基維這一塊，造成高基數維度使用普通字典，沒有使用全局字典，並且上線了，導致查詢server偶爾會佔滿堆內存，影響查詢性能。
後來我們瞭解到他們其實是按月去構建的，每個月對應一個Segment，並且業務上不會跨Segment查詢，每次只查詢一個月的數據。Kylin的每個Segment都會對應一份獨立的字典，而每次查詢時都會掃描多個Segment，也就是會加載多個字典，這會導致內存佔用彪高。
這個問題我們的緊急優化了一版代碼，思路就是隻查詢有效的Segment，避免查詢無效的Segment，自然就避免加載無效的字典了。我們怎麼過濾呢，就是根據用戶指定的時間範圍，比如SQL中指定的是19年1月的數據，那麼我們只需要查一個Segment就可以了，我們不需要加載無效的字典到內存裏面，所以我們定義了一個參數叫cube.time.dimensions，同時引入了一個選擇器去過濾Segment，具體的實現其實就是拿到TupleFilter對象，根據其中的時間條件，以及每個Segment的DateRange去判斷這個Segment是否符合條件，如果不符合條件我們就直接不查了。
優化 3：非精確去重、精確去重
第三個優化是說我們有一個比較特殊的場景，可能大家都沒有碰到過。我們之前有一個模塊最開始是非精確去重的，運行良好，查詢也比較穩定，但是上線一年後，產品突然說要改用精確去重，同時歷史數據不能重刷，也就是歷史數據保持非精確去重，新數據是需要做精確去重，還有一個前提，這個Cube也是不會跨Segment去聚合的。
其實最簡單的思路，就是創建一個全新的Cube，設置使用精確去重，用來構建新數據，再通過創建Hybrid把新Cube和舊Cube “綁定”在一起，同時支持新老數據的查詢。但是這裏遇到一個問題，就是Hybrid不支持同一個字段在兩個Cube中度量不同這種情況。
我們做了一點改造，就是根據SQL裏面的時間條件去動態選擇使用新Cube還是舊Cube，並且設置正確的Measure類型，也就是HyperLogLog或Bitmap。這裏也用到前面提到的DateRangeMatcher工具類，根據SQL中的時間條件和Cube對應的時間區間，來選擇正確的Cube並設置正確的度量類型。
優化 4：調度性能優化
再說調度性能方面的優化，背景其實是我們機房遷移過程當中有一段時間是需要跨機房去訪問HBase集羣的，我們發現跨機房訪問HBase的時候，每次調度構建任時候很慢，調度一次要十幾分鍾。
通過定位我們發現是因爲每次調度的時候會查詢job的信息，也就是頻繁的訪問HBase，當時跨機房的網絡延遲在5毫秒以上，已經超過HBase本身的查詢時間了，所以會導致調度性能很慢。這一塊優化比較簡單，就是在調度的過程中，跳過所有的成功狀態的job，而成功狀態的作業佔到了99%以上，所以做過這個改動後，調度性能就沒有問題了。
優化 5：設置 Cube 爲不可查詢狀態
這個是優化是我們把Cube設置成臨時不可查詢的狀態。背景是當業務需求發生變化時，比如增加維度，通常需要創建新的Cube並且構建數據，比如說需要構建兩年的數據，但是我們無法一次構建出兩年的數據，肯定是一個月一個月的去構建，當第一個月的數據構建成功時，Kylin就會默認把這個Cube的狀態調整爲Ready狀態，此時用戶查詢就可能會路由到這個數據還不完整的新Cube上，會導致這個結果不符合預期。
應對這種情況，我們增加了一個Cube級別的配置，標記這個Cube不參與查詢，當數據沒有刷完的時候把這個配置設置成false，Cube就不參與路由了，當數據全部構建成功後，再設置爲true，同時把舊的Cube disable掉就可以了。
優化 6：監控及自動拉起
我們監控主要是基於Kylin原生的Metric，Kylin提供了豐富的Metric，結合之家雲監控平臺提供的prometheus和grafana可以配置相對全面的監控圖表。
在前期沒有加健康檢測的時候，服務有的時候還是會不穩定的，比如說之前提到的問題，可能會導致查詢很慢，所以我們自己開發了監控程序，部署在每個Kylin節點上，用於監控Kylin服務的健康狀況，並視情況進行重啓。
首先就是我們會檢查Kylin的進程是否存在，如果是存活狀態，再去調一個REST API，判斷響應時間是否符合預期，同時還會監控堆內存的佔用，如果有一個指標連續幾次不符合預期，就會上報metric並報警，同時重啓Kylin。比如我們線上堆內存連續3次檢測都超過95%，那麼就會自動重起Kylin。另一方面，重啓本身也會帶來風險，所以需要合理設置每個閾值，避免誤報，影響服務；同時需要指定合適的最小重啓間隔，避免無限重啓；同時監控程序本身也要負責監控自身的工作線程是否正常運行；最後監控程序本身會監聽一個端口，方便其他的服務區監控自己。
這個是我們監控程序的一個示例，最上面通過pidCmd、startCmd、KillCmd用來聲明檢測進程存活狀態的命令以及重啓的命令，接下來是Kylin實例的一些基本信息，還有JMXExport端口的配置，最下面就是檢測週期和報警的相關配置。
優化 7：HBase 主從集羣
然後還有一個比較重要的點，就是HBase主從集羣，因爲我們是提供商業化的數據產品，所以我們需要保障SLA。所以我們把這個集羣做了一個T+1的備份，我們爲什麼不用原生的儲存備份？我們用的是HBase1.2.4版本，這個版本的主從複製是不支持Kylin使用的Bulkload方式的，所以我們自己開發了一套程序去做備份。
首先就是對比HBase對應的HDFS上的文件，增量的去拷貝這些文件，也就是用distcp去做文件同步，然後第二步就是讓HBase去識別這些表，最後我們要把從集羣上多餘的表給定期Drop掉。因爲我們主要的數據都是T+1的數據，都是離線的數據，每天都是在早上9點之前去把前一天的數據都構建好，所以我們每天十點的時候會調起的備份程序，把數據備份到HBase從集羣上，儘量讓從集羣的數據和主集羣保持一致。
這個從集羣還有一個好處，就是我們可以把這個服務開放給分析師用，因爲這個集羣上的數據很重要，也比較全面，分析師會用這份數據產出一些行業報告，同時也會做一些探索性的查詢。由於這部分都是手寫的SQL查詢，包含很多不確定性，如果這些操作直接在主集羣上去做的話，有可能會把HBase給搞壞了，整個Kylin服務都會掛掉。有了這個從集羣之後，順便也把分析師的需求也支持了，讓他們去查這個從集羣，不用擔心對線上的服務造成影響。
8. 其他實踐
再說一下其他的一些實踐，最基礎的就是定期去備份Kylin的元數據，定期調用Kylin的清理腳本，刪除無用的數據。同時定期清理Kylin生成的一些臨時文件，不然他有的時候可能會報inode數超出限制的異常。我們還加了一個SQL黑名單的功能，就是前期的時候有些查詢會導致HBase的region server批量掛掉，這個時候負責HBase的同學會定位到是因爲哪個Query ID導致的，我們會找到對應的SQL，然後把這個SQL加入到黑名單裏面去，臨時把這個異常查詢排掉。同時我們也加了一個功能，就是強制去要求用戶必須制定Where條件，這也是爲的保證穩定性的。然後我們去完善了一下原來的REST API，比如支持查詢更長時間的job。還有完善了慢查詢的告警，以及使用Filebeat將Kylin日誌統一收集到Elasticsearch中，便於查詢及分析。
9. KylinSide - 集羣信息統計、集羣管理
我們內部還有一個系統，我們叫做 KylinSide，他主要是生成一些統計信息，便於我們對集羣做管理和維護，還有一些遷移和升級過程中用到的工具，也是 KylinSide 提供的。這個截圖是 KylinSide 生成的一些集羣統計數據，通過之家的 AutoBI 系統配置的 Dashboard。新版本的 Kylin已經自帶了強大的 Dashboard 功能，目前我們兩者都在使用。
03
集羣升級的一些經驗分享
1. 背景及挑戰
集羣升級的背景主要是說我們當時用到1.6的版本，其實是比較早期的一個版本了，功能也相對比較少，比如說Spark構建不支持，job server不支持高可用，我們很早就想升級了。因爲是支持商業數據產品，服務不能長時間去中斷服務，並且升級之後數據必須和原來保持一致，同時我們要規避升級過程帶來的風險。
2. 整體方案
從1.6到2.6的版本，我們覺得升級跨度比較大，可能會有未知的風險，所以我們當時的方案是基於新版本的Kylin去搭建新的集羣，然後並行運行，穩定運行後，直接切換域名解析。
整個過程分這幾步，首先肯定是要把元數據同步到新集羣，然後我們要把歷史的這些Segment都構建起來，並且增量的構建要同步到新集羣上進行自動構建，最後要對比新老集羣的Segment數據量和大小以及連續情況。同時我們需要去收集老集羣的一些SQL，然後把他們回放到新集羣上，對比新老集羣的SQL查詢的結果並且生成對比報告。
3. 整體架構
這個是我們升級的一個整體架構，其實中間是基於KylinSide的工具，自動去構建和回放的一些功能。首先我們是對元數據的備份，相當於我們是直接對取HBase的元數據表，去把他同步到另一個HBase裏面，其次是歷史數據構建及增量構建，這也是一個自動的過程，還有就是我們收集老集羣的SQL，寫到kafka裏面，然後存到MySql裏面，然後KylinSide定期去回放這些SQL到新的集羣裏面去執行，最終會生成SQL結果的對比報告。
04
未來規劃
1. 實時 OLAP
其實我們組是一個實時計算的小組，除了負責Kylin，我們還負責實時接入分發平臺，消息中間件，實時計算平臺這幾塊內容。我們目前遇到很多實時需求都是可以看成是實時OLAP需求，大部分場景都是讓用戶在我們平臺上去寫Flink SQL作業，將結果存儲到Redis Sink或MySql Sink中。用Flink SQL開發，雖然一定程度上減輕他們的開發壓力了，但還是沒有Kylin的多維建模來的自然，同時Kylin本身支持lambda模式，可以很自然的實現實時和離線計算的口徑統一。
目前我們也在調研了 Kylin 的實時OLAP的能力，我們內部也有幾個場景在試用，雖然目前還沒有正式上生產，但我們相信Flink SQL 的實時ETL加上Kylin的實時多維建模是一個不錯的選擇。
2. 雲原生
我們很期待4.0雲原生時代的Kylin，尤其是實時OLAP這一塊，實時OLAP目前的運行方式，Streaming Receiver的維護成本還是有點高的，相信4.0時代，可以支持在Cube級別動態部署Streaming Receivers，讓實時模塊更加易用。
作者：邸星星，汽車之家實時計算平臺負責人，長期從事實時計算與 OLAP 領域的平臺建設工作，致力於爲公司提供大規模、高效、穩定的計算與查詢服務。
往期推薦
▬
Uber基於Apache Hudi構建PB級數據湖實踐
數據湖 | 一文讀懂Data Lake的概念、特徵、架構與案例
認識 Delta Lake：讓數倉進化到數據湖
乾貨 | Kafka 內核知識梳理，附思維導圖
