當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

每个大数据工程师都应该知道的OLAP 核心知识点

發布時間：2023/12/20 编程问答 37 豆豆

生活随笔收集整理的這篇文章主要介紹了每个大数据工程师都应该知道的OLAP 核心知识点小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

轉載：https://mp.weixin.qq.com/s/I2WqQoGwK7LRrpB4R2pobw

很值得學習的一篇文章，不適用于初學者，適用于中級或者進階高級的大數據工程師

OLAP 系統廣泛應用于 BI, Reporting, Ad-hoc, ETL 數倉分析等場景，本文主要從體系化的角度來分析 OLAP 系統的核心技術點，從業界已有的 OLAP 中萃取其共性，分為談存儲，談計算，談優化器，談趨勢?4 個章節。

談儲存??

?

列存的數據組織形式

行存，可以看做 NSM (N-ary Storage Model) 組織形式，一直伴隨著關系型數據庫，對于 OLTP 場景友好，例如 innodb[1] 的 B+ 樹聚簇索引，每個 Page 中包含若干排序好的行，可以很好的支持 tuple-at-a-time 式的點查以及更新等；而列存 (Column-oriented Storage)，經歷了早期的 DSM (Decomposition Storage Model) [2]，以及后來提出的 PAX (Partition Attributes Cross) 嘗試混合 NSM 和 DSM，在 C-Store 論文 [3] 后逐漸被人熟知，用于 OLAP，分析型不同于交易場景，存儲 IO 往往是瓶頸，而列存可以只讀取需要的列，跳過無用數據，避免 IO 放大，同質數據存儲更緊湊，編碼壓縮友好，這些優勢可以減少 IO，進而提高性能。

?

列存的數據組織形式

對于基本類型，例如數值、string 等，列存可以使用合適的編碼，減少數據體積，在 C-Store 論文中對于是否排序、NDV (Number of Distince Values) 區分度，這 4 種排列組合，給出了一些方案，例如數值類型，無序且 NDV 小的，轉成 bitmap，然后 bit-packing 編碼。其他場景的編碼還有 varint、delta、RLE (Run Length Encoding)、字符串字典編碼 (Dictionary Encoding) 等，這些輕量級的編碼技術僅需要多付出一些 CPU，就可以節省不小的 IO。對于復雜類型，嵌套類型的可以使用 Google Dremel 論文 [4] 提出 Striping/Assembly 算法 (開源 Parquet)，使用 Definition Level+Repetition Level做編解碼。一些數值類型有時也可以嘗試大一統的用 bitshuffle [14] 做轉換，配合壓縮效果也不錯，例如 KUDU [7] 和百度 Palo (Doris) 中有應用。在編碼基礎上，還可以進行傳統的壓縮，例如 lz4、snappy、zstd、zlib 等，一般發現壓縮率不理想時可以不啟用。

一些其他的選項，包括 HBase，實際存儲的是純二進制，僅支持 Column Family，實際不是 columnar format，一些序列化框架和 Hadoop 融合比較好的，例如 Avro，也不是列式存儲。

?

儲存格式

現代的 OLAP 往往采用行列混存的方案，采用 Data Block + Header/Footer 的文件結構，例如 Parquet、ORC，Data Block 使用 Row Group (Parquet的叫法，ORC叫做Stripe) -> Column Chunk -> Page 三層級，每一層又有 metadata，Row Group meta包含 row count，解決暴力 count(*)，Column Chunk meta 包含 max、min、sum、count、distinct count、average length 等，還有字典編碼，解決列剪枝，并且提供基礎信息給優化器，Page meta 同樣可以包含 max、min 等，跳頁用于加速計算。

?

存儲索引

在 Parquet、ORC 中，除了列 meta 信息外，不提供其他索引，在其他存儲上，支持了更豐富的索引，索引可以做單獨的塊 (Index Block)，或者形成獨立的文件。例如阿里云 ADB [5]，對于 cardinality 較小的，可以做 bitmap 索引，多個條件下推使用 and/or。倒排索引也是可選的，需要在空間和性能上有所折中，還可以支持全文檢索。Bloom Filter 可以按照 page 粒度做很多組，加速 "in", "=" 查詢，快速做 page 剪枝。另外，假設數據按照某個列或者某幾個列是有序的，這樣可以減少數據隨機性，好處在于相似的數據對編碼壓縮有利，而且可以基于 Row Group、Column Chunk、Page 的 meta 做有效的過濾剪枝，有序列可以使用 B-Tree、Masstree [6]（例如KUDU [7]），或者借鑒 LevelDB 的思想，在 Index Block 內對有序列做稀疏索引，方便二分查找，Index Block 可以用 LRU Cache 盡量常駐內存，這樣有利于按照排序列做點查 (point query) 和順序掃描的范圍查詢 (range query)。另外其他列也可以做稀疏有序索引。有序列如果是唯一，可以看做 OLTP 中主鍵的概念。

