《分布式數(shù)據(jù)庫和Hadoop都不夠好，于是我們設(shè)計分布式SQL計算系統(tǒng)》要點：
本文介紹了分布式數(shù)據(jù)庫和Hadoop都不夠好，于是我們設(shè)計分布式SQL計算系統(tǒng)，希望對您有用。如果有疑問，可以聯(lián)系我們。

設(shè)計思想

為了解決分布式數(shù)據(jù)庫下,復(fù)雜的 SQL(如全局性的排序、分組、join、子查詢,特別是非均衡字段的這些邏輯操作)難以實現(xiàn)的問題；在有了一些分布式數(shù)據(jù)庫和 Hadoop?實際應(yīng)用經(jīng)驗的基礎(chǔ)上,對比兩者的優(yōu)點和不足,加上自己的一些提煉和思考, 設(shè)計了一套綜合兩者的系統(tǒng),利用兩者的優(yōu)點, 補充兩者的不足.具體的說, 使用數(shù)據(jù)庫水平分割的思想實現(xiàn)數(shù)據(jù)存儲,使用 MapReduce的思想實現(xiàn) SQL 計算.

這里的數(shù)據(jù)庫水平分割的意思是只分庫不分表,對于不同數(shù)量級別的表,分庫的數(shù)量可以不一樣,例如 1 億的數(shù)據(jù)量分 10 個分庫,10 億的分 50 個分庫.對于使用 MapReduce的思想實現(xiàn)計算 ; 對于一個需求,轉(zhuǎn)換成一個或多個有依賴關(guān)系的SQL,其中的每個SQL分解成一個或多個 MapReduce任務(wù),每個 MapReduce任務(wù)又包含 mapsql、洗牌(shuffle)、reducesql,這個過程可以理解為類似 hive,區(qū)別是連 MapReduce任務(wù)中的 map 和 reduce 操作也是通過?SQL?實現(xiàn), 而非 Hadoop?中的 map 和 reduce 操作.

這是基本的 MapReduce的思想,但是在 Hadoop 的生態(tài)圈中, 第一代的MapReduce將結(jié)果存儲于磁盤,第二代的 MapReduce根據(jù)內(nèi)存使用情況將結(jié)果存儲于內(nèi)存或磁盤,類比一下用數(shù)據(jù)庫來存儲,那么 MapReduce 的結(jié)果就是存儲在表中,而數(shù)據(jù)庫的緩存機制天然支持根據(jù)內(nèi)存情況決定存儲在內(nèi)存還是磁盤 ; 另外,Hadoop?生態(tài)圈中, 計算模型也并非一種,這里的 MapReduce的計算思想,可以用類似 spark 的 RDD 迭代計算方式來替代 ; 本系統(tǒng)還是基于MapReduce來說明的.

架構(gòu)

根據(jù)以上的思想, 系統(tǒng)的架構(gòu)如下：

沒有代理節(jié)點 ?

有代理節(jié)點 ?

模塊說明 ?

關(guān)于系統(tǒng)中的模塊,由于和絕大部分的分布式系統(tǒng)類似,這里僅做簡要說明：

兩種架構(gòu)的區(qū)別 ?

無代理節(jié)點的時候,客戶端擔(dān)負著比較大的工作,包括：發(fā)送請求、解析 SQL、生成執(zhí)行計劃、申請資源、安排執(zhí)行、獲取結(jié)果等；有代理節(jié)點的時候,代理節(jié)點擔(dān)負著接受請求、解析 SQL、生成執(zhí)行計劃、申請資源、安排執(zhí)行、返回結(jié)果給客戶端等大部分責(zé)任,另外代理節(jié)點提供支持外部協(xié)議的接口,如 mysql 的 c/s 協(xié)議,使用 mysql 的命令行可以直接連接進來執(zhí)行 SQL,整個系統(tǒng)就像普通的 mysql server 一樣.

應(yīng)用架構(gòu) ?

實際應(yīng)用環(huán)境可能是正式環(huán)境一套, 正式備份環(huán)境一套, 線下環(huán)境一套, 可以按照如下的架構(gòu)進行部署.

基本概念 說明

下面針對架構(gòu)中的一些概念做些說明

下面說明常用的增刪改查如何執(zhí)行, 特別是查詢操作

增刪改操作

當(dāng)插入數(shù)據(jù)的時候,根據(jù)均衡字段和均衡策略將記錄插入到對應(yīng)的數(shù)據(jù)庫節(jié)點中.

當(dāng)更新數(shù)據(jù)的時候,需要根據(jù)均衡策略判斷數(shù)據(jù)更新前的和更新后的數(shù)據(jù)庫節(jié)點是否變化：如果沒有變化,直接更新；如果有變化,在更新前的數(shù)據(jù)庫節(jié)點中刪除老數(shù)據(jù),在更新后的數(shù)據(jù)庫節(jié)點中插入新數(shù)據(jù).

