[[211185]]

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

神策數(shù)據(jù)一直致力于幫助企業(yè)搭建數(shù)據(jù)倉(cāng)庫(kù)，實(shí)現(xiàn)數(shù)據(jù)的秒級(jí)響應(yīng)，積累數(shù)據(jù)資產(chǎn)。本文主要通過(guò)神策數(shù)據(jù)在技術(shù)上的探索與實(shí)踐，探討如何利用現(xiàn)有的開(kāi)源組件實(shí)現(xiàn)分析型數(shù)據(jù)倉(cāng)庫(kù)當(dāng)中的讀寫(xiě)分離。

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

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

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

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

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

針對(duì)這樣特點(diǎn)，分析性數(shù)據(jù)庫(kù)一般選擇列存儲(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ù)庫(kù)，使用的行存儲(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ù)庫(kù)，如果只選用 ROS，則很難支持大數(shù)據(jù)量的秒級(jí)導(dǎo)入。如果只選用 WOS，則很難實(shí)現(xiàn)任意維度的秒級(jí)查詢，所以我們需要進(jìn)行讀寫(xiě)分離。

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

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

圖1 讀寫(xiě)分離原理圖

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

開(kāi)源方案的操作

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

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è)表。

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

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

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

這時(shí)，我們一方面生成一張新的 Kudu 表作為 Ingesting 表，另一方面開(kāi)始 WOS 到 ROS 的轉(zhuǎn)換，通過(guò)一個(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)的表寫(xiě)滿時(shí)，會(huì)觸發(fā)一個(gè)切表操作，需要更新元數(shù)據(jù)，告訴 Impala 使用新的數(shù)據(jù)進(jìn)行查詢，整個(gè)切表的操作是原子的。而且已經(jīng)轉(zhuǎn)化的 Staging 表還需要保留一段時(shí)間，避免切表之前發(fā)起的查詢操作沒(méi)有及時(shí)執(zhí)行完成。

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

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

神策數(shù)據(jù)最終的技術(shù)架構(gòu)如下圖： 

圖3 神策數(shù)據(jù)技術(shù)架構(gòu)圖

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

本文作者為神策數(shù)據(jù)資深研發(fā)工程師張廣強(qiáng)，版權(quán)歸神策數(shù)據(jù)所有。歡迎關(guān)注神策數(shù)據(jù)（ID：SensorsDataCrop）。