?

分布式存儲

DAC (Divide And Conquer) 在分布式領域也是屢試不爽，要突破單機存儲大小和 IO 限制，就需要把一個文件劃分為若干小分片 (sharding)，以某個列做 round-robin、constant、random、range、hash 等，分布在不同的文件或者機器，形成分布式存儲。

第一類，存儲計算一體的架構，基于單機磁盤 (SATA、SSD、NVM)，例如 Greenpulm 基于 PostgreSQL，還有 ClickHouse、百度 Palo (Doris) 等，是 share nothing 架構，可實現多副本，擴容需要 reshard 往往比較耗時。

第二類，存儲計算分離，文件存在分布式存儲 (GFS、HDFS) 或者對象存儲 (S3、OSS、GCS)，是 share everthing (share storage) 架構，好處在于擴展性和可用性的提高，由于存儲網絡延遲，所以一般都做批量、追加寫，而非隨機寫，這把雙刃劍也加大了 OLAP 在實時更新上難度，所以很多都放棄了實時寫和 ACID 能力。存儲計算分離的架構上，例如文件如果存在 HDFS 上，每個分片是一個 HDFS block（例如 128MB 大小），便于高吞吐大塊 IO 順序讀，一個 Row Group 大小等于 block size，便于上層計算引擎，例如 Spark SQL 作業并行計算。存儲計算一體架構，可以更專心的設計文件和分片管理系統，采用 Centralized Master + 多個 Tablet 架構，例如 KUDU 以及 OLTP 新興的 Tikv，分片的多副本依賴于一致性協議 Multi-Paxos 或者支持亂序提交的 Raft 協議，多個分片組成 Raft-Group，這樣可以打散一個表（文件）到多分片多副本的架構上，既保證了擴展性又保證了高可用。Centralized Master 管理分片存放的位置，元數據，便于負載均衡、分裂合并等。

示例：數據按 uid range 分片。?

shard1 shard2+---------------+ +---------------+ |uid| date | |uid| date | +---------------+ +---------------+ | 1 | 2020-11-11| | 3 | 2020-11-13|| 2 | 2020-11-12| | 4 | 2020-11-14|+---------------+ +---------------+

示例：數據按uid hash分片，f(uid) = uid mod 2。?

shard1 shard2+---------------+ +---------------+ |uid| date | |uid| date | +---------------+ +---------------+ | 1 | 2020-11-11| | 2 | 2020-11-12|| 3 | 2020-11-13| | 4 | 2020-11-14|+---------------+ +---------------+

?

數據進一步分區

數據分片的基礎上，可以進行更細粒度的分區 (partition)，便于做分區剪枝 (partition prune)，直接跳過不需要掃描的文件。分片 (sharding) 策略按照 range，可以優化 OLAP 的范圍查詢和快速點查；按照 hash 分區，可以充分打散，有效解決 hotspot 熱點。將二者結合，做二級分區 (two-level)，例如阿里云 ADB、ClickHouse、KUDU，支持 DISTRIBUTED BY HASH 再 PARTITION BY RANGE，而百度 Palo (Doris) 一般先按時間一級分區，更好做冷熱數據區分，二級分區分桶采用 hash。

示例：數據按照二級分區，一級分區uid hash分片，二級分區按date，形成4個文件。?

shard1 shard2+---------------+ +---------------+ |uid| date | |uid| date | +---------------+ +---------------+ | 1 | 2020-11-11| | 2 | 2020-11-12|+---------------+ +---------------+
+---------------+ +---------------+ |uid| date | |uid| date | +---------------+ +---------------+ | 3 | 2020-11-13| | 3 | 2020-11-14| +---------------+ +---------------+

?

實時寫入和 ACID

