以 MySQL 為代表的傳統(tǒng)事務(wù)型數(shù)據(jù)庫相比，數(shù)據(jù)倉庫有一個很大的特點(diǎn)，就是主要面向批量寫和查詢進(jìn)行優(yōu)化，可以不支持更新、事務(wù)這些高級特性。一些商用的數(shù)據(jù)倉庫分析系統(tǒng)，例如 Vertica，已經(jīng)可以做到千億級數(shù)據(jù)的秒級導(dǎo)入和秒級查詢。本文主要探討如何利用現(xiàn)有的開源組件實(shí)現(xiàn)分析型數(shù)據(jù)倉庫當(dāng)中的讀寫分離。

　　為什么要進(jìn)行讀寫分離

　　分析性數(shù)據(jù)倉庫一般有如下幾個特點(diǎn)：

　　（1）面臨著復(fù)雜的多維分析需求，能夠進(jìn)行任意維度的上卷下鉆。

　　（2）存儲的數(shù)據(jù)維度一般較多，所以是寬表，而且一般比較稀疏。

　　（3）數(shù)據(jù)量比較大，一次寫入，多次查詢。

　　針對這樣特點(diǎn)，分析性數(shù)據(jù)庫一般選擇列存儲數(shù)據(jù)格式，例如 Parquet 等。優(yōu)點(diǎn)是對于統(tǒng)計分析效率很高，而且對于稀疏的寬表具有很高的存儲壓縮比。所以我們可以認(rèn)為列存儲格式是一種面向讀進(jìn)行優(yōu)化的存儲格式，我們稱為 ReadOptimized Store（ROS）。

　　但是列存儲格式也有一個缺點(diǎn)：這種格式的數(shù)據(jù)一旦生成，就很難進(jìn)行修改，也很難往已有的數(shù)據(jù)文件當(dāng)中插入新數(shù)據(jù)，只能增加新的數(shù)據(jù)文件。像 MySQL 這種傳統(tǒng)的數(shù)據(jù)庫，使用的行存儲文件格式是一種適合修改和插入的存儲格式，我們可以認(rèn)為這種行存儲格式是面向?qū)戇M(jìn)行優(yōu)化的存儲格式，稱為 WriteOptimized Store（WOS）。

　　綜上所述，要實(shí)現(xiàn)一個可以秒級導(dǎo)入、秒級查詢的分析型數(shù)據(jù)庫，如果只選用 ROS，則很難支持大數(shù)據(jù)量的秒級導(dǎo)入。如果只選用 WOS，則很難實(shí)現(xiàn)任意維度的秒級查詢，所以我們需要進(jìn)行讀寫分離。

　　讀寫分離的實(shí)現(xiàn)原理

　　數(shù)據(jù)倉庫當(dāng)中需要同時存在 WOS 和 ROS，這樣對于所有的寫操作我們都生成 WOS 型文件；同時所有的讀操作，則主要依賴于 ROS 文件，但也要查詢少量的 WOS 文件。整體示意圖如下：

　　圖1 讀寫分離原理圖

　　如圖所示，WOS 文件需要定期轉(zhuǎn)換為 ROS 文件，同時因?yàn)?ROS 在數(shù)據(jù)倉庫當(dāng)中一般是分為多個 Partition 存在，所以一個 WOS 可能轉(zhuǎn)化為多個 ROS。轉(zhuǎn)化的過程需要是原子操作，因?yàn)閷ι蠈硬樵円鎭碚f，同一時刻，同樣的數(shù)據(jù)只能有一份。

　　開源方案的操作

　　前面簡單介紹了讀寫分離方案的原理，具體的工程實(shí)踐過程中， 的工程師還面臨著很多方案的選擇和實(shí)踐難點(diǎn)。下面簡單介紹一下 在搭建數(shù)據(jù)倉庫的實(shí)踐中啃過的“硬骨頭”。

　　ROS 的選擇比較簡單，我們的工程師選擇了 Parquet+ Impala 的查詢方案，同時結(jié)合我們的業(yè)務(wù)特點(diǎn)做了很多代碼級別的優(yōu)化。WOS 的選擇可能會比較多，我們可以選擇常用的 HDFS 行存儲文件格式，例如 TextFile、SequenceFile、Avro 等。

　　以 SequenceFile 為例，我們在定義自己的 Impala 表的時候，可以指定一個特殊的 Partition 文件的存儲格式為 SequenceFile，同時其他的 Partition 作為正常的按照日期 Partition 的數(shù)據(jù)，指定格式為 Parquet，這種方式的優(yōu)勢體現(xiàn)在始終只有一個表。

　　后來基于查詢效率和未來架構(gòu)升級方面的考慮，我們最終選擇了 Kudu 作為 WOS，架構(gòu)實(shí)現(xiàn)示意圖如下：

　　圖2 讀寫分離的實(shí)現(xiàn)圖

　　如圖所示，我們會建立三張物理表，其中兩張 Kudu 表作為 WOS，一張 Parquet 表作為 ROS。所有的寫操作都會寫入到 Ingesting 狀態(tài)的 Kudu 表中，當(dāng) Ingesting 表寫到一定大小之后，會自動轉(zhuǎn)換為 Staging 狀態(tài)。

　　這時，我們一方面生成一張新的 Kudu 表作為 Ingesting 表，另一方面開始 WOS 到 ROS 的轉(zhuǎn)換，通過一個叫做 Mover 的任務(wù)執(zhí)行這個操作。將 Staging 狀態(tài)的 Kudu 表中的數(shù)據(jù)全部轉(zhuǎn)換到對應(yīng) Partition 的 Parquet 表當(dāng)中。

　　Staging 狀態(tài)的表轉(zhuǎn)換完成且 Ingesting 狀態(tài)的表寫滿時，會觸發(fā)一個切表操作，需要更新元數(shù)據(jù)，告訴 Impala 使用新的數(shù)據(jù)進(jìn)行查詢，整個切表的操作是原子的。而且已經(jīng)轉(zhuǎn)化的 Staging 表還需要保留一段時間，避免切表之前發(fā)起的查詢操作沒有及時執(zhí)行完成。

　　對于查詢請求來說，我們會建立一個包含 Staging 表、Ingesting 表和 ROS 表的虛擬表，即一個 View。用戶的查詢始終指向一個 View，但是下面的物理表會經(jīng)常發(fā)生變化。這樣就兼顧查詢數(shù)據(jù)的不斷更新及查詢性能的優(yōu)化兩方面了。

　　在實(shí)現(xiàn)的過程中還有很多具體的工作，例如如何對表進(jìn)行加列操作，保證各個表的結(jié)構(gòu)一致；Parquet 表中碎文件較多影響查詢效率，如何定期合并等。限于篇幅，這里不再具體介紹。

　　 最終的技術(shù)架構(gòu)如下圖：

　　圖3 技術(shù)架構(gòu)圖

　　綜上所述， 為了實(shí)現(xiàn)數(shù)據(jù)驅(qū)動，在數(shù)據(jù)倉庫的讀寫效率方面做了比較深入的探索，也參考了眾多優(yōu)秀的開源項(xiàng)目，做了適配產(chǎn)品的優(yōu)化，累計十萬行代碼以上，大數(shù)據(jù)行業(yè)技術(shù)才是企業(yè)的核心競爭力，也希望大家在技術(shù)和業(yè)務(wù)層面進(jìn)行開放性的探討。