當(dāng)刪除數(shù)據(jù)的時候,根據(jù)均衡策略在相應(yīng)的數(shù)據(jù)庫節(jié)點中刪除.

這三種變更數(shù)據(jù)的操作,只要涉及到多個節(jié)點的數(shù)據(jù)變更,都需要使用分布式事務(wù)保證一致性、原子性等事務(wù)特性.

查詢操作

查詢操作的原理類似 hive,大家可以對比來理解 ; 為了方便解釋查詢操作, 首先來說明階段樹和階段的結(jié)構(gòu),如下圖所示：

階段樹 ?

階段

查詢步驟

結(jié)合上面的圖, 查詢操作的具體過程如下:

1. 將輸入 SQL 經(jīng)過詞法、語法、語義分析,集合表結(jié)構(gòu)信息和數(shù)據(jù)分布信息,生成包含多個階段(簡稱 stage)的執(zhí)行計劃,這些階段具有一定的依賴關(guān)系,形成多輸入單輸出的任務(wù)樹.
2. 每個階段包括兩種 SQL,稱為 mapsql 和 reducesql,另外每個階段包括三個操作,map、數(shù)據(jù)洗牌和 reduce；map 和 reduce 分別執(zhí)行 mapsql 和 reducesql.
3. 先在不同的數(shù)據(jù)庫節(jié)點中執(zhí)行 map 操作,map 操作執(zhí)行 mapsql,它的輸入是每個數(shù)據(jù)庫節(jié)點上的表內(nèi)部的數(shù)據(jù),輸出根據(jù)某個字段按照一定的規(guī)則進行分割,放到不同的結(jié)果集中,結(jié)果集作為數(shù)據(jù)洗牌的輸入.
4. 然后執(zhí)行數(shù)據(jù)洗牌的過程,將不同結(jié)果集拷貝到不同的將要執(zhí)行 reduce 的數(shù)據(jù)庫節(jié)點上.
5. 在不同的數(shù)據(jù)庫節(jié)點中執(zhí)行 reduce 操作,reduce 操作執(zhí)行 reducesql；
6. 最后返回結(jié)果.

例子

由于系統(tǒng)核心在于存儲和計算, 下面對存儲和計算相關(guān)的概念舉例說明

均衡策略

舉例說明均衡策略,基本信息如下：表名字：tab_user_login表描述：用于存儲用戶登錄信息節(jié)點數(shù)：4,分為 0、1、2、3

舉例說下如下的幾種策略：

列表：以登錄省份作為均衡字段為例

取模 hash：按 4 取模, 以用戶 id 作為均衡字段

范圍: 從 0 到一億,以用戶 id 作為均衡字段

取模 hash 和范圍結(jié)合：先范圍,再取模, 以用戶 id 作為均衡字段

查詢

舉例說明查詢操作,基本信息如下：

用戶表 tab_user_info 如下：

用戶登錄表 tab_login_info 的結(jié)構(gòu)如下：

排序

排序的關(guān)鍵點是節(jié)點之間存在大小關(guān)系,大的 key 或者 key 范圍放到節(jié)點 id 大的節(jié)點上,然后在節(jié)點上排序,獲取數(shù)據(jù)的時候根據(jù)節(jié)點 id 大小依次獲取.

以如下 sql 為例,某一注冊時間范圍內(nèi)的用戶信息,按照年齡和 id 排序：

select * from tab_user_info t where u_reg_dt>=? and u_reg_dt<=? order by u_id

執(zhí)行計劃可能為：

Map：

select * from tab_user_info t where u_reg_dt>=? and u_reg_dt<=? order by u_id

Shuffle：

執(zhí)行完成之后,這種情況下由于需要按照 u_id 進行數(shù)據(jù)洗牌,所以各個存儲節(jié)點上需要按照 u_id 進行劃分.例如有 N 個計算節(jié)點,那么按照(最大 u_id- 最小 u_id)/N 平均劃分,將不同存儲節(jié)點上的同一范圍的 u_id,劃分到同一個計算節(jié)點上即可(這里的計算節(jié)點存在大小關(guān)系).

Reduce：

select * from tab_user_info t order by u_id

分組聚合

關(guān)鍵點和排序類似,節(jié)點之間存在大小關(guān)系,大的 key 或者 key 范圍放到節(jié)點 id 大的節(jié)點上,然后在節(jié)點上分組聚合,獲取數(shù)據(jù)的時候根據(jù)節(jié)點 id 大小依次獲取.

以如下 sql 為例,某一注冊時間范圍內(nèi)的用戶,按照年齡分組,計算每個分組內(nèi)的用戶數(shù)：

