本文作者為神策數據資深研發工程師張廣強，版權歸神策數據所有。

和以?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?的查詢方案，同時結合我們的業務特點做了很多代碼級別的優化。（相關鏈接：付力力: 基于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 神策數據技術架構圖

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

相關閱讀：

付力力: 基于Impala構建實時用戶行為分析引擎

【干貨下載】大數據分析——如何消除金融不確定性

數據處理中的準確性問題

如果您對我們的內容感興趣，歡迎關注“神策數據”哦~

總結

以上是生活随笔為你收集整理的分析型数据仓库中读写分离的实现的全部內容，希望文章能夠幫你解決所遇到的問題。

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