前沿拓展：

olap

保質期為三年，OLAPLEX，中文名：奧拿匹斯連鎖倍增科技，是一種美發(fā)產品。

作者 | 李遠策

編輯 | 薛梁

12 月 7-8 日在北京舉辦的 ArchSummit 全球架構師峰會上，快手科技大數(shù)據(jù)平臺架構師李遠策分享了快手在 OLAP 平臺的建設與實踐。以下為演講的主要內容，有刪節(jié)。

快手 App 目前日活 1.5 億，每天會產生數(shù)萬億規(guī)模的用戶行為數(shù)據(jù)，對這些數(shù)據(jù)的高效探索是一件很有挑戰(zhàn)同時也很有價值的工作。今天重點分享快手建設萬億級數(shù)據(jù)規(guī)模 OLAP 平臺的設計方案以及主要改進過程。

快手 OLAP 平臺概覽

快手的 OLAP 平臺誕生的時間不長，在 2018 年 4 月份之前，一些**分析的需求還是采用預定義指標加上離線計算的方案，其缺點很明顯，第一指標預定義是非常固定的，另外因為采用離線計算，實用性也很差。

在今年 4 月份上線 Druid OLAP 分析引擎，加上 Superset 數(shù)據(jù)可視化平臺，解決了不少業(yè)務的痛點。5 月，Druid 平臺升級到了當時社區(qū)最新的 0.12 的版本，在升級過程中解決了時區(qū)、文件加載性能等問題。7 月，Druid 平臺每天的錄入消息數(shù)已經突破 1000 億，用戶配置的可視化圖表也超過 1000 個。7 月份之后平臺進入了一個快速發(fā)展的階段，Druid 在查詢性能和穩(wěn)定性方面都出現(xiàn)了很多的問題，我們做了非常多的改進。9 月，上線了 Druid 探針系統(tǒng)、時序和維度物化視圖功能、Indexing Service 細顆粒資源分配等，另外在資源調度層面也做了大量優(yōu)化工作。截至今年 11 月，OLAP 平臺每天攝入消息的數(shù)據(jù)量峰值已經超過 5000 億，用戶配置的可視化圖表數(shù)已經突破 1 萬。

半年來 OLAP 平臺發(fā)展速度非?？欤靡嬗诨?Druid 的高可用架構設計，以及團隊伙伴的努力，整個 OLAP 平臺上線至今未出現(xiàn)中型或大型的故障，服務很穩(wěn)定。

快手 OLAP 平臺共有 150 臺物理服務器，接入的數(shù)據(jù)源超過 2000 個，每天錄入的消息數(shù)量在 5000 億左右，索引的數(shù)據(jù)存量約 400TB。每天查詢次數(shù)峰值 1000 萬，這個量是非常大的，但是有很多在程序里觸發(fā) API 的調用，人為觸發(fā)的比例較小。整體上平均查詢時延為 50 毫秒，P90 為 100 毫秒左右，P99 為 500 毫秒到 1 秒。可視化方面，積累的用戶看板數(shù)有八百多個，圖表數(shù)超過 1 萬。

快手使用 OLAP 的業(yè)務場景

第一是多媒體質量分析業(yè)務?？焓质褂昧巳珖嗉?CDN 廠商服務，涉及的域名有幾百個，每天上報的 CDN 質量**數(shù)據(jù)上百億。CDN 服務質量會直接關系到主站 APP 用戶使用體驗，公司 CDN 質量團隊需要實時對 CDN **數(shù)據(jù)做分析和智能調度，以及對調度效果進行實時的監(jiān)測。另外，對于 CDN 質量問題需要做出快速分析和**，這本身也是一個**分析的過程，OLAP 技術能夠很好地滿足這個需求。

另外一個業(yè)務場景是 A/B Test，快手已經上線了約 1000 個 A/B 的實驗，需要對比的 A/B 指標多達數(shù)千個，每天有數(shù)百億的數(shù)據(jù)要流入 A/B Test 平臺。對 A/B Test 指標的分析，也是一個很典型的**分析的過程，OLAP 平臺要滿足每天幾十萬次的查詢調用需求，查詢的時延要保證在百毫秒級。