隨著實時數倉和 HTAP，HSAP [8] 等概念的興起，對于傳統數據處理的 Lambda 架構弊端就凸顯出來，鏈路長，數據冗余，數據一致性不好保證等。融合 OLTP 的能力，第一點就是在之前所述的 immutable table file 上做實時增刪改，要保證低延遲，高吞吐，可以借鑒 LSM-Tree 思想，優化寫吞吐，將流式的低延遲隨機寫，最終變成聚批 mini-batch 的 group commit 順序寫，依賴 write-ahead log 保證持久性，最終形成 Base + Delta 的文件結構，讀流程包括點查或者掃描，基于 Base 的同時，還需要 merge Delta 的變化，另外后臺通過 minor compaction 和 major compaction 不斷的合并 Delta 和 Base，可以不斷優化讀性能，在阿里云 ADB，KUDU，Google MESA [9] 里面都采用了類似的方案。在讀寫一致性層面，需要提供 ACID 和事務隔離特性，比較好保證單行和 mini-batch 的原子性，持久性不言而喻，對于一致性和事務隔離，可以采用 MVCC 機制，每個寫都帶有 version，很簡單的實現帶版本查一致性，快照一致性 (snapshot isolation)。

談計算??

?

查詢步驟

SQL 語言是?OLAP 的標配，一個完整的 SQL 查詢步驟包括：

SQL詞法解析，語法解析；

形成抽象語法樹 (AST)；

校驗檢查；

AST轉成關系代數表達式 (relational algebra)；

根據關系代數表達式生成執行計劃，先生成邏輯執行計劃 (logical plan)；

經過優化器生成最優的執行計劃；

根據執行計劃生成物理執行計劃 (physical plan)；

最終交由執行器執行并返回結果。

由 SQL 到 AST 的過程，類庫和工具較多，C++可用 Lex/Yacc，Java 可用 JavaCC/ANTLR，也可以自己手寫實現。由 AST 到關系代數表達式，可以使用 visitor 模式遍歷。下一章節談優化器，本節聚焦在物理執行計劃后的執行階段。

?

OLAP 數據建模分類

ROLAP 和 MOLAP。Relational OLAP (ROLAP)?對 SQL 支持好，查詢靈活，使用組合模型，雪花或者星型模型組織多張表。ROLAP 計算的數據規模往往小于離線大數據計算（Hive/Spark），ROLAP產品很多，包括傳統的 Greenpulm、Vertica、Teradata，Sql-on-Hadoop 系的 Presto、Impala、Spark SQL、HAWQ，云計算廠商的阿里云 ADB、Google BigQuery，AWS RedShift，有學術界出品的 MonetDB [10]，還有新興的 ClickHouse。

如果把查詢階段分為

cache /\ |pre-computing -> computing -> post computing

上面的提到的存儲技術更多是為了 ROLAP 在 computing 階段優化考慮的，如果把計算中的熵前置到 pre-computing 階段做預計算，也可以大幅優化 computing 階段。

Multidimensional OLAP (MOLAP)?可以把數據預計算，有些場景下不一定需要細粒度的fact，可以嚴格區分維度列和指標列，使用 Kylin、Druid 等，利用上卷 (roll-up) 做數據立方體 (data cube)，這樣可以大大減少 OLAP 場景下聚合查詢的 IO，另外百度 Palo、Google MESA，基于上卷操作做物化視圖，也減少了 IO 消耗，所以他們對于高并發查詢支持普遍較好，但是缺點就在于查詢不夠靈活，數據有冗余。下文主要針對 ROLAP 談計算。

?

計算引擎分類

物理執行計劃往往是一個 DAG，每個節點都是一種 operator，最下游的葉子節點一般都是 TableScan operator，這個 DAG 的分布式執行器就是計算引擎 (Query Engine)，分為兩個流派。

第一類是基于離線計算引擎，例如 Hive on MR，Spark SQL，阿里云 MaxCompute，支持超大規模的數據，進行了容錯保證，多個 stage 落盤 (spill to disk)，使用 resource manager 調度和 queueing，作業可能持續非常長的時間，占用大量資源，并發低。

第二類是MPP，例如 Greenpulm、Presto、Impala、阿里云 ADB，RedShift 支持大規模數據，不需要 resource manager 耗時的分配資源和調度任務，long-running 的 task manager，只需要輕量級的調度，查詢一般不容錯，算子并行執行，并行度有限制避免 straggler node 影響 TP99，相比基于離線的計算引擎往往是短任務，查詢耗時不會太長。

Presto、Impala 屬于 Sql-on-Hadoop MPP，利用 Hive metastore，直接讀取 Parquet、ORC 等文件格式，Greenpulm、RedShift 基于 PostgreSQL，阿里云 ADB 采用私有的數據存儲技術，計算存儲分離的架構，存儲表到分布式存儲盤古上。

