前沿拓展：

olap

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

作者 | 李遠(yuǎn)策

編輯 | 薛梁

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

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

快手 OLAP 平臺(tái)概覽

快手的 OLAP 平臺(tái)誕生的時(shí)間不長，在 2018 年 4 月份之前，一些**分析的需求還是采用預(yù)定義指標(biāo)加上離線計(jì)算的方案，其缺點(diǎn)很明顯，第一指標(biāo)預(yù)定義是非常固定的，另外因?yàn)椴捎秒x線計(jì)算，實(shí)用性也很差。

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

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

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

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

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

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

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

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

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

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

上面提到 Druid 的查詢性能非常好，小編綜合來說來說主要是因?yàn)椴捎昧巳缦挛鍌€(gè)技術(shù)點(diǎn)：數(shù)據(jù)的預(yù)聚合、列式存儲(chǔ)、Bitmap 索引、mmap、以及查詢結(jié)果的中間緩存。下面針對兩個(gè)點(diǎn)具體展開講一下。

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

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

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

Druid 在快手使用的經(jīng)驗(yàn)以及一些主要改進(jìn)點(diǎn)

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

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

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

在 Historical 數(shù)據(jù)存儲(chǔ)層，做了兩個(gè)層面的數(shù)據(jù)劃分。一是數(shù)據(jù)的冷熱分離，熱數(shù)據(jù)存儲(chǔ)在 SSD 的機(jī)器上，當(dāng)熱數(shù)據(jù)變成冷數(shù)據(jù)之后會(huì)自動(dòng)地遷移到 HDD 機(jī)器上。因?yàn)榇蟛糠植樵兌际遣樵冏罱臄?shù)據(jù)，所以才用 SSD 的加速效果是非常明顯的?？紤]到 SSD 的成本比較高，可以在設(shè)置熱數(shù)據(jù)的副本的時(shí)候，把其中一個(gè)副本放在 SSD 上，另外一個(gè)副本放到 HDD 的機(jī)器上，第二設(shè)置 SSD 副本的權(quán)重，大部分的請求還是能夠落在 SSD 機(jī)器上。當(dāng) SSD 機(jī)器出現(xiàn)故障之后，請求才會(huì)發(fā)送 HDD 上，這樣能節(jié)約不少成本。

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

在大規(guī)模數(shù)據(jù)場景下查詢性能的加速，我們也做了很多優(yōu)化。第一是物化視圖，會(huì)做兩個(gè)層面的物化視圖，一個(gè)是維度層面的物化，一個(gè)是時(shí)序?qū)用娴奈锘?/p>

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

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

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

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

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

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

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

快手對 Druid 集群資源利用率的改進(jìn)

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

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

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

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

除此之外，很多時(shí)候用戶對 Druid 平臺(tái)或者對自己的數(shù)據(jù)理解不夠深入，也可能對業(yè)務(wù)的分析需求場景不夠明確，在接入數(shù)據(jù)源時(shí)往往會(huì)導(dǎo)入大量的維度和指標(biāo)信息，這就帶來一個(gè)隱患：維度越多聚合效果就會(huì)變差，更甚至?xí)幸恍└呋S嚴(yán)重影響數(shù)據(jù)聚合的效果和查詢性能。

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

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

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

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

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

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

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

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

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

本回答被網(wǎng)友采納

olap

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