OLAP 平臺選型時對公司多個業(yè)務團隊的需求做了調研，小編綜合來說來講，大家對以下幾個點關注度會比較高。比如超大數(shù)據(jù)規(guī)模的支持，單個數(shù)據(jù)源可能每天有上百億的數(shù)據(jù)量需要錄入；查詢時延，要保證在毫秒到秒級；數(shù)據(jù)實時性，很多業(yè)務線明確提出實時數(shù)據(jù)分析的需求；另外還有高并發(fā)查詢、平臺穩(wěn)定性等，除此之外還有一些相對權重比較低的需求：如數(shù)據(jù) Schema 的靈活變更、精確去重的功能，以及 SQU 接口的支持等。

根據(jù)對用戶調研的小編綜合來說，我們對比了現(xiàn)在比較常用的 OLAP 技術。

第一，Hive/SparkSQL 在數(shù)據(jù)倉庫的領域應用是比較廣泛的，但是因為查詢時延很難能夠滿足毫秒到秒級的要求，同時因為是離線計算，數(shù)據(jù)時效性也比較差。第三，ES 是一個功能很強大的系統(tǒng)，在中等數(shù)據(jù)規(guī)模場景下能較好地滿足需求，但是在萬億和更大的數(shù)據(jù)規(guī)模場景下，數(shù)據(jù)的寫入性能和查詢性能都遇到了很大的瓶頸。Kylin 和 Druid 功能比較類似，考慮到 Druid 采用 OLAP 架構，數(shù)據(jù)時效性相對于 Kylin 來講會更好，數(shù)據(jù)的變更也相對更加靈活，所以最終選用 Druid 作為 OLAP 平臺的查詢引擎。Druid 系統(tǒng)概述

上圖是 Druid 系統(tǒng)架構圖，其中 Coordinator 和 Overlord 是 Druid 的主節(jié)點；Middle Manager 主要是負責數(shù)據(jù)索引，生成索引文件，Historical 節(jié)點主要負責加載索引文件，同時提供歷史數(shù)據(jù)的查詢服務；Broker 是查詢的接入節(jié)點；除此，Druid 還需要對元數(shù)據(jù)進行存儲，比如選用 MySQL；Middle Manager 在產生索引文件的時候，需要把索引文件先發(fā)布到一個共享的存儲系統(tǒng)里，我們選擇了大家普遍采用的 HDFS 系統(tǒng)。

上面提到 Druid 的查詢性能非常好，小編綜合來說來說主要是因為采用了如下五個技術點：數(shù)據(jù)的預聚合、列式存儲、Bitmap 索引、mmap、以及查詢結果的中間緩存。下面針對兩個點具體展開講一下。

第一講下數(shù)據(jù)預聚合。Druid 會把一行數(shù)據(jù)消息分成三個部分，包括時間戳列、維度列以及指標列。所謂預聚合，就是當數(shù)據(jù)錄入到 Druid 系統(tǒng)時，會按照一定的時間周期把原始數(shù)據(jù)做一次預先聚合，會根據(jù)一個全維度聚合出要計算的指標，也就是要索引的內容。后續(xù)所有的查詢都是通過這些預聚合的中間結果做二次查詢。

接下來講下 Bitmap 索引。Bitmap 索引主要為了加速查詢時有條件過濾的場景。Druid 在生成索引文件的時候，對每個列的每個取值生成對應的 Bitmap **。如圖上所示，Gender 為 Male 對應的 Bitmap 為“1001”，代表第 1 行和第 4 行的 Gender 為“Male”。舉一個查詢的例子，假設要篩選 Gender =‘Female’and City =‘Taiyuan’的數(shù)據(jù)，那么只需要把 Gender =‘Female’對應的 Bitmap “0110”和 Taiyuan 對應的 Bitmap “0101”進行與**作，得到結果為“0100”，代表第二行滿足篩選條件。通過 Bitmap 可以快速**要讀取的數(shù)據(jù)，加速查詢速度。

關于 Druid 模塊，Druid 支持從 kafka 實時導入數(shù)據(jù)，同時也支持批量從 HDFS 或者 HIVE 系統(tǒng)進行離線導入；Druid 提供了豐富的查詢 API 接口。除了默認提供的 Restful 接口之外，Python 、Java、Go 等編程語言都有第三方的實現(xiàn) API 接口。此外，Druid 也提供了 SQL 接口的支持。值得一提的是，Hive 在 2.2 版本之后通過 StorageHandler 實現(xiàn)了對 Druid 的支持，這樣可以通過 Hive SQL 查詢 Druid 里的數(shù)據(jù)，快手內部也在用，但是需要做一些修改工作，比如解決時區(qū)問題、Druid 數(shù)據(jù)源維度和指標的大小寫敏感問題，以及實現(xiàn)默認的 limit、默認時間范圍選擇等功能。