?

MPP 架構

通用的 MPP 架構組成由 coordinator，worker，metastore，scheduler 組成，各個產品名稱不同而已。通過 metastore 可以獲取表元信息、分區/分片位置、輔助 coordinator 做校驗等。coordinator 負責從 SQL 到物理執行計劃的生成以及執行，一個計劃往往被切分為多個 plan fragment，plan fragment 之間通過添加 ExchangeOperator 來傳遞數據（例如 shuffle），邏輯上 plan fragment 等同于 stage，scheduler 管理所有 worker 節點，coordinator 調用 scheduler 分發 stage 到不同的 worker 節點執行，就形成了很多 task。一個 task，包含一個或者多個 operator 算子，最簡單的算子實現就是解釋執行 (interpreted) 的模式。算子包括 Project、Filter、TableScan、HashJoin、Aggregation 等，葉子節點一般是 TableScan，拉取存儲中數據。MPP 架構就是充分利用分布式的特性，讓算子分布式的并行計算，同時 task 內部也可以做并行處理，加速查詢。

?

計算執行

數據流

DAG 在進行數據流動時，采用 pipeline 方式，也就是上游 stage 不用等下游 stage 完全執行結束就可以拉取數據并執行計算。數據不落盤，算子之間通過內存直接拷貝到 socket buffer 發送，需要保證內存足夠大，否則容易 OOM。

火山模型 (Volcano-style)

是一種 Row-Based Streaming Iterator Model 算子的實現，只需要 open、next、close 三個函數，就可以實現數據從底向上的“拉”取，驅動計算進行。

向量化執行 (Vectorized query)

MonetDB 論文提出了火山模型的改進方案——向量化執行，火山模型 tuple-at-a-time 的實現，每個算子執行完傳遞一行給上游算子繼續執行，函數調用過多，且大量的虛函數調用，條件分支預測失敗，直接現象就是 CPU 利用率低 (low IPC)。而現代的 CPU 有多級流水線可以實現指令級并行，超標量 (super scalar) 實現亂序執行，對于 forloop 可以有效優化，超線程還能實現線程級并行，而 CPU 多級的 Cache，以及 cache line 的有效利用避免 cache miss，再配合編譯器的優化，都會大大加速計算過程。向量化執行的思想就是算子之間的輸入輸出是一批（Batch，例如上千行）數據，這樣可以讓計算更多的停留在函數內，而不是頻繁的交互切換，提高了 CPU 的流水線并行度，而且還可以使用 SIMD 指令，例如 AVX 指令集來實現數據并行處理。實際實現中，例如 Impala 各個算子的 input 雖然是 RowBatch，但除了 TableScan 算子，其他的也是火山模型執行式的 row by row 處理，TableScan 讀存儲，列式內存布局加速 pushdown 的 filter 執行，aggregation 下推后還可以使用 SIMD 指令加速聚合。但是向量化也會帶來額外的開銷，就是物化中間結果 (materlization)，以犧牲物化的開銷換取更高的計算性能。

動態代碼生成 (codegen)

解釋執行 (interpreted) 的算子，因為面向通用化設計，大數據集下往往效率不高，可以使用 codegen 動態生成算子邏輯，例如 Java 使用 ASM 或者 Janino，C++ 使用 LLVM IR，這樣生成的算子更貼近計算，減少了冗余和虛函數調用，還可以多個算子糅合成一個函數。另外表達式計算的 codegen 還可以做的更極致，一些簡單的計算可以做成匯編指令，進一步加速。

關于向量化或者 codegen，孰優孰劣，論文 Everything You Always Wanted to Know About Compiled and Vectorized Queries But Were Afraid to Ask [11] 進行了深入的對比。二者也可以融合，通過 codegen 生成向量化執行代碼，另外也不一定做 wholestage codegen，和解釋執行也可以一起配合。

計算的耗時有一部分會損耗在 IO、CPU 的閑置上。內存的布局和管理，行式布局還是列式布局，對于 CPU Cache 是否友好，內存池還是按需分配，都會影響著系統的吞吐，C++ 可自行維護 Arena 或者使用 jemalloc 等框架，而 Java 的 heap memory 比較低效還影響 GC，因此使用 Unsafe API 操作堆外內存。另外 Arrow 的興起，也對于跨進程通信后，不必進行數據反序列化、內存分配再拷貝，就可以讀取列式的數據，也進一步加速了計算。

?

常見算子實現

