OLAP 技術(shù)選型：對什么進(jìn)行選型?
上圖展現(xiàn)的 impala 技術(shù)架構(gòu)，很直觀展示了 OLAP 技術(shù)核心模塊：數(shù)據(jù)模型、存儲格式與數(shù)據(jù)處理架構(gòu)；
數(shù)據(jù)模型
數(shù)據(jù)模型層主要是解決數(shù)據(jù)傳輸問題，通過對數(shù)據(jù)序列化與反序列化，同時提供了遠(yuǎn)程調(diào)用（ 如 RPC ）功能，從而實現(xiàn)跨平臺、多語、客戶端與服務(wù)端數(shù)據(jù)傳輸與通信。傳統(tǒng)跨語言通信方案：
基于 SOAP 消息格式的 WebService
基于 JSON 消息格式的 RESTful 服務(wù)
分布式、大數(shù)據(jù)量跨語言通信方案：
Google protobuf
Apache Thrift
Apache Avro
下圖為 Thrift 協(xié)議棧結(jié)構(gòu)，通過對結(jié)構(gòu)化數(shù)據(jù)的解析，發(fā)送，接受完成數(shù)據(jù)傳輸
大家可能會有疑問，為什么會存在這么多通信協(xié)議與通信框架；只使用 JSON 不香嗎？其實，當(dāng)你想要將一些數(shù)據(jù)存儲在文件中或想要通過網(wǎng)絡(luò)發(fā)送時，你經(jīng)歷了一下幾個演化階段：
使用編程語言的內(nèi)置序列化，如 Java 序列化、Ruby 的 marshal，或 Python 的 pickle。
然而，你意識到困在一種編程語言中是很糟糕的，所以轉(zhuǎn)而使用一種廣泛支持的、與語言無關(guān)的格式，比如 Json。
然而，你發(fā)現(xiàn) JSON 太過冗余，解析太慢，不能區(qū)分整數(shù)和浮點數(shù)，并且你認(rèn)為自己非常喜歡二進(jìn)制字符串和 Unicode 字符串。
然后你會發(fā)現(xiàn)人們使用不一致的類型將各種各樣的隨機字段填充到他們的對象中，這時你非常需要一個 schema 以及一些 documentation。也許你還在使用靜態(tài)類型的語言，并從 schema 生成 model 類。你還會意識到，與 JSON 相似的二進(jìn)制文件實際上不是那么緊湊，因為你在一遍又一遍地存儲字段名。如果你有一個 schema，你可以避免存儲對象的字段名，這樣可以節(jié)省更多字節(jié)。
如果你到了第四階段，你的選擇一般會使 Thrift，Protocol Buffers 或 Avro。這三種方法都為 Java 人員提供了高效的、跨語言的數(shù)據(jù)序列化（使用 schema）和代碼生成。
存儲格式
存儲格式指的是數(shù)據(jù)在存儲介質(zhì)中以什么樣方式進(jìn)行存儲；傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，如 Oracle、DB2、MySQL、SQL SERVER 等采用行式存儲法(Row-based)，在基于行式存儲的數(shù)據(jù)庫中， 數(shù)據(jù)是按照行數(shù)據(jù)為基礎(chǔ)邏輯存儲單元進(jìn)行存儲的， 一行中的數(shù)據(jù)在存儲介質(zhì)中以連續(xù)存儲形式存在。隨著大數(shù)據(jù)的發(fā)展，現(xiàn)在出現(xiàn)的列式存儲和列式數(shù)據(jù)庫。它與傳統(tǒng)的行式數(shù)據(jù)庫有很大區(qū)別的。列式存儲(Column-based)是相對于行式存儲來說的，新興的 Hbase、HP Vertica、EMC Greenplum 等分布式數(shù)據(jù)庫均采用列式存儲。在基于列式存儲的數(shù)據(jù)庫中， 數(shù)據(jù)是按照列為基礎(chǔ)邏輯存儲單元進(jìn)行存儲的，一列中的數(shù)據(jù)在存儲介質(zhì)中以連續(xù)存儲形式存在。下圖為兩種主要列式存儲格式 Parquet 與 ORC 比較。
因此，選擇什么樣存儲格式，會在很多程度上影響到是否支持模式演化（schema evolution）、是否支持 ACID、是否支持 update 操作、查詢性能、數(shù)據(jù)壓縮能力等
數(shù)據(jù)處理框架
數(shù)據(jù)處理框架指的就是 OLAP 引擎或者 OLAP 工具，比如 presto、doris、doris、kylin、clickhouse、impala 等等。這些 OLAP 數(shù)據(jù)處理框架執(zhí)行查詢邏輯一般都會經(jīng)過客戶端發(fā)送 SQL 查詢、引擎節(jié)點解析和分析查詢語句、執(zhí)行查詢某個任務(wù)、向 client 發(fā)送結(jié)果集；下圖是 impala 執(zhí)行流程
對什么進(jìn)行選型
講了這么多，哪我們 OLAP 技術(shù)選型究竟是對什么進(jìn)行選型；很明顯，我們是對 OLAP 數(shù)據(jù)處理框架進(jìn)行選型
但是數(shù)據(jù)處理框架所使用的存儲格式對 OLAP 很多方面起到?jīng)Q定性作用；如下圖，如果我們選型了 impala（使用 Parquet 作為存儲格式），就不能期望對模式演化（schema evolution）有很好支持；再比如，如果選型了 druid（使用作為存儲格式），底層查詢在存儲引擎上的執(zhí)行過程不能向量化執(zhí)行，因此在對大數(shù)據(jù)量、少量列進(jìn)行聚合計算查詢時性能應(yīng)該是比 impala、presto 差。
通過數(shù)據(jù)處理框架所使用存儲格式，再結(jié)合我們需求可以很大程度縮小選型范圍；哪怎么再在這個小范圍再進(jìn)一步去選擇符合我們場景的 OLAP 技術(shù)呢？在下篇再跟大家講講 OLAP 技術(shù)分類，通過這些分類我們可以進(jìn)一步縮小我們選型范圍，最終選擇合適技術(shù)。