快手 App 目前日活 1.5 億，每天會產生數萬億規模的使用者行為資料，對這些資料的高效探索是一件很有挑戰同時也很有價值的工作，這樣才能更快的接近抖音。今天重點分享快手建設萬億級資料規模 OLAP 平臺的設計方案以及主要改進過程。
快手 OLAP 平臺概覽快手的 OLAP 平臺誕生的時間不長，在 2018 年 4 月份之前，一些多維分析的需求還是採用預定義指標加上離線計算的方案，其缺點很明顯，首先指標預定義是非常固定的，另外因為採用離線計算，實用性也很差。
在今年 4 月份上線 Druid OLAP 分析引擎，加上 Superset 資料視覺化平臺，解決了不少業務的痛點。5 月，Druid 平臺升級到了當時社群最新的 0.12 的版本，在升級過程中解決了時區、檔案載入效能等問題。7 月，Druid 平臺每天的錄入訊息數已經突破 1000 億，使用者配置的視覺化圖表也超過 1000 個。7 月份之後平臺進入了一個快速發展的階段，Druid 在查詢效能和穩定性方面都出現了很多的問題，我們做了非常多的改進。9 月，上線了 Druid 探針系統、時序和維度物化檢視功能、Indexing Service 細顆粒資源分配等，另外在資源排程層面也做了大量優化工作。截至今年 11 月，OLAP 平臺每天攝入訊息的資料量峰值已經超過 5000 億，使用者配置的視覺化圖表數已經突破 1 萬。
半年來 OLAP 平臺發展速度非常快，得益於基於 Druid 的高可用架構設計，以及團隊夥伴的努力，整個 OLAP 平臺上線至今未出現中型或大型的故障，服務很穩定。
快手 OLAP 平臺共有 150 臺物理伺服器，接入的資料來源超過 2000 個，每天錄入的訊息數量在 5000 億左右，索引的資料存量約 400TB。每天查詢次數峰值 1000 萬，這個量是非常大的，但是有很多在程式裡觸發 API 的呼叫，人為觸發的比例較小。整體上平均查詢時延為 50 毫秒，P90 為 100 毫秒左右，P99 為 500 毫秒到 1 秒。視覺化方面，積累的使用者看板數有八百多個，圖表數超過 1 萬。
快手使用 OLAP 的業務場景首先是多媒體品質分析業務。快手使用了全國多家 CDN 廠商服務，涉及的域名有幾百個，每天上報的 CDN 品質監控資料上百億。CDN 服務品質會直接關係到主站 APP 使用者使用體驗，公司 CDN 品質團隊需要實時對 CDN 監控資料做分析和智慧排程，以及對排程效果進行實時的監測。另外，對於 CDN 品質問題需要做出快速分析和定位，這本身也是一個多維分析的過程，OLAP 技術能夠很好地滿足這個需求。
另外一個業務場景是 A/B Test，快手已經上線了約 1000 個 A/B 的實驗，需要對比的 A/B 指標多達數千個，每天有數百億的資料要流入 A/B Test 平臺。對 A/B Test 指標的分析，也是一個很典型的多維分析的過程，OLAP 平臺要滿足每天幾十萬次的查詢呼叫需求，查詢的時延要保證在百毫秒級。
OLAP 平臺選型時對公司多個業務團隊的需求做了調研，總結來講，大家對以下幾個點關注度會比較高。比如超大資料規模的支援，單個數據源可能每天有上百億的資料量需要錄入；查詢時延，要保證在毫秒到秒級；資料實時性，很多業務線明確提出實時資料分析的需求；另外還有高併發查詢、平臺穩定性等，除此之外還有一些相對權重比較低的需求：如資料 Schema 的靈活變更、精確去重的功能，以及 SQU 介面的支援等。
根據對使用者調研的總結，我們對比了現在比較常用的 OLAP 技術。
首先，Hive/SparkSQL 在資料倉庫的領域應用是比較廣泛的，但是因為查詢時延很難能夠滿足毫秒到秒級的要求，同時因為是離線計算，資料時效性也比較差。其次，ES 是一個功能很強大的系統，在中等資料規模場景下能較好地滿足需求，但是在萬億和更大的資料規模場景下，資料的寫入效能和查詢效能都遇到了很大的瓶頸。Kylin 和 Druid 功能比較類似，考慮到 Druid 採用 OLAP 架構，資料時效性相對於 Kylin 來講會更好，資料的變更也相對更加靈活，所以最終選用 Druid 作為 OLAP 平臺的查詢引擎。Druid 系統概述上圖是 Druid 系統架構圖，其中 Coordinator 和 Overlord 是 Druid 的主節點；Middle Manager 主要是負責資料索引，生成索引檔案，Historical 節點主要負責載入索引檔案，同時提供歷史資料的查詢服務；Broker 是查詢的接入節點；除此，Druid 還需要對元資料進行儲存，比如選用 MySQL；Middle Manager 在產生索引檔案的時候，需要把索引檔案先發布到一個共享的儲存系統裡，我們選擇了大家普遍採用的 HDFS 系統。
上面提到 Druid 的查詢效能非常好，總結來說主要是因為採用了如下五個技術點：資料的預聚合、列式儲存、Bitmap 索引、mmap、以及查詢結果的中間快取。下面針對兩個點具體展開講一下。
首先講下資料預聚合。Druid 會把一行資料訊息分成三個部分，包括時間戳列、維度列以及指標列。所謂預聚合，就是當資料錄入到 Druid 系統時，會按照一定的時間週期把原始資料做一次預先聚合，會根據一個全維度聚合出要計算的指標，也就是要索引的內容。後續所有的查詢都是通過這些預聚合的中間結果做二次查詢。
接下來講下 Bitmap 索引。Bitmap 索引主要為了加速查詢時有條件過濾的場景。Druid 在生成索引檔案的時候，對每個列的每個取值生成對應的 Bitmap 集合。如圖上所示，Gender 為 Male 對應的 Bitmap 為“1001”，代表第 1 行和第 4 行的 Gender 為“Male”。舉一個查詢的例子，假設要篩選 Gender =‘Female’and City =‘Taiyuan’的資料，那麼只需要把 Gender =‘Female’對應的 Bitmap “0110”和 Taiyuan 對應的 Bitmap “0101”進行與操作，得到結果為“0100”，代表第二行滿足篩選條件。通過 Bitmap 可以快速定位要讀取的資料，加速查詢速度。
關於 Druid 模組，Druid 支援從 kafka 實時匯入資料，同時也支援批量從 HDFS 或者 HIVE 系統進行離線匯入；Druid 提供了豐富的查詢 API 介面。除了預設提供的 Restful 介面之外，Python 、Java、Go 等程式語言都有第三方的實現 API 介面。此外，Druid 也提供了 SQL 介面的支援。值得一提的是，Hive 在 2.2 版本之後通過 StorageHandler 實現了對 Druid 的支援，這樣可以通過 Hive SQL 查詢 Druid 裡的資料，快手內部也在用，但是需要做一些修改工作，比如解決時區問題、Druid 資料來源維度和指標的大小寫敏感問題，以及實現預設的 limit、預設時間範圍選擇等功能。
Druid 在快手使用的經驗以及一些主要改進點這是快手 OLAP 的平臺架構圖，中間部分是 Druid 自有的元件，資料通過 kafka 實時攝入和離線從 Hive 數倉中批量匯入。除此之外，我們還配套了完善的 Metric 系統，探針系統、Druid 資料來源管理系統等。
在萬億甚至幾十萬億資料規模場景下，OLAP 平臺使用過程中也面臨了很多挑戰。比如如何讓查詢變得更快，資源的利用率如何更高效，在資料的管理到資料的接入如何更方便，叢集平臺如何更穩定，針對這些問題我們都針對性的做了改進和優化。
首先，穩定性方面我們做了多種的資源隔離部署的方案，在接入層通過代理實現 Broker 的高可用和負載均衡。
在 Historical 資料儲存層，做了兩個層面的資料劃分。一是資料的冷熱分離，熱資料儲存在 SSD 的機器上，當熱資料變成冷資料之後會自動地遷移到 HDD 機器上。因為大部分查詢都是查詢最近的資料，所以才用 SSD 的加速效果是非常明顯的。考慮到 SSD 的成本比較高，可以在設定熱資料的副本的時候，把其中一個副本放在 SSD 上，另外一個副本放到 HDD 的機器上，然後設定 SSD 副本的權重，大部分的請求還是能夠落在 SSD 機器上。當 SSD 機器出現故障之後，請求才會發送 HDD 上，這樣能節約不少成本。
除了冷熱資料分離的考慮外，因為有些對查詢穩定性要求更高，快手通過 Tier 配置也對特殊業務也做了隔離，特殊的業務資料來源索引資料儲存在專用的 Historical 機器上。這樣在一些大查詢可能會導致 historical 記憶體 GC 或者是系統 IO 支援 Load 較高的場景下，其查詢效能仍然不受影響。
在大規模資料場景下查詢效能的加速，我們也做了很多優化。首先是物化檢視，會做兩個層面的物化檢視，一個是維度層面的物化，一個是時序層面的物化。
什麼是物化檢視，假設一個數據源的原始維度有十個列，通過分析查詢請求發現，group1 中的三個維度和 group2 中的三個維度分別經常同時出現，剩餘的四個維度可能查詢頻率很低。更加嚴重的是，沒有被查詢的維度列裡面有一個是高基維，就是 count district 值很大的維度，比如說像 User id 這種。這種情況下會存在很大的查詢效能問題，因為高基維度會影響 Druid 的資料預聚合效果，聚合效果差就會導致索引檔案 Size 變大，進而導致查詢時的讀 IO 變大，整體查詢效能變差。針對這種 case 的優化，我們會將 group1 和 group2 這種維度分別建一個預聚合索引，然後當收到新的查詢請求，系統會先分析請求裡要查詢維度集合，如果要查詢的維度集合是剛才新建的專用的索引維度集合的一個子集，則直接訪問剛才新建的索引就可以，不需要去訪問原始的聚合索引，查詢的效能會有一個比較明顯的改善，這就是物化檢視的一個設計思路，也是一個典型的用空間換時間的方案。
時序物化檢視：除了剛才提到的查詢場景外，還有一種查詢 Case，Druid 也不能很好滿足。比如大跨度時間範圍的查詢，假設一個數據源的聚合力度是分鐘級別，但需要查詢最近三個月的資料就比較麻煩，因為需要把過去三個月的所有分鐘級別的索引檔案全部掃描一遍，然後再做一次聚合的計算。
為了解決這個問題，我們在資料來源分鐘級別的索引上再新建一個小時級別甚至級別的物化索引，這種情況下聚合效果就會更好，索引整體的 size 也會比較小。當收到一個新的查詢請求時，如果查詢要統計的粒度是天級別或者是更高級別的查詢粒度，會把查詢請求自動路由到天級別物化索引上，這樣查詢效能也會有一個比較明顯的改善。
下面討論下 Druid 元資料儲存系統的效能優化，平臺上線以來我們積累了大約幾百萬的 Segment 檔案，對這些數百萬 Segment 元資訊的查詢，或者說 MySQL Segments 表的查詢也遇到的效能瓶頸。
首先是 Overlord 與 MySQL 之間的互動優化。Overlord 在釋出新的 Segment 檔案的時候會多次查詢 Segments 表，監控發現會有大量的慢查詢。解決方案很簡單，針對性地對 Segments 表增加索引即可。對比優化後的 MySQL 查詢效能，可以從 10 秒多降到 1 秒，有 10 倍以上的提升。
另外是 Coordinator 與 MySQL 之間的互動效能優化。Coordinator 會週期性的去全量掃描 Segments 表，每次掃描都會花費較長的時間。首先全量掃描完全是沒必要的，我們改造成增量掃描的方案，整個掃描的耗時從原來的 1.7 分鐘降到 40 秒左右。然後更進一步對增量掃描的 SQL 專門建立了 MySQL 索引，掃描耗時可以降到 30 毫秒，整體算下來有上千的效能提升。
接下來是 Segment 檔案載入過程的優化，Coordinator 掃描 segment 匹配 Rule 過程預設是序列實現的，我們對此做了並行化的加速，再加上一些細節點的改進。叢集幾百萬量級的 Segment 檔案協調一遍的耗時從原來的 3 分鐘降低到現在的 30 秒。Druid 元資料系統通過如上幾個點的優化後，目前基本上不再有效能瓶頸。
快手對 Druid 叢集資源利用率的改進首先，每個 Kafka indexing task 會對應一個 Supervisor 的服務，Supervisor 的 task count 是一個固定的值，當用戶設定 task count 比較小時，可能會因為讀取 Kafka 的 lag 過大而出現數據延遲，而如果設定的過大會造成資源的浪費。另外，使用者在建立一個 indexing task 的時候，也很難估算 task count 應該是多少合適。我們的優化方案是讓 Supervisor 根據當前消費 Kafka 時延的情況，自動調節 task count，這樣業務高峰期不至於出現數據延時，資料低峰期時也能把資源還給叢集，整個叢集的利用率有明顯提升。
另外是 Middle Manager 的 indexing task 資源分配問題。Druid 為每個 Middler Manager 分配一個固定的 Slot 數，但是因為相對 Kafka indexing task 來講 Hadoop indexing task 其實只是一個 Hadoop 客戶端僅負責提交一個任務，本身並不怎麼佔資源，這樣的話會有一些資源的浪費的問題。針對這個問題的優化思路是，把 Middler Manager 的 task 排程配置從按照 Slot 數改成按照記憶體大小分配，我們會區別對待不同型別的 task，對於 Kafka 的 task 和 Hadoop 的 task 會預設不同的記憶體大小，當然使用者在提交 task 的時候，可以指定自己的 task 記憶體大小，我們會做一些最大值的限制，防止惡意的提交。
此外，對 Segment 檔案及時的做 Compaction 會有益於查詢效能加速，也能節省儲存空間。目前 Druid 在做 Compaction 的時候，會提交一個特殊的 Compaction task，序列掃描 Segment 檔案進行合併，效能較差。我們對此做了一個並行化的方案，思路是提交一個 Hadoop 的任務，在 Hadoop 叢集上去並行掃描 Segment 的資訊，然後去做 Compaction，效能的提升還是非常明顯的。
在平臺易用性方面我們也做了很多的工作。在平臺運營的時候會面臨一個問題，每天都有很多資料來源要接入，在平臺上線初期，管理員是可以參與完成，但是當業務快速增長的時候，這個工作量非常大。資料來源接入後，還會面臨很多需要修改資料來源的維度和指標定義的需求，這些都需要系統化的去解決。
除此之外，很多時候使用者對 Druid 平臺或者對自己的資料理解不夠深入，也可能對業務的分析需求場景不夠明確，在接入資料來源時往往會匯入大量的維度和指標資訊，這就帶來一個隱患：維度越多聚合效果就會變差，更甚至會有一些高基維嚴重影響資料聚合的效果和查詢效能。
針對這些問題，我們設計了兩套工具，分別是 Druid 資料來源管理系統和 Druid 探針系統。
資料來源的管理系統是一個 Web 管理系統，使用者可以在這個系統上完成資料來源接入、檢視和管理，可以檢視的資訊包括維度和指標資訊、Kafka 消費的速率、kafka 消費的 lag 等。上圖展示的是資料來源管理系統的 indexing task 列表資訊，系統配有許可權管理功能，只有資料來源的負責人可以修改資料來源的維度和指標等配置資訊。
上圖是 indexing task 詳情頁面，除了一些基礎的資訊之外，還可以看到像 Kafka 消費的速率情況，使用者可以自主地去排查自己負責的資料來源的線上問題。
這張是資料來源的新建和編輯頁面。使用者新建 Kafka 資料來源的過程非常方便， 其中 Kafka 的資訊是從 Kafka 的管理系統裡面直接抽取出來的，使用者不需要手動填寫，直接點選即可。對於時間戳列和時間戳列的格式，系統會自動抽取使用者 Kafka 的資料做填充，如果是使用者寫錯了時間戳列的格式，也能夠自動糾正過來。對於維度和指標系統也預先做了資料的解析提供 Suggestion，使用者只要用滑鼠點選即可。
這張圖展示的資料來源的列表資訊，可以在列表上清楚地看到這個資料來源的資料量、Segment 檔案的平均大小、維度和指標資訊。此外，如果這個資料來源是通過離線任務匯入的話，能夠會自動關聯離線任務的名字，方便快速定位到自己的定時匯入任務。
Druid 探針系統主要解決如下幾個問題：
第一，資料來源查詢熱度的分析。探針系統會對 Druid 所有的資料來源做總體的查詢熱度排名，這樣管理員可以知道哪些資料來源是查詢的大客戶，會做針對性的“關照”。此外，還可以發現一些沒有查詢請求的冷資料來源或者殭屍資料來源，並通知使用者去做下線處理，避免佔用叢集的資源。
對於單個數據源，探針系統還可以對這個資料來源內部的維度和指標做查詢熱度的分析，了解哪些維度是經常被查詢的，哪些維度和指標是不常查詢的冷維度或指標，特別是還能發現一些既是冷維度又是高基維的維度，這種 Case 會嚴重影響查詢效能，要及時通知使用者進行優化。
下面講一下 OLAP 平臺數據視覺化方面的工作。一個強大的視覺化工具，是 OLAP 平臺必備的元件，我們採用了開源的 Superset 方案。Superset 是 Airbnb 開源的、能與 Druid 深度整合的、互動式的、高效的、資料分析和視覺化平臺，它的功能非常強大，支援種類豐富的資料視覺化的圖表。
截至目前，我們的 Superset 已經積累了上萬個圖表，使用者在使用 Superset 過程中也遇到很多問題，針對這些問題我們對 Superset 同樣做了大量的改造。包括資料的同步、許可權管理、報警功能、產品設計的一些互動改進等。
針對幾個重點的改進點做下介紹，比如對多 time shift 的支援，所謂 time shift 就是可以在一張圖裡面同時繪製出來當前值與前一天同比和環比的指標對比。這裡展示的是當前這一天與前一天，以及上週同天指標對比情況，使用者可以加任意多的其他日期的指標對比到同一張圖裡面。除了這種時序線圖之外，我們對其他圖表也做了大量的 time shift 支援。
這裡展示的是 Superset 同一個看板裡面多個圖表，在滑鼠滑動視窗進行滑行的時候能夠聯動重新整理的功能，對其中一個圖表進行時間範圍選擇，其他圖表能夠關聯進行重新整理，這在進行多表關聯分析的時候還是比較實用的。
這裡展示的是 Superset 報警功能的設計。公司很多監控資料都是依賴 Druid 和 Superset 做資料分析，對報警需求也是非常強烈。我們參考了 Grafana 的報警功能的設計，在 Superset 上也實現了類似的功能，使用者可以在平臺上自定義一些報警維度、指標、檢查週期、報警級別等。
總結：快手對 Druid 的改進在效能提升方面，我們做了時序和維度兩個層面的物化檢視以及元資料方面的互動優化。在資源管理層面，實現了 Supervisor indexing task 的自動伸縮、Middler Manager 細粒度資源分配以及並行 Compaction。在穩定性層面，設計了 Broker 和 Historical 的隔離部署。在平臺易用性層面，自研了資料來源的管理系統、資料探針系統，以及引入 Superset 資料視覺化平臺。
最後分享未來快手 OLAP 平臺的一些工作計劃。首先，我們會引入一些新型的 OLAP 的技術，比如 Clickhouse。第二，我們在考慮 OLAP 與 Adhoc，以及例行報表的整合，希望 OLAP 技術能夠在離線資料分析方面也有更大的發揮空間。第三，從資料的流入到資料的視覺化提供一站式的服務，降低技術人員和非技術人員的使用門檻。第四，希望平臺能夠從技術輸出向產品化、服務化的方向去演進。