ColumnStore在大數據中的應用實踐

作者 | 陳興隆

責編 | 仲培藝

隨著企業數據量急速增長，為了滿足業務需求，大數據統計早已成為迫切的需求。在引擎排行榜上MySQL已經長期處於第二，但大數據統計並沒有明顯突破。

MySQL解決方案包括Infobright、Greenplum、Spark等，與之更為密切的是Infobright，但是多表連接場景下，性能會大幅下降（且特殊功能需要付費）。而ColumnStore的出現則彌補了此處的空缺，是MariaDB在OLAP領域解決方案的突破。ColumnStore是InfiniDB與MariaDB 10.1的結合體，目前已經GA，擁有計算能力及存儲線性擴展、高壓縮比、MySQL協議兼容、自動水平和垂直分區、擴展窗口函數等特點。如果你正在尋找性能及存儲線性擴展、學習成本低、易維護且兼具數據安全及審計的數據倉庫解決方案，相信ColumnStore會給你帶來不小的驚喜。

圖1是來自官方的ColumnStore結構圖。

圖1 ColumnStore架構圖

UM：MariaDB SQL FRONT End（User Module）；

PM：Distributed Query Engine（Performance Module）；

整體架構分為計算層和存儲層，都是可擴展的，計算層需由以下幾項主要進程構成：

MariaDB（mysqld）：收集用戶請求的一個SQL入口，存儲元數據信息；

Execution Manager：解析語法樹，轉化成任務列表（JOB LIST），包括優化、取數據、（HASH）JOIN、匯總、分組；

DMLProc／DDLProc：將DML／DDL語句發送到指定的PM執行；

Performance Module：接受Execution Manager發送過來的任務調度，分布式掃描，（HASH）JOIN與匯總。

由此，我們能清晰地理解整個處理流程：MariaDB收到用戶的SQL請求後，通過執行管理器將SQL轉化為任務列表，再由DMLProc／DDLProc發送任務給PM，最後PM將結果返回給UM進行匯總，返回結果給客戶端。

優勢

存儲、性能、兼容、擴展

為了解決在大數據統計性能上的問題，對比了Infobright和ColumnStore兩種解決方案，最終選取了ColumnStore，對比如下：

表1 數倉方案對比表

1. 對於存儲而言，InnoDB本身的壓縮率並不高，有1倍左右。相比之下，Infobright的壓縮率相對最高，有20倍之多；而ColumnStore則比較適中，為5倍左右。如果為了追求高壓縮比的歷史數據存檔，很明顯使用Infobright社區版是很好的方案。

2. InnoDB自身的擴展性並不高，需要外部中間件來實現分庫分表，因此給予擴展性低的評價；Infobright也可以部署集群，因此擴展性給予高評分；同樣ColumnStore也是易於擴展的分布式方案。

3. 在性能方面，InnoDB的OLTP性能遠高於後兩者，在數據倉庫中提供在線服務，可以考慮用InnoDB來存儲，但統計性能則相差甚遠；由於Infobright中存在Knowledge Grid（知識網格），又使用了列式存儲來壓縮數據，在數據量超過內存容量的情況下，對單列的統計表現卓越，100倍性能提升就成了極輕鬆的事，但如果統計欄位增加或多表查詢，性能也就極速下降；ColumnStore不僅擁有單列高速統計的優勢，而且在多表連接的場景下也表現不俗，當然欄位越多性能同樣會下降，但下降後的速度仍可以接受。

4. Infobright的社區版不支持DML，因此語法兼容性存在很大問題，對查詢的支持尚佳；ColumnStore本身開源，但語法也略有不同，例如多表連接時，不能對同一個表進行多次連接，分組查詢欄位（SELECT COLUMN LIST）必須要在分組列表（GROUP BY LIST）中。

窗口函數

窗口函數（Windowing Function）在數倉的場景下非常有用，當分析App中的行為路徑時，很簡單地就能把用戶的使用路徑串聯起來。

性能優勢