TableScan 算子直讀底層數據源，例如 Presto，抽象了很好了 connector，可對接多種數據源（Hadoop，對象存儲等），一般都支持 projection、filter，因此可以做 filter pushdown 和 projection pushdown 到 TableScan，另外在做 predicate 的時候可以使用 lazy materialization（延遲物化）的技巧去 short circuit 掉先不需要的列。

Join 算子的實現，如果兩個表都很小，最簡單的利用 in-memory hash join、simple nested loop join；一大一小，可以廣播小表 (broadcast)，一般維度表都比較小，如果大表有索引，掃描小表，根據大表做 index lookup join，否則基于小表做 build table，大表做 probe table，實現 hash join；兩個大表，如果兩個表的 join key 的一級分區策略相同，則可以很好的對齊，避免大表 shuffle，直接在大表的 shard 做 local join，如果不能對齊，則兩個表按照 join key shuffle 到其他節點，重分布式后再做 join；另外如果兩個表的 join key 有序，還可以使用 sort-merge join。

?

資源管理與調度

MPP 架構下 coordinator 需要 scheduler 調度 task 到 worker 節點，對于長計算任務或者 ETL 任務，會占用很多資源，導致 OLAP 的并發度受限，其他請求需要排隊，因此很難服務對外在線請求，為了迎合混合負載，傳統 scheduler 簡單粗暴的調度和資源管理已經無法滿足要求，因此可以進行任務的 fine grained schedule 避免空閑資源，請求間對資源的使用盡量的隔離，避免 bad query 吃滿資源，簡單的策略可以通過 label 化集群，或者用 SQL hint 實現，區分長短計算任務，讓更多的短任務也可以快速得到響應。當 OLAP 系統足夠高性能后，更好的資源管理和調度，將會提升 OLAP 為一個支持高并發、低延遲的，可對外提供在線服務的系統，而不僅僅是一個 in-house 的分析系統。

03?

談優化器??

查詢優化器不光是傳統數據庫 DB2、Oracle、MySQL 的核心，在 OLAP 里也至關重要。AST 轉為 SQL 形式化表達語言——關系代數表達式 (relational algebra)，代碼實現就是一顆關系運算符組成的樹，查詢優化主要是圍繞著“等價交換”的原則做相應的轉換，優化關系代數表達式。關系代數的基本運算包括投影 (project)、選擇 (select)、并 (union)、差 (set difference)、連接 (join) 等。優化器分為 Rule-Based Optimizer (RBO) 和 Cost-Based Optimizer (CBO) 兩類。

?

RBO

會將原有表達式裁剪掉，遍歷一系列規則 (Rule)，只要滿足條件就轉換，生成最終的執行計劃。一些常見的規則包括分區裁剪 (Partition Prune)、列裁剪、謂詞下推 (Predicate Pushdown)、投影下推 (Projection Pushdown)、聚合下推、limit 下推、sort 下推、常量折疊 (Constant Folding)、子查詢內聯轉 join 等。

?

CBO

會將原有表達式保留，基于統計信息 + 代價模型，嘗試探索生成等價關系表達式，最終取代價最小的執行計劃。CBO 的實現有兩種模型，Volcano 模型，Cascades 模型，很流行的 Calcite [12] 使用 Volcano 模型，比如 Flink、Hive 都基于此，Orca 使用 Cascades 模型，在 Greenpulm 中使用。優化器需要盡量的高效，高效的生成搜索空間、動態規劃遍歷搜索空間 (top down、bottom up、depth-first 等)，高效的剪枝策略等都可以加速優化過程。統計信息包括表數據大小，row count。查詢列的 trait metadata (min、max、cardinality等)，sortness、可利用的索引，直方圖 (Histogram) 分布統計等。Join 是 OLAP 最消耗吞吐的算子之一，也是 ROLAP 對于分析最強大的地方，可以進行多表的關聯查詢，常見的優化手段包括 join reorder，使用 left-deep tree 還是 bushy tree 執行 join，以及如何選擇 join 算法實現（上節提到的各種 join 實現的選擇），結合高效索引結構實現的 index join，group by 下推、top-n 下推等。

談趨勢??

OLAP 領域經歷了從 RDBMS 建立起來的 SQL + OLAP，到 ETL + 專有 OLAP 的數倉階段，目前仍在不斷演進，更多的云廠商也加入這個領域，展示出、也正經歷著如下的趨勢。

實時分析