Druid 在快手使用的經驗以及一些主要改進點

這是快手 OLAP 的平臺架構圖，中間部分是 Druid 自有的組件，數(shù)據(jù)通過 kafka 實時攝入和離線從 Hive 數(shù)倉中批量導入。除此之外，我們還配套了完善的 Metric 系統(tǒng)，探針系統(tǒng)、Druid 數(shù)據(jù)源管理系統(tǒng)等。

在萬億甚至幾十萬億數(shù)據(jù)規(guī)模場景下，OLAP 平臺使用過程中也面臨了很多挑戰(zhàn)。比如如何讓查詢變得更快，資源的利用率如何更高效，在數(shù)據(jù)的管理到數(shù)據(jù)的接入如何更方便，集群平臺如何更穩(wěn)定，針對這些問題我們都針對性的做了改進和優(yōu)化。

第一，穩(wěn)定性方面我們做了多種的資源隔離部署的方案，在接入層通過**實現(xiàn) Broker 的高可用和負載均衡。

在 Historical 數(shù)據(jù)存儲層，做了兩個層面的數(shù)據(jù)劃分。一是數(shù)據(jù)的冷熱分離，熱數(shù)據(jù)存儲在 SSD 的機器上，當熱數(shù)據(jù)變成冷數(shù)據(jù)之后會自動地遷移到 HDD 機器上。因為大部分查詢都是查詢最近的數(shù)據(jù)，所以才用 SSD 的加速效果是非常明顯的?？紤]到 SSD 的成本比較高，可以在設置熱數(shù)據(jù)的副本的時候，把其中一個副本放在 SSD 上，另外一個副本放到 HDD 的機器上，第二設置 SSD 副本的權重，大部分的請求還是能夠落在 SSD 機器上。當 SSD 機器出現(xiàn)故障之后，請求才會發(fā)送 HDD 上，這樣能節(jié)約不少成本。

除了冷熱數(shù)據(jù)分離的考慮外，因為有些對查詢穩(wěn)定性要求更高，快手通過 Tier 配置也對特殊業(yè)務也做了隔離，特殊的業(yè)務數(shù)據(jù)源索引數(shù)據(jù)存儲在專用的 Historical 機器上。這樣在一些大查詢可能會導致 historical 內存 GC 或者是系統(tǒng) IO 支持 Load 較高的場景下，其查詢性能仍然不受影響。

在大規(guī)模數(shù)據(jù)場景下查詢性能的加速，我們也做了很多優(yōu)化。第一是物化視圖，會做兩個層面的物化視圖，一個是維度層面的物化，一個是時序層面的物化。

什么是物化視圖，假設一個數(shù)據(jù)源的原始維度有十個列，通過分析查詢請求發(fā)現(xiàn)，group1 中的三個維度和 group2 中的三個維度分別經常同時出現(xiàn)，剩余的四個維度可能查詢頻率很低。更加嚴重的是，沒有被查詢的維度列里面有一個是高基維，就是 count district 值很大的維度，比如說像 User id 這種。這種情況下會存在很大的查詢性能問題，因為高基維度會影響 Druid 的數(shù)據(jù)預聚合效果，聚合效果差就會導致索引文件 Size 變大，進而導致查詢時的讀 IO 變大，整體查詢性能變差。針對這種 case 的優(yōu)化，我們會將 group1 和 group2 這種維度分別建一個預聚合索引，第二當收到新的查詢請求，系統(tǒng)會先分析請求里要查詢維度**，如果要查詢的維度**是剛才新建的專用的索引維度**的一個子集，則直接訪問剛才新建的索引就可以，不需要去訪問原始的聚合索引，查詢的性能會有一個比較明顯的改善，這就是物化視圖的一個設計思路，也是一個典型的用空間換時間的方案。

時序物化視圖：除了剛才提到的查詢場景外，還有一種查詢 Case，Druid 也不能很好滿足。比如大跨度時間范圍的查詢，假設一個數(shù)據(jù)源的聚合力度是分鐘級別，但需要查詢最近三個月的數(shù)據(jù)就比較麻煩，因為需要把過去三個月的所有分鐘級別的索引文件全部掃描一遍，第二再做一次聚合的計算。

