導(dǎo)讀：數(shù)據(jù)總線（DBus）專注于數(shù)據(jù)的實時采集與實時分發(fā)，可以對IT系統(tǒng)在業(yè)務(wù)流程中產(chǎn)生的數(shù)據(jù)進(jìn)行匯聚，經(jīng)過轉(zhuǎn)換處理后成為統(tǒng)一JSON的數(shù)據(jù)格式（UMS），提供給不同數(shù)據(jù)使用方訂閱和消費，充當(dāng)數(shù)倉平臺、大數(shù)據(jù)分析平臺、實時報表和實時營銷等業(yè)務(wù)的數(shù)據(jù)源。

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)建站！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、小程序制作、集團企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了四平免費建站歡迎大家使用！

本文從數(shù)據(jù)分片的角度出發(fā)，具體介紹DBus在數(shù)據(jù)采集的過程中，運用了什么樣的分片策略和分片原理，以及過程中遇到的問題及解決方案。

一、分片策略

對于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，DBus通過提供全量數(shù)據(jù)拉取和增量數(shù)據(jù)采集兩種途徑滿足用戶數(shù)據(jù)采集需求。DBus數(shù)據(jù)抽取流程如下圖所示(以MySQL為例)：

全量數(shù)據(jù)采集的主要原理是：根據(jù)主鍵、唯一索引、索引等信息，確定分片列。之所以分片列要根據(jù)主鍵、唯一索引、索引等選擇，是因為這些列的數(shù)據(jù)在庫里建立了良好索引，能提升數(shù)據(jù)掃描的效率。

根據(jù)選定的分片列，對數(shù)據(jù)進(jìn)行拆片，確定每片數(shù)據(jù)的上下界，然后根據(jù)每片上下界，以6~8左右的并發(fā)度，進(jìn)行數(shù)據(jù)拉取。（6~8左右的并發(fā)度是經(jīng)大量測試獲得的經(jīng)驗值。實驗顯示，6~8左右的并發(fā)度既不會對源庫形成過高壓力，又能最大限度提升全量數(shù)據(jù)拉取的效率。）

DBus分片策略示意圖：

DBus拉取策略示意圖：

那么，DBus支持什么類型的列作為分片列？不同類型的分片列，分片策略如何呢?

分片策略這塊，DBus借鑒了Sqoop的分片設(shè)計，支持以下類型的列作為分片列：

• BigDecimal/numeric
• Boolean
• Date/time/timestamp
• Float/double
• Integer/smallint/long
• Char/Varchar/Text/NText

拆片原理大體一致，都是根據(jù)分片列的最大最小值，以及設(shè)定的每片大小，進(jìn)行每一分片上下界的計算和確定。但具體實現(xiàn)細(xì)節(jié)差異很大。尤其是Text/NText類型，借鑒、應(yīng)用的過程中發(fā)現(xiàn)一些問題，我們進(jìn)行了一些調(diào)整和優(yōu)化。

本文主要和大家分享一下遇到的坑和我們的解決辦法。

二、分片原理

2.1 數(shù)字類型分片列

讓我們先以最簡單、明了的數(shù)字類型分片列為例介紹分片原理。

如前所述，我們會按照主鍵->唯一索引->索引的優(yōu)先級確定分片列。如果表有主鍵，我們以主鍵列為分片列；如果沒有主鍵，有唯一索引，我們以唯一索引列為分片列……以此類推。如果找到的鍵或索引是聯(lián)合主鍵或聯(lián)合索引，我取其中的第一列作為分片列。如果沒有找到任何合適的列作為分片列，則不分片，所有數(shù)據(jù)作一片進(jìn)行拉?。o法享受并發(fā)拉取帶來的效率提升）。

首先要根據(jù)一定的規(guī)則選取某一列作為分片列，然后根據(jù)分片列的最大最小值，以及設(shè)定的每片大小，進(jìn)行每一分片上下界的計算和確定：

1)獲取切分字段的MIN()和MAX()

• "SELECT MIN(" + qualifiedName + "),
• MAX(" + qualifiedName + ") FROM (" + query + ") AS " + alias

2)根據(jù)MIN和MAX不同的類型采用不同的切分方式

• 支持有Date, Text, Float, Integer，Boolean, NText, BigDecimal等等。
• 以數(shù)字為例子：
• 步長=（最大值-最小值）/mapper個數(shù)
• 生成的區(qū)間為
• [最小值，最小值+步長)
• [最小值+步長，最小值+2*步長)
• ...
• [最大值-步長，最大值]
• 生成的condition類似：
• splitcol >= min and splitcol < min+splitsize

實現(xiàn)代碼片段如下：

2.2 字符串類型分片列

對于分片列類型為數(shù)字類型的情況，很好理解。

如果分片列類型為char/varchar等字符串類型呢？每一片的上下界該如何計算？

原理還是一樣的：查出該列的最小、最大值，根據(jù)每片大小，計算每片分界點，生成每一片的上下界。

技術(shù)細(xì)節(jié)上不一樣的地方是：每片分界點/上下界的計算。

分片列類型為int，min 為2 ，max為10， shard size為3，分片很好理解：

Split[2,5)

Split[5,8)

Split[8,10]

如果分片列類型為varchar(128), min 為abc，max為 xyz，怎么計算拆片點呢？

Sqoop的分片機制是通過將“字符串”映射為“數(shù)字”，根據(jù)數(shù)字計算出分片上下界，然后將以數(shù)字表達(dá)的分片上下界映射回字符串，以此字符串作為分片的上/下界。如下所示：

• 字符串映射為數(shù)值 （a/65536 + b/65536^2 + c/65536^3）
• 數(shù)值split 計算分割點，生成插值
• 插值映射回會字符串