傳統的 OLAP 需要做各種 pipeline、ETL 導入數據，這樣的架構會存儲多份數據，冗余并且一致性不好保證，也引入過多的技術棧和復雜度，也不能滿足實時分析，即使 mini-batch 的處理仍然需要最快數分鐘。業界的趨勢在于賦予 OLAP 高吞吐實時寫，提供實時查詢能力，例如上游數據源，經過流計算系統，老的架構基于 lambda，寫歷史數據到存儲再清洗，實時數據入一些 NoSQL，使用方需要做各種數據源 merge 操作，流行的方式是流計算系統直接寫 OLAP，這樣避免了數據孤島，保證了鏈路簡單，阿里云 hologres 團隊提出的 HSAP (Hybrid Serving/Analytical Processing) [8] 正是這種理念。

HTAP

事務處理和分析處理在一個數據庫中提供，是最理想的狀態，但是二者的技術體系往往又很難融合，因此現在很多數據庫廠商都在做這方面的嘗試，保證數據一致性是很大的挑戰，一種思路是從 OLTP 到 OLAP，多副本存儲時，有些副本是專門為 OLAP 定制的，使用專用的 OLAP 引擎提供查詢，另外就是賦予 ACID 和事務能力到 OLAP 系統中，使得 OLAP 也支持 INSERT/DELETE/UPDATE 操作。

云原生

傳統的 OLAP，例如 Exadata 等依賴于高端硬件，很多 on-premise 的解決方案也面臨擴展性和成本問題，云原生的架構通過虛擬化技術，可實現更好的彈性計算，如果采用存儲計算分離的架構還可以實現彈性存儲，這些水平擴展的機制可以很好的兼顧高性能、成本和擴展性。

多模數據結構分析

不僅限于結構化數據，半結構化、非結構化的數據分析也逐漸在 OLAP 中應用，包括向量檢索，JSON、ARRAY 檢索等。

軟硬一體化

計算方面，更好利用多核并行，使得查詢滿足 NUMA-aware，親核性 (affinity) 可以進一步榨干系統的吞吐，使用 FPGA、GPU 硬件加速，利用這些硬件提供的超高帶寬和深度流水線可以加速一些向量計算和聚合操作；存儲方面，隨著存儲查詢帶寬增大、延遲降低，可以應用更多新存儲，例如 Intel 傲騰 NVM 3D-XPoint SSD [13] 提供 2.6G/s 的順序讀吞吐，高并發點查延遲可控制在 10 幾個 us；網絡方面，基于 RDMA 網絡，DPDK 等技術可替換傳統的 tcp，做 kernel bypass，降低網絡延遲。上層的 OLAP 軟件可以基于這些新硬件做更深度的定制，提供更極致的性能。

?

參考資料

[1] [從MySQL InnoDB物理文件格式深入理解索引](從MySQL InnoDB物理文件格式深入理解索引)

[2] [A DECOMPOSITION STORAGE MODEL](inf.ufpr.br/eduardo/ens)

[3] [C-Store: A Column-oriented DBMS](vldb.org/archives/websi)

[4] [Dremel: Interactive Analysis of Web-Scale Datasets](static.googleusercontent.com)

[5] [AnalyticDB: Real-time OLAP Database System at Alibaba Cloud](vldb.org/pvldb/vol12/p2)

[6] [Cache craftiness for fast multicore key-value storage](pdos.csail.mit.edu/pape)

[7] [Kudu: Storage for Fast Analytics on Fast Data](kudu.apache.org/kudu.pd)

[8] [數據倉庫、數據湖、流批一體，終于有大神講清楚了](阿里云Hologres：數據倉庫、數據湖、流批一體，終于有大神講清楚了！)

[9] [Mesa: Geo-Replicated, Near Real-Time, Scalable Data Warehousing](static.googleusercontent.com)

[10] [MonetDB/X100: Hyper-Pipelining Query Execution](w6113.github.io/files/p)

[11] [Everything You Always Wanted to Know About Compiled and Vectorized Queries But Were Afraid to Ask](vldb.org/pvldb/vol11/p2)

[12] [Apache Calcite: A Foundational Framework for Optimized Query Processing Over Heterogeneous Data Sources](arxiv.org/pdf/1802.1023)

[13] [Intel Optane Series](Intel? Optane? DC SSD Series)

[14] [bitshuffle](github.com/kiyo-masui/b)

總結

以上是生活随笔為你收集整理的每个大数据工程师都应该知道的OLAP 核心知识点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：浅析麒麟信安云几大优势之“安全性”篇
下一篇：缠中说缠，最好用的缠论画笔和中枢的指标公