為了解決這個問題，我們在數(shù)據(jù)源分鐘級別的索引上再新建一個小時級別甚至級別的物化索引，這種情況下聚合效果就會更好，索引整體的 size 也會比較小。當收到一個新的查詢請求時，如果查詢要統(tǒng)計的粒度是天級別或者是更高級別的查詢粒度，會把查詢請求自動路由到天級別物化索引上，這樣查詢性能也會有一個比較明顯的改善。

下面討論下 Druid 元數(shù)據(jù)存儲系統(tǒng)的性能優(yōu)化，平臺上線以來我們積累了大約幾百萬的 Segment 文件，對這些數(shù)百萬 Segment 元信息的查詢，或者說 MySQL Segments 表的查詢也遇到的性能瓶頸。

第一是 Overlord 與 MySQL 之間的交互優(yōu)化。Overlord 在發(fā)布新的 Segment 文件的時候會多次查詢 Segments 表，**發(fā)現(xiàn)會有大量的慢查詢。解決方案很簡單，針對性地對 Segments 表增加索引即可。對比優(yōu)化后的 MySQL 查詢性能，可以從 10 秒多降到 1 秒，有 10 倍以上的提升。

另外是 Coordinator 與 MySQL 之間的交互性能優(yōu)化。Coordinator 會周期性的去全量掃描 Segments 表，每次掃描都會花費較長的時間。第一全量掃描完全是沒必要的，我們改造成增量掃描的方案，整個掃描的耗時從原來的 1.7 分鐘降到 40 秒左右。第二更進一步對增量掃描的 SQL 專門創(chuàng)建了 MySQL 索引，掃描耗時可以降到 30 毫秒，整體算下來有上千的性能提升。

接下來是 Segment 文件加載過程的優(yōu)化，Coordinator 掃描 segment 匹配 Rule 過程默認是串行實現(xiàn)的，我們對此做了并行化的加速，再加上一些細節(jié)點的改進。集群幾百萬量級的 Segment 文件協(xié)調一遍的耗時從原來的 3 分鐘降低到現(xiàn)在的 30 秒。Druid 元數(shù)據(jù)系統(tǒng)通過如上幾個點的優(yōu)化后，目前基本上不再有性能瓶頸。

快手對 Druid 集群資源利用率的改進

第一，每個 Kafka indexing task 會對應一個 Supervisor 的服務，Supervisor 的 task count 是一個固定的值，當用戶設置 task count 比較小時，可能會因為讀取 Kafka 的 lag 過大而出現(xiàn)數(shù)據(jù)延遲，而如果設置的過大會造成資源的浪費。另外，用戶在創(chuàng)建一個 indexing task 的時候，也很難估算 task count 應該是多少合適。我們的優(yōu)化方案是讓 Supervisor 根據(jù)當前消費 Kafka 時延的情況，自動調節(jié) task count，這樣業(yè)務高峰期不至于出現(xiàn)數(shù)據(jù)延時，數(shù)據(jù)低峰期時也能把資源還給集群，整個集群的利用率有明顯提升。

另外是 Middle Manager 的 indexing task 資源分配問題。Druid 為每個 Middler Manager 分配一個固定的 Slot 數(shù)，但是因為相對 Kafka indexing task 來講 Hadoop indexing task 其實只是一個 Hadoop 客戶端僅負責提交一個任務，本身并不怎么占資源，這樣的話會有一些資源的浪費的問題。針對這個問題的優(yōu)化思路是，把 Middler Manager 的 task 調度配置從按照 Slot 數(shù)改成按照內存大小分配，我們會區(qū)別對待不同類型的 task，對于 Kafka 的 task 和 Hadoop 的 task 會默認不同的內存大小，當然用戶在提交 task 的時候，可以指定自己的 task 內存大小，我們會做一些最大值的限制，防止惡意的提交。

此外，對 Segment 文件及時的做 Compaction 會有益于查詢性能加速，也能節(jié)省存儲空間。目前 Druid 在做 Compaction 的時候，會提交一個特殊的 Compaction task，串行掃描 Segment 文件進行合并，性能較差。我們對此做了一個并行化的方案，思路是提交一個 Hadoop 的任務，在 Hadoop 集群上去并行掃描 Segment 的信息，第二去做 Compaction，性能的提升還是非常明顯的。

