<dd id="pdtpp"></dd>
<progress id="pdtpp"><track id="pdtpp"><video id="pdtpp"></video></track></progress>

<button id="pdtpp"></button>
<rp id="pdtpp"></rp>
  • <rp id="pdtpp"></rp>
      數極客首頁

      Apache Kylin 在小米大數據中的應用

      本文來自 Apache Kylin Meetup 北京站上小米大數據平臺 OLAP 負責人陳學輝的分享。

      小米擁有眾多產品線,業務遍及全球 80 多個國家和地區,數據規模大,對查詢響應時間要求高。本次分享主要介紹了 Kylin 在小米內部的使用情況,包括適用的業務場景,遇到的挑戰,源自業務實踐中的功能優化點。

      小米業務場景

      小米的產品業務線包含硬件、互聯網、電商、金融、AI等等,絕大部分都有非常強烈的數據分析和統計需求。小米在不斷進行全球化的商業布局,在全球各地都有自己相關的硬件、互聯網等業務在開展。

      下圖為小米目前的主要業務數據分析場景。

      下圖為小米業務上對數據的需求。

      在性能層面,數據規模大,且對查詢響應時間要求高。

      在系統層面,小米的大部分場景,時效性要求不是特別高,一般來說天級或小時級的時效性,就能夠滿足業務大部分的需求。但對數據系統的穩定性要求非常高。高并發查詢目前來看,需求中等。

      在功能層面,對多表關聯這種場景,需求中等。Schema 靈活性在用戶分析的場景要求會比較高,在其他的場景要求適中。精確去重在絕大部分場景之中是強依賴的需求,所以我們非常注重這一塊的能力。

      在運維層面,我們比較關心數據系統的擴展性,以及多租戶性,保證資源隔離、各個業務不互相干擾。

      簡單給大家介紹小米內部的幾種主要的數據分析和統計系統。

      數據工場是小米內部的數據倉庫平臺,服務于小米絕大部分的業務。這套系統的局限和不足也有很多,比如說報表展現比較簡單。一個任務對應一個圖表,工作量會隨統計需求呈現出正相關的增長。

      第二,就是簡單實時的統計系統。在實時性要求比較高的場景里,我們用開源的方案,去比較快速地搭建這樣的系統,這樣的系統比較滿足我們實時性比較高的需求,維護的成本相對比較低,缺陷是對于大跨度的歷史數據查詢性能得不到滿足,且不支持多表 Join。

      第三,是傳統的 BI 系統。BI 比較重量級,需要比較大的維護成本。優點是豐富的可視化圖表,統計分析功能也會非常強大。它主要是偏人工定制,因而能夠滿足各種各樣的數據需求。不足點也很明顯,第一難以支撐海量數據多維的靈活分析,第二是整個系統的開發運維成本較高,因為大部分都是靠人工寫代碼,對計算邏輯正確性、系統穩定性等方面有較高要求。

      最后,是我們 2018 年啟動的增長分析系統,該系統基于“事件模型”為互聯網業務提供 App 內的用戶行為分析能力,使用 SparkSQL+Kudu 的技術方案實現實時多維分析,能夠同時提供統計聚合和明細粒度的查詢分析。這個系統的優點是能夠提供實時多維的數據查詢分析,實時動態增加字段,支持多種用戶行為分析的模型。不足之處,在數據規模比較大的情況下,查詢響應時間較長,另外整個系統的硬件成本比較高。

      我們正在研發的 Big BI 自助 BI 報表平臺,主要用到 Kylin+Doris 兩個開源 OLAP 系統的多維分析能力。

      BigBI 希望通過自動化的方式去實現業務數據從 0 到 1 的過程,從最開始的數據源接入到數據處理(包括數據清洗ETL和數據建模),再到數據展現,實現全環節可配置化,提升 BI 系統研發效率。技術架構圖如下:

      Kylin的使用情況

      接下來給大家分享 Kylin 在小米內部應用的基本情況、實踐案例、使用技巧和未來規劃等內容。

      小米內部大概有十幾個業務在使用 Kylin,平均每個月活躍的項目管理員有 20 多人,每個項目會有 1 到 2 個管理員(研發)來維護 Kylin 的 Cube 數據。目前 Kylin 總體數據量在 100 TB 級別,平均每天對 Kylin 的查詢次數是 30W 次以上,整體平均查詢響應時間是 0.8 s 左右,Cube 總數是 150 個左右。

      Kylin 有2個重度用戶,一個是 MIUI BI,MIUI BI 是覆蓋手機數據和互聯網 App 數據的公司級 BI 平臺。另外一個是人工智能產品小愛同學,小愛業務也會大量地用到Kylin做數據統計。另外,一般用戶有有品、Push、手機質量系統等。重度用戶大概每天查詢量都是在 10 萬級以上,一般用戶的日均查詢量在 1k 到 10k 之間。

      小米內部維護了一個自有的 Kylin 的分支,我們會定期同步社區的 Kylin 版本。目前線上環境使用的是 Kylin 2.5.2 版本,啟用了 Cube Planner 特性,方便分析 Cuboid 查詢命中情況,提高 Cube 優化剪枝效率。

      公司內部的 Kylin 集群包含 3 臺服務器,其中 1 臺 JobSever,2 臺 QueryServer,能夠滿足前面所提到的日常查詢量負載。Kylin的后端存儲使用了公司統一維護 HBase,為此,修改 Kylin 代碼適配了公司的 HBase v0.98。通過 Project 或者 Cube 級別配置獨立計算隊列,基本實現了計算資源隔離,確保業務之間的 Cube 構建過程互不影響。

      我們在 Kylin 上做了一些易用性的改進。業務使用方面,支持了基于日期時間的周期性調度,這樣可以讓我們的 Cube 每天定時地去跑,不用我們通過別的手段去觸發。另外,增加了 Cube 構建成功事件的回調,每天成功構建 Cube之后,產生回調通知,方便業務系統都將最新的數據用起來。

      為了支持多用戶,我們在 Kylin 界面上增加了用戶管理的頁面,便于為多個業務線創建用戶和管理權限。一個常見的場景,因為隊列資源緊張或其他原因,導致業務某一天的 Cube 構建失敗而產生空洞,一般需要人工觸發再次構建,針對這個業務使用痛點問題,我們開發了定期檢查和修復 segment 的空洞和重疊情況功能,當發現某一個業務線有不連續的 Cube 數據時候,自動觸發相關 segment 的構建任務。

      監控運維方面,支持了 Kylin 各種內部事件的短信通知,能夠幫助我們的研發工程師及時了解系統情況。我們打通了小米內部的 falcon 監控平臺,將 Kylin 的關鍵的指標,如查詢時間等信息推送到 falcon 上,建立 Kylin 的服務監控。我們還做了基于 ZK 的服務發現功能,避免繁瑣的手工配置,降低運維的成本。

      以上是我們在易用性方面的優化,我們還向社區提交了十余項改進和修復的 patch。

      其中第一項是 support max segment merge span,是我們從內部合并的角度去做一些優化,我們會去設置一個最大的 segment 的粒度,當 segment 到達最大的粒度之后,對應的中間文件不再繼續保留而被清理掉,可以節省 HDFS 的存儲空間。其他 patch 大家有興趣的話可以通過 Jira ID 查看具體的改動內容。

      接下來講一下我們內部實踐中的一些簡單實用技巧。

      編寫 SQL 查詢語句時,比如說用 date、sum 等關鍵詞,是需要用雙引號來括起來的。需要注意的是,SQL 語句查詢的表應該是 Hive 表名,而不是 Cube 和 Model 的名稱。Cube 和 Model 是 Kylin 邏輯上的抽象,查詢的對象實際還是 Hive 表而非 Cube/Model。

      設計 Cube 時,可以通過調整 Rowkey 順序來優化查詢性能。這一塊有幾個小點的分享:第一要將查詢中作為過濾條件的字段,放在其他維度前面,保證它優先被查詢到;第二是將經常出現的維度放在不經常查詢的維度的前面;第三是對于基數較高的維度,如果高基維度會出現在過濾條件中,則將它先前移,否則后移,因為高基維度通常會導致數據膨脹比較厲害。

      最后一點是?UV 統計場景的心得,大家知道,當 UV 量級達到上億級別時,COUNT DISTINCT 的計算成本和存儲成本比較高。我們的優化思路是,在數據預處理的時候,保證一個 ID 的數據只存一行數據,同時設置字段 UV 值為1表示該 ID 是活躍的,通過 SUM(UV) 替代 COUNT DISTINCT 來計算 UV,大幅節省了計算時間和存儲空間。

      另外,簡單分享一下我們之前在 MIUI BI 項目里使用 Kylin 時遇到的維度互斥問題。MIUI BI 的國家維度,包含了全部國家,海外國家,中國,印度,印尼,俄羅斯等不同層次的維度值。這種復合維度在 Kylin 構建 Cube 時,統計數據是有問題的,因為 Kylin 內在要求維度的不同取值之間不能有包含關系,否則統計值不準確。另外,在 MIUI BI 的場景里,層級維度并不能滿足業務的需求,因為 Kylin 的層級維度要求在查詢時低級別維度時,需要同時帶上低級別維度對應的高級別維度。我們的解決的方案是,構造維度互斥,將一個維度拆成兩個,保證 2 個維度之間能夠實現互斥的效果。這樣的話 Cube 計算的統計值就是正確的,這種拆分維度方案帶來的副作用會導致查詢語句變復雜。

      查詢性能和彈性運維方面探索更好的方案。另外一個重要的方向是,希望能夠把 Kylin、Doris、SparkSQL 等多種引擎結合起來實現智能路由,充分發揮每種引擎的長處,形成公司級的 OLAP 解決方案。目前公司許多產品線 OLAP 需求是通過多種技術方案和引擎來實現的,比較雜亂,希望未來能夠形成統一的 OLAP 解決方案,降低研發和維護成本。關于 Kylin 的底層的存儲引擎,我們正在測試?Kylin On Parquet 方案,希望通過這個方案能夠提升 Kylin 查詢性能。另外我們也會在彈性運維上去做嘗試,試圖把 Kylin 部署到 Kubernetes 上,把 Kubernetes 的一些特性用起來,提高運維效率。

      Q&A

      提問:每次構建 Cube 數據量的大小,每個 Cube 構建時間大概是多少?

      回答:我們大概是 500 G;絕大部分業務 1 天的數據大概一個小時內能構建完。

      提問:最后一頁你提到比較關注 Kylin on Parquet 的方案。能夠講一下你們希望通過 Kylin on Parquet 來獲得什么方面的收益?

      回答:我們發現 HBase 模糊匹配的效率不是特別好,希望通過 Parquet 列式存儲格式提升 scan 性能。

      回答:其實我可以請到我們這邊資深的同學來講一下,他做了大量的工作。劉紹輝是我們計算平臺的同學,也經常給 Kylin 社區提交 Patch。

      紹輝:測試 Parquet 主要是因為 HBase 有一些數據量的限制,數據量不匹配的時候,在 HBase 上會狂掃數據,但你拿到的數據其實很少,這樣的話對 HBase 的壓力也是很大。現在我們測試的情況是把流程跑通了,但是后面會有一些結合業務的測試,還在繼續做的過程中,后面是希望慢慢有一些業務實際使用起來,提高整個 Kylin 的性能。

      提問:你們現在 Kylin 的構建,是由基礎業務來做?還是交給了實際業務來做?

      回答:一般情況會由業務的研發人員設計和構建 Cube,業務同學更懂他們的數據和查詢需求,我們會在 Kylin 技術和剪枝優化方面給業務的研發同學提供幫助和支持。

      提問:

      回答:小米內部大部分場景是 10 個左右的維度就能夠滿足業務需求,我們的業務場景下的維度不會特別多。Kylin 本身有 64 個維度的限制。

      提問:Kylin On Parquet 處理的相關業務或者說數據格式有什么要求?還有一個問題就是 Kylin ON Parquet 和 Spark SQL 有什么區別?

      主持人:Kylin on Parquet 和 Spark SQL 現階段來說沒有太大的關系,我們只是把 Parquet 作為 Kylin 一個存儲的方式,把它轉型到了 Spark 的格式。在查詢的時候,我們會把 Kylin 生成的查詢計劃,轉變成在 Spark 里面去做對 Parquet 文件的處理,然后我們給到 Spark 的并不是一個簡單的內容,而是一個文件集的操作。未來這里可以再做一些打通,比如說能夠把 Kylin 的查詢直接的變成 SparkSQL,然后用 SparkSQL 去查 Parquet,這樣的話 SparkSQL 也有自己的查詢優化,這樣的話最終能夠達到一個比較好的性能。

      關注數極客訂閱號:分析客

      數極客是新一代用戶行為分析與數據智能平臺,支持用戶數據分析運營數據分析留存分析路徑分析漏斗分析用戶畫像SEM數據分析等16種分析模型的數據分析產品,支持網站統計網站分析APP統計APP分析等分析工具,以及會員營銷系統A/B測試工具等數據智能應用,支持SAAS和私有化部署,提升用戶留存和轉化率,實現數據驅動增長!

      發表評論

      評論已關閉。

      相關文章

      數極客(shujike.com) 是新一代的智能數據分析平臺,包括用戶行為分析、用戶行為錄屏、會員營銷系統、AB測試系統 四款核心產品。目前累計服務用戶量超過100,000+。本欄目接受投稿,請聯系微信號:shujikecsm(注明投稿)
      最近文章
    1. 僅須3步,讓你的SEM推廣費用降低 50%,ROI提升100%
    2. 2019中國軟件百強榜發布,數極客簽約多家TOP20企業
    3. 京東云Elite-數極客用戶行為分析平臺上線
    4. 阿里政采云簽約數極客,全面提升政企采購平臺的用戶體驗
    5. 深度分析 | 什么是用戶畫像,如何構建用戶畫像?
    6. 聊聊APP數據分析的那些思路
    7. 熱門文章

      熱門標簽

      女主播直播