以 MySQL 為代表的傳統事務型數據庫相比，數據倉庫有一個很大的特點，就是主要面向批量寫和查詢進行優化，可以不支持更新、事務這些高級特性。一些商用的數據倉庫分析系統，例如 Vertica，已經可以做到千億級數據的秒級導入和秒級查詢。本文主要探討如何利用現有的開源組件實現分析型數據倉庫當中的讀寫分離。

　　為什么要進行讀寫分離

　　分析性數據倉庫一般有如下幾個特點：

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

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

　　（3）數據量比較大，一次寫入，多次查詢。

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

　　但是列存儲格式也有一個缺點：這種格式的數據一旦生成，就很難進行修改，也很難往已有的數據文件當中插入新數據，只能增加新的數據文件。像 MySQL 這種傳統的數據庫，使用的行存儲文件格式是一種適合修改和插入的存儲格式，我們可以認為這種行存儲格式是面向寫進行優化的存儲格式，稱為 WriteOptimized Store（WOS）。

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

　　讀寫分離的實現原理

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

　　圖1 讀寫分離原理圖

　　如圖所示，WOS 文件需要定期轉換為 ROS 文件，同時因為 ROS 在數據倉庫當中一般是分為多個 Partition 存在，所以一個 WOS 可能轉化為多個 ROS。轉化的過程需要是原子操作，因為對上層查詢引擎來說，同一時刻，同樣的數據只能有一份。

　　開源方案的操作

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

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

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

　　后來基于查詢效率和未來架構升級方面的考慮，我們最終選擇了 Kudu 作為 WOS，架構實現示意圖如下：

　　圖2 讀寫分離的實現圖

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

　　這時，我們一方面生成一張新的 Kudu 表作為 Ingesting 表，另一方面開始 WOS 到 ROS 的轉換，通過一個叫做 Mover 的任務執行這個操作。將 Staging 狀態的 Kudu 表中的數據全部轉換到對應 Partition 的 Parquet 表當中。

　　Staging 狀態的表轉換完成且 Ingesting 狀態的表寫滿時，會觸發一個切表操作，需要更新元數據，告訴 Impala 使用新的數據進行查詢，整個切表的操作是原子的。而且已經轉化的 Staging 表還需要保留一段時間，避免切表之前發起的查詢操作沒有及時執行完成。

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

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

　　 最終的技術架構如下圖：

　　圖3 技術架構圖

　　綜上所述， 為了實現數據驅動，在數據倉庫的讀寫效率方面做了比較深入的探索，也參考了眾多優秀的開源項目，做了適配產品的優化，累計十萬行代碼以上，大數據行業技術才是企業的核心競爭力，也希望大家在技術和業務層面進行開放性的探討。