[[197453]]

設(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)中的一些概念做些說明

增刪改操作

當(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，所有的表都要進行查詢操作，并且為每張表打上自己的標(biāo)簽，具體實施的時候可以加個表名字字段，在所有存儲節(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)用場景