12月7-8日在北京舉辦的ArchSummit全球架構師峯會上，快手科技大數據平臺架構師李遠策分享了快手在OLAP平臺的建設與實踐。以下爲演講的主要內容，有刪節。
快手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技術能夠在離線數據分析方面也有更大的發揮空間。第三，從數據的流入到數據的可視化提供一站式的服務，降低技術人員和非技術人員的使用門檻。第四，希望平臺能夠從技術輸出向產品化、服務化的方向去演進。
嘉賓介紹：
李遠策：快手科技大數據平臺架構師
快手大數據平臺架構師，數據查詢引擎團隊負責人。負責公司 SQL 引擎、OLAP 引擎、多維可視化平臺的研發以及在公司的應用。曾供職於奇虎360，是開源項目 XLearning 的作者。主要研究領域包括分佈式計算、OLAP 引擎、SQL on Hadoop、AI on Hadoop 等。