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

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

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

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

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

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

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

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

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

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

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

　　圖1 讀寫分離原理圖

　　如圖所示，WOS 文件需要定期轉(zhuǎn)換為 ROS 文件，同時(shí)因?yàn)?ROS 在數(shù)據(jù)倉庫當(dāng)中一般是分為多個(gè) Partition 存在，所以一個(gè) WOS 可能轉(zhuǎn)化為多個(gè) ROS。轉(zhuǎn)化的過程需要是原子操作，因?yàn)閷?duì)上層查詢引擎來說，同一時(shí)刻，同樣的數(shù)據(jù)只能有一份。

　　開源方案的操作

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

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

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

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

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

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

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

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

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

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

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

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

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