select age,count(u_id) v from tab_user_info t where u_reg_dt>=? and u_reg_dt<=? group by age

執(zhí)行計劃可能為：

Map：

select age,count(u_id) v from tab_user_info t where u_reg_dt>=? and u_reg_dt<=? group by age

Shuffle：

執(zhí)行完成之后,這種情況下由于需要按照 age 進行數(shù)據(jù)洗牌,考慮到 age 的唯一值比較少,所以數(shù)據(jù)洗牌可以將所有的記錄拷貝到同一個計算節(jié)點上.

Reduce：

select age,sum(v) from t where group by age

連接 ?

首先明確 join 的字段類型為數(shù)字類型和字符串類型,其他類型如日期可以轉(zhuǎn)換為這兩種.數(shù)字類型的排序很簡單,字符串類型的數(shù)據(jù)排序需要確定規(guī)則,類似 mysql 中的 collation,比較常用的是按照 unicode 編碼順序,按照實際存儲節(jié)點的大小等；其次 join 的方式有等值 join 和非等值 join；以如下常用且比較簡單的情況為例.

以如下 sql 為例,某一注冊時間范圍內(nèi)的用戶的所有登錄信息：

select t1.u_id,t1.u_name,t2.login_product

from tab_user_info t1 join tab_login_info t2

on (t1.u_id=t2.u_id and t1.u_reg_dt>=? and t1.u_reg_dt<=?)

執(zhí)行計劃可能為：

Map：

由于是 join,所有的表都要進行查詢操作,并且為每張表打上自己的標簽,具體實施的時候可以加個表名字字段,在所有存儲節(jié)點上執(zhí)行

select u_id,u_name from tab_user_info t where u_reg_dt>=? and t1.u_reg_dt<=?

select u_id, login_product from tab_login_info t

Shuffle：這種情況下由于需要按照 u_id 進行數(shù)據(jù)洗牌,考慮到 u_id 的唯一值比較多,所以各個存儲節(jié)點上需要按照 u_id 進行劃分,例如有 N 個計算節(jié)點,那么按照(最大 u_id- 最小 u_id)/N 平均劃分,將不同存儲節(jié)點上的同一范圍的 u_id,劃分到同一個計算節(jié)點上.

Reduce：

select t1.u_id,t1.u_name,t2.login_product

from tab_user_info t1 join tab_login_info t2

on (t1.u_id=t2.u_id)

子查詢

由于子查詢可以分解成具有依賴關(guān)系的不包含子查詢的 SQL,所以生成的執(zhí)行計劃,就是多個 SQL?的執(zhí)行計劃按照一定的依賴關(guān)系進行依次執(zhí)行.

與已有系統(tǒng)的區(qū)別和優(yōu)點

• 相比 hdfs 來說,數(shù)據(jù)的分布是有規(guī)則的,hdfs 需要啟動之后執(zhí)行命令去查詢文件具體在什么節(jié)點上；元數(shù)據(jù)的較小,記錄規(guī)則即可,管理成本較低,在啟動速度方面很快.
• 數(shù)據(jù)是放在數(shù)據(jù)庫中的,可以很好的使用索引和數(shù)據(jù)庫本身的緩存機制,大大提高數(shù)據(jù)查詢的效率,特別是在大量數(shù)據(jù)的情況下,利用索引查詢返回少量的數(shù)據(jù).
• 數(shù)據(jù)可以進行刪除和修改,這在基于 hdfs 的系統(tǒng)中一般比較麻煩和低效.
• 在計算方面,和 MapReduce ?或者其他的分布式計算框架(如 spark)并沒有本質(zhì)的區(qū)別(需要進行 shuffle).但是由于數(shù)據(jù)的分布是有規(guī)則的,在有些地方可以做的更好,在分布式全文索引體現(xiàn).
• 由于線上系統(tǒng)一般使用數(shù)據(jù)庫作為最終的存儲位置,而把數(shù)據(jù)庫同步到 hdfs 中是比較麻煩的,并且對于有刪除和更新的情況,同步數(shù)據(jù)麻煩低效,速度較慢；相比之下,這個方案可以使用數(shù)據(jù)庫本身提供的鏡像復(fù)制功能來同步,基本沒有額外的麻煩和低效的工作.
• 基于以上,可以把線上系統(tǒng)(主系統(tǒng))和線下的數(shù)據(jù)分析挖掘(從系統(tǒng))做成統(tǒng)一的方案, 參見應(yīng)用架構(gòu)圖.

應(yīng)用場景 ?

最后列舉一些應(yīng)用場景

作者：江和慧,目前就職稅友軟件,曾經(jīng)任職網(wǎng)易,專注數(shù)據(jù)處理領(lǐng)域MySQL、Hadoop,分布式數(shù)據(jù)庫

文章來自微信公眾號：高效開發(fā)運維

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/2738.html