本文作者為神策數(shù)據(jù)資深研發(fā)工程師張廣強(qiáng)，版權(quán)歸神策數(shù)據(jù)所有。

和以?MySQL?為代表的傳統(tǒng)事務(wù)型數(shù)據(jù)庫(kù)相比，數(shù)據(jù)倉(cāng)庫(kù)有一個(gè)很大的特點(diǎn)，就是主要面向批量寫和查詢進(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)。本文主要通過神策數(shù)據(jù)在技術(shù)上的探索與實(shí)踐，探討如何利用現(xiàn)有的開源組件實(shí)現(xiàn)分析型數(shù)據(jù)倉(cāng)庫(kù)當(dāng)中的讀寫分離。

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

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

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

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

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

針對(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)行讀寫分離。

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

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

圖1 讀寫分離原理圖

如圖所示，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)化的過程需要是原子操作，因?yàn)閷?duì)上層查詢引擎來(lái)說，同一時(shí)刻，同樣的數(shù)據(jù)只能有一份。

開源方案的操作

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

ROS?的選擇比較簡(jiǎn)單，我們的工程師選擇了?Parquet+ Impala?的查詢方案，同時(shí)結(jié)合我們的業(yè)務(wù)特點(diǎn)做了很多代碼級(jí)別的優(yōu)化。（相關(guān)鏈接：付力力: 基于Impala構(gòu)建實(shí)時(shí)用戶行為分析引擎）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 讀寫分離的實(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)求來(lái)說我們會(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ù)據(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ù)的讀寫效率方面做了比較深入的探索，也參考了眾多優(yōu)秀的開源項(xiàng)目，做了適配產(chǎn)品的優(yōu)化，累計(jì)十萬(wàn)行代碼以上，大數(shù)據(jù)行業(yè)技術(shù)才是企業(yè)的核心競(jìng)爭(zhēng)力，也希望大家在技術(shù)和業(yè)務(wù)層面進(jìn)行開放性的探討。

相關(guān)閱讀：

付力力: 基于Impala構(gòu)建實(shí)時(shí)用戶行為分析引擎

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

數(shù)據(jù)處理中的準(zhǔn)確性問題

如果您對(duì)我們的內(nèi)容感興趣，歡迎關(guān)注“神策數(shù)據(jù)”哦~

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。