分析型數(shù)據(jù)倉庫中讀寫分離的實現(xiàn)

作者：張廣強

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

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

為什么要進行讀寫分離

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

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

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

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

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

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

圖1?讀寫分離原理圖

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

開源方案的操作

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

ROS?的選擇比較簡單，我們的工程師選擇了?Parquet+ Impala?的查詢方案，同時結(jié)合我們的業(yè)務(wù)特點做了很多代碼級別的優(yōu)化。（相關(guān)鏈接：付力力:?基于Impala構(gòu)建實時用戶行為分析引擎）WOS?的選擇可能會比較多，我們可以選擇常用的?HDFS?行存儲文件格式，例如?TextFile、SequenceFile、Avro?等。

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

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

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

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

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

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

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

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

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

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

生成海報

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。