在平臺易用性方面我們也做了很多的工作。在平臺運營的時候會面臨一個問題，每天都有很多數(shù)據(jù)源要接入，在平臺上線初期，管理員是可以參與完成，但是當業(yè)務快速增長的時候，這個工作量非常大。數(shù)據(jù)源接入后，還會面臨很多需要修改數(shù)據(jù)源的維度和指標定義的需求，這些都需要系統(tǒng)化的去解決。

除此之外，很多時候用戶對 Druid 平臺或者對自己的數(shù)據(jù)理解不夠深入，也可能對業(yè)務的分析需求場景不夠明確，在接入數(shù)據(jù)源時往往會導入大量的維度和指標信息，這就帶來一個隱患：維度越多聚合效果就會變差，更甚至會有一些高基維嚴重影響數(shù)據(jù)聚合的效果和查詢性能。

針對這些問題，我們設計了兩套工具，分別是 Druid 數(shù)據(jù)源管理系統(tǒng)和 Druid 探針系統(tǒng)。

數(shù)據(jù)源的管理系統(tǒng)是一個 Web 管理系統(tǒng)，用戶可以在這個系統(tǒng)上完成數(shù)據(jù)源接入、查看和管理，可以查看的信息包括維度和指標信息、Kafka 消費的速率、kafka 消費的 lag 等。上圖展示的是數(shù)據(jù)源管理系統(tǒng)的 indexing task 列表信息，系統(tǒng)配有權限管理功能，只有數(shù)據(jù)源的負責人可以修改數(shù)據(jù)源的維度和指標等配置信息。

上圖是 indexing task 詳情頁面，除了一些基礎的信息之外，還可以看到像 Kafka 消費的速率情況，用戶可以自主地去排查自己負責的數(shù)據(jù)源的線上問題。

這張是數(shù)據(jù)源的新建和編輯頁面。用戶新建 Kafka 數(shù)據(jù)源的過程非常方便， 其中 Kafka 的信息是從 Kafka 的管理系統(tǒng)里面直接抽取出來的，用戶不需要手動填寫，直接點選即可。對于時間戳列和時間戳列的格式，系統(tǒng)會自動抽取用戶 Kafka 的數(shù)據(jù)做填充，如果是用戶寫錯了時間戳列的格式，也能夠自動糾正過來。對于維度和指標系統(tǒng)也預先做了數(shù)據(jù)的解析提供 Suggestion，用戶只要用鼠標點選即可。

這張圖展示的數(shù)據(jù)源的列表信息，可以在列表上清楚地看到這個數(shù)據(jù)源的數(shù)據(jù)量、Segment 文件的平均大小、維度和指標信息。此外，如果這個數(shù)據(jù)源是通過離線任務導入的話，能夠會自動關聯(lián)離線任務的名字，方便快速**到自己的定時導入任務。

OLAP即聯(lián)機分析處理，是數(shù)據(jù)倉庫的核心部心，所謂數(shù)據(jù)倉庫是對于大量已經由OLTP形成的數(shù)據(jù)的一種分析型的數(shù)據(jù)庫，用于處理商業(yè)智能、決策支持等重要的決策信息。

數(shù)據(jù)倉庫是在數(shù)據(jù)庫應用到一定程序之后而對歷史數(shù)據(jù)的加工與分析；是處理兩種不同用途的工具而已。

On-Line Transaction Processing聯(lián)機事務處理過程(OLTP)。

也稱為面向交易的處理過程，其基本特征是前臺接收的用戶數(shù)據(jù)可以立即傳送到計算中心進行處理，并在很短的時間內給出處理結果，是對用戶**作快速響應的方式之一。

本回答被網友采納

olap

oltp主要是事務處理方面的，而olap主要是用于數(shù)據(jù)分析。
一般的數(shù)據(jù)庫通常都是oltp，因為主要用于在線記錄數(shù)據(jù)，離線進行數(shù)據(jù)分析。
而如果要隨時進行數(shù)據(jù)挖掘，或者提高數(shù)據(jù)分析的效率，讓人們可以隨時觀察分析數(shù)據(jù)的情況之類的，就需要olap了?，F(xiàn)在一些大型的數(shù)據(jù)庫軟件都逐漸提供了部分olap的功能，但是這些的實際應用目前還不是很多