然而，在實際應(yīng)用中，上述分片機制碰到各種問題，下面將我們碰到和解決這一系列問題的經(jīng)驗分享如下。

三、分片經(jīng)驗

3.1 首先，根據(jù)上面的分片進(jìn)行數(shù)據(jù)的拉取，有卡死情況。

1)現(xiàn)象

• 無錯誤輸出，但全量抽取進(jìn)程輸出一部分分片后卡死，無任何輸出
• 經(jīng)過檢查，發(fā)現(xiàn)30秒后， storm worker被莫名其妙重啟了？

2)分析

• nimbus.task.timeout.secs的缺省時間為30秒，nimbus發(fā)現(xiàn)worker無響應(yīng)，就重啟動worker
• 為什么worker無響應(yīng)？
• 字符串的插值是任意可能的，例如：
• splitcol >= ‘a(chǎn)bc’ and splitcol < ‘fxxx’xx’

3)解決辦法

• 使用binding變量方式，而不是拼接字符串方式
• Select * from T splitcol >= ？and splitcol < ？

3.2 更新后碰到新問題，報Illegal mix of collations異常。

1)現(xiàn)象

• 顯示exception：[ERROR] Illegal mix of collations (utf8_general
  -_ci,IMPLICIT) and (utf8mb4_general_ci,COERCIBLE) for operation '<'
• java.sql.SQLException: Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8mb4_general_ci,COERCIBLE) for operation '<‘

2)分析

• 什么是Utf8和utf8mb4？
• utf8 是 Mysql 中的一種字符集，只支持最長三個字節(jié)的 UTF-8字符
• 三個字節(jié)的全部編碼空間： 000000~ 00FFFF
• MySQL在5.5.3之后增加了這個utf8mb4的編碼，mb4就是most bytes 4的意思，專門用來兼容四字節(jié)的unicode
• 四個字節(jié)新增的編碼空間：010000~10FFFF
• 似乎生成了utf8mb4的碼的字符串， splitcol和生成的插值字符串，屬于不同的字符集,無法進(jìn)行比較，Splitcol屬于utf8字符集，而插值屬于utf8mb4字符集

3)檢查發(fā)現(xiàn)

• character_set_server：utf8mb4
• character_set_database/table : utf8
• Connection url: utf8 = utf8mb4

4)Unicode

• 代碼空間：總共有1,114,112個代碼點，編號從0x0到0x10FFFF
• 代碼平面：Unicode分成了17個代碼平面（Code Plane），編號為#0到#16。每個代碼平面65,536個代碼點

5)UTF16

• 從U+0000至U+FFFF基本多語言平面（BMP）
• 包含了最常用的字符
• 實際字符需要除去代理區(qū)，也就是從U+0000至U+D7FF 和 U+E000 至U+FFFF。
• UTF8
• 從U+D800到U+DFFF的碼位（代理區(qū)）
• Unicode標(biāo)準(zhǔn)規(guī)定U+D800..U+DFFF的值不對應(yīng)于任何字符

• 從U+10000到U+10FFFF的補充平面（Supplementary Planes）
• 在UTF-16中被編碼為一對16比特長的碼元（即32bit，4Bytes），稱作 code units called a 代理對（surrogate pair）
• 第一個WORD的高6位是110110，第二個WORD的高6位是110111?？梢?，
• 第一個WORD的取值范圍（二進(jìn)制）是11011000 00000000到11011011 11111111，即0xD800-0xDBFF。

• 第二個WORD的取值范圍（二進(jìn)制）是11011100 00000000到11011111 11111111，即0xDC00-0xDFFF。

• Emoji字符的例子：

• 對應(yīng)Unicode 是\u1F601
• 對應(yīng)的utf16 碼是2個word，即：0xd83d,　0xde01，對應(yīng)java string length為2.

根據(jù)上述字符集只是，我們找到了問題癥結(jié)所在：

• bigDecimalToString()生成的插值:
• 無法保證是否會落入U+D800到U+DFFF的代理區(qū)
• 無法保證連續(xù)兩個word滿足代理對的標(biāo)準(zhǔn)，可能會被認(rèn)定為亂碼
• 代理區(qū)間占整個U+FFFF區(qū)間很小

6)解決方案

• 回避生成在代理區(qū)的字符，用合法的BMP區(qū)字符替代
• if (0xD800 <= codePoint && codePoint <= 0xDFFF) {
• codePoint = 0xD3FF;
• }
• 可能的缺點是：分片不那么均勻，但由于代理區(qū)占整個U+FFFF區(qū)間很小，影響不大

↓↓↓

3.3 拉取總數(shù)不對

解決字符集亂碼問題后，能正常拉取數(shù)據(jù)，但總數(shù)不對。

1)現(xiàn)象

• 沒有錯誤，全量抽取完成，但數(shù)量不對，整個表只有300萬，實際抽取了500萬？

2)分析

• 程序并沒有錯，存在重復(fù)數(shù)據(jù)
• utf8_genera_ci不區(qū)分大小寫，ci為case insensitive的縮寫，即大小寫不敏感
• utf8_bin將字符串中的每一個字符用二進(jìn)制數(shù)據(jù)存儲，區(qū)分大小寫
• 例如：SELECT * FROM table WHERE txt = 'a'
• 那么在utf8_bin中你就找不到 txt = 'A', 而 utf8_general_ci 則可以.

3)解決方案

• 應(yīng)該使用utf8_bin進(jìn)行查詢

類似： SELECT * FROM tableName WHERE binary columnName = 'a';

至此，對char、varchar類型字符串分片列的分片，也有了很好的支持。