想了解ColumnStore的性能表現，請移步 Percona的性能測試對比（https://www.percona.com/blog/2010/01/07/star-schema-bechmark-infobright-infinidb-and-luciddb/）

限制

數據類型不一致

InnoDB支持的數據類型有：

TINYINT／SMALLINT／MEDIUMINT／INT或INTEGER／BIGINT

FLOAT／DOUBLE／DECIMAL

CHAR／VARCHAR／TINYBLOB／BLOB／MEDIUMBLOB／LOGNGBLOB／TINYTEXT／TEXT／MEDIUMTEXT／LONGTEXT／VARBINARY／BINARY

DATE／TIME／YEAR／DATETIME／TIMESTAMP

ENUM／SET

ColumnStore支持的數據類型為：

TINYINT／SMALLINT／INT或INTERGER／BIGINT

FLOAT／DOUBLE／DEAL／DECIMAL或NUMBER

CHAR／VARCHAR

DATE／DATETIME

通過對比可知，ColumnStore不支持的數據類型有：MEDIUMINT、BLOB、TEXT、BINARY、TIMESTAMP／TIME／YEAR、ENUM／SET

不支持的數據類型，我們通過類型轉換來保證兼容，規則如表2所示：

表2 類型轉換對照表

字元類型長度限制

ColumnStore的字元串類型欄位長度最長為8000，否則報語法錯誤。也許在ColumnStore工程師的眼中，過長的字元不具有很好的分析意義，加之如果文本過大，應該不利於列式存儲發揮壓縮統計的優勢，這可能正是8000長度限制的由來（純屬個人猜測）。大多數場景下，需要把過長的文本截斷以保證系統之間的兼容性。如果業務對此類文本內容依賴較強，建議在原數據中拆分為多行處理。

表總欄位總長度限制

對於長度的限制，不僅欄位的長度有限制，一個表中多個欄位長度總和也有限制。雖然碰見的情況比較少，但也不容忽視。

中文字元長度的限制

MySQL的老司機都知道，MySQL在早期版本里字元串長度的定義為位元組長度（一個漢字佔用三個位元組），後面的版本才定義為字元數（一個漢字佔用一個長度），但ColumnStore或者InfiniDB都佔用三個位元組。如果你的中文字元串莫名其妙地被截斷了，很可能是出現了這個問題，即VARCHAR(3)類型欄位只能存儲一個漢字。

窗口函數的視圖

如果SQL中包含了窗口函數，那麼在創建視圖時會報錯。

建表限制

不支持primary key/auto_increment/index等DDL語句，表名不支持關鍵字。

建議

由於碰到了ColumnStore如此多的限制，使用者很容易出錯，建議自己寫腳本將建表、數據抽取做到自動化，省時省力，其中可能包含的功能建議：

創建表結構

欄位數據類型轉換

欄位長度轉換

資料庫/表名稱變更：

有了以上四點，就不用人工審核每個欄位應該用什麼類型和多大的長度，如果表名字還是個關鍵字（那就更糟糕了），只有把名字改掉了，比如可以加個前綴。

多線程數據抽取

數據增量抽取

當數據量到一定程度，從原資料庫抽取數據會成為瓶頸，此時如果能多線程抽取，那可謂如虎添翼。之前等2個小時才能抽取完的任務，現在10分鐘就搞定。如果再加上增量抽取，那便可以再節省5分鐘。

欄位忽略

前面講過，ColumnStore的欄位長度和表總寬度有限制，但我們不能控制業務表設計，因而只能適應，所以如果有了欄位忽略的功能，把沒有分析統計意義的欄位直接忽略掉，數據就可以很愉快地抽取起來了。

參考

窗口函數

https://www.percona.com/live/mysql-conference-2014/sessions/windowing-functions-mysql-infinidb

性能對比

https://www.percona.com/blog/2010/01/07/star-schema-bechmark-infobright-infinidb-and-luciddb/

https://www.percona.com/blog/2017/03/17/column-store-database-benchmarks-mariadb-columnstore-vs-clickhouse-vs-apache-spark/

結構簡介

http://mt.sohu.com/20161216/n476022933.shtml

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！