關係型數據庫全表掃描分片詳解

導讀：數據總線（DBus）專一於數據的實時採集與實時分發，能夠對IT系統在業務流程中產生的數據進行匯聚，通過轉換處理後成爲統一JSON的數據格式（UMS），提供給不一樣數據使用方訂閱和消費，充當數倉平臺、大數據分析平臺、實時報表和實時營銷等業務的數據源。在上一篇關於DBus的文章中，咱們主要介紹了在DBus的設計中，表結構變動及其帶來的各類問題是如何處理的。在本文中，咱們則是從數據分片的角度出發，具體介紹DBus在數據採集的過程當中，運用了什麼樣的分片策略和分片原理，以及過程當中遇到的問題及解決方案。

1、分片策略

對於傳統的關係型數據庫，DBus經過提供全量數據拉取和增量數據採集兩種途徑知足用戶數據採集需求。DBus數據抽取流程以下圖所示(以mysql爲例)：

全量數據採集的主要原理是：根據主鍵、惟一索引、索引等信息，肯定分片列。之因此分片列要根據主鍵、惟一索引、索引等選擇，是由於這些列的數據在庫裏創建了良好索引，能提高數據掃描的效率。

根據選定的分片列，對數據進行拆片，肯定每片數據的上下界，而後根據每片上下界，以6~8左右的併發度，進行數據拉取。（6~8左右的併發度是經大量測試得到的經驗值。實驗顯示，6~8左右的併發度既不會對源庫造成太高壓力，又能最大限度提高全量數據拉取的效率。）

DBus分片策略示意圖：

DBus拉取策略示意圖：

那麼，DBus支持什麼類型的列做爲分片列？不一樣類型的分片列，分片策略如何呢?

分片策略這塊，DBus借鑑了Sqoop的分片設計，支持如下類型的列做爲分片列：

BigDecimal/numeric

Boolean

Date/time/timestamp

Float/double

Integer/smallint/long

Char/Varchar/Text/NText

拆片原理大致一致，都是根據分片列的最大最小值，以及設定的每片大小，進行每一分片上下界的計算和肯定。但具體實現細節差別很大。尤爲是Text/NText類型，借鑑、應用的過程當中發現一些問題，咱們進行了一些調整和優化。

本文主要和你們分享一下遇到的坑和咱們的解決辦法。

2、分片原理

1. 數字類型分片列

讓咱們先以最簡單、明瞭的數字類型分片列爲例介紹分片原理。

如前所述，咱們會按照主鍵->惟一索引->索引的優先級肯定分片列。若是表有主鍵，咱們以主鍵列爲分片列；若是沒有主鍵，有惟一索引，咱們以惟一索引列爲分片列……以此類推。若是找到的鍵或索引是聯合主鍵或聯合索引，我取其中的第一列做爲分片列。若是沒有找到任何合適的列做爲分片列，則不分片，全部數據做一片進行拉取（沒法享受併發拉取帶來的效率提高）。

首先要根據必定的規則選取某一列做爲分片列，而後根據分片列的最大最小值，以及設定的每片大小，進行每一分片上下界的計算和肯定：

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

• "SELECT MIN(" + qualifiedName + "),

• MAX(" + qualifiedName + ") FROM (" + query + ") AS " + alias

• 2 根據MIN和MAX不一樣的類型採用不一樣的切分方式

• 支持有Date, Text, Float, Integer，Boolean, NText, BigDecimal等等。

• 以數字爲例子：

• 步長=（最大值-最小值）/mapper個數

• 生成的區間爲

• [最小值，最小值+步長)

• [最小值+步長，最小值+2*步長)

• ...

• [最大值-步長，最大值]

• 生成的condition相似：

• splitcol >= min and splitcol < min+splitsize

實現代碼片斷以下：

2. 字符串類型分片列

對於分片列類型爲數字類型的狀況，很好理解。

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

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

技術細節上不同的地方是：每片分界點/上下界的計算。

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

Split[2,5) Split[5,8) Split[8,10]

若是分片列類型爲varchar(128), min 爲abc，max爲 xyz，怎麼計算拆片點呢？

Sqoop的分片機制是經過將「字符串」映射爲「數字」，根據數字計算出分片上下界，而後將以數字表達的分片上下界映射回字符串，以此字符串做爲分片的上/下界。以下所示：

1. 字符串映射爲數值 （a/65536 + b/65536^2 + c/65536^3）

2. 數值split 計算分割點，生成插值

3. 插值映射回會字符串

然而，在實際應用中，上述分片機制碰到各類問題，下面將咱們碰到和解決這一系列問題的經驗分享以下。

3、分片經驗

1. 首先，根據上面的分片進行數據的拉取，有卡死狀況。

• 現象

• 無錯誤輸出，但全量抽取進程輸出一部分分片後卡死，無任何輸出

• 通過檢查，發現30秒後， storm worker被莫名其妙重啓了？

• 分析

• nimbus.task.timeout.secs的缺省時間爲30秒，nimbus發現worker無響應，就重啓動worker

• 爲何worker無響應？

• 字符串的插值是任意可能的，例如：

• splitcol >= ‘abc’ and splitcol < ‘fxxx’xx’

• 解決辦法

• 使用binding變量方式，而不是拼接字符串方式

• Select * from T splitcol >= ？and splitcol < ？

2. 更新後碰到新問題，報Illegal mix of collations異常。

• 現象

• 顯示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 '<‘

• 分析

• 什麼是Utf8和utf8mb4？

• utf8 是 Mysql 中的一種字符集，只支持最長三個字節的 UTF-8字符

• 三個字節的所有編碼空間： 000000~ 00FFFF

• MySQL在5.5.3以後增長了這個utf8mb4的編碼，mb4就是most bytes 4的意思，專門用來兼容四字節的unicode

• 四個字節新增的編碼空間：010000~10FFFF

• 彷佛生成了utf8mb4的碼的字符串， splitcol和生成的插值字符串，屬於不一樣的字符集,沒法進行比較，Splitcol屬於utf8字符集，而插值屬於utf8mb4字符集

• 檢查發現：

• character_set_server：utf8mb4

• character_set_database/table : utf8

• Connection url: utf8 = utf8mb4

• Unicode

• 代碼空間：總共有1,114,112個代碼點，編號從0x0到0x10FFFF

• 代碼平面：Unicode分紅了17個代碼平面（Code Plane），編號爲#0到#16。每一個代碼平面65,536個代碼點

• UTF16

• 從U+0000至U+FFFF基本多語言平面（BMP）

• 包含了最經常使用的字符

• 實際字符須要除去代理區，也就是從U+0000至U+D7FF 和 U+E000 至U+FFFF。

• UTF8

• 從U+D800到U+DFFF的碼位（代理區）

• Unicode標準規定U+D800..U+DFFF的值不對應於任何字符

• 從U+10000到U+10FFFF的補充平面（Supplementary Planes）

• 在UTF-16中被編碼爲一對16比特長的碼元（即32bit，4Bytes），稱做 code units called a 代理對（surrogate pair）

• 第一個WORD的高6位是110110，第二個WORD的高6位是110111。可見，

• 第一個WORD的取值範圍（二進制）是11011000 00000000到11011011 11111111，即0xD800-0xDBFF。

• 第二個WORD的取值範圍（二進制）是11011100 00000000到11011111 11111111，即0xDC00-0xDFFF。

• Emoji字符的例子：

•

• 對應Unicode 是\u1F601

• 對應的utf16 碼是2個word，即：0xd83d,　0xde01，對應java string length爲2.

根據上述字符集只是，咱們找到了問題癥結所在：

• bigDecimalToString()生成的插值:

• 沒法保證是否會落入U+D800到U+DFFF的代理區

• 沒法保證連續兩個word知足代理對的標準，可能會被認定爲亂碼

• 代理區間佔整個U+FFFF區間很小

• 解決方案

• 迴避生成在代理區的字符，用合法的BMP區字符替代

• if (0xD800 <= codePoint && codePoint <= 0xDFFF) {

• codePoint = 0xD3FF;

• }

• 可能的缺點是：分片不那麼均勻，但因爲代理區佔整個U+FFFF區間很小，影響不大

↓↓↓

3. 拉取總數不對。

解決字符集亂碼問題後，能正常拉取數據，但總數不對。

• 現象

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

• 分析

• 程序並無錯，存在重複數據

• utf8_genera_ci不區分大小寫，ci爲case insensitive的縮寫，即大小寫不敏感

• utf8_bin將字符串中的每個字符用二進制數據存儲，區分大小寫

• 例如：SELECT * FROM table WHERE txt = 'a'

• 那麼在utf8_bin中你就找不到 txt = 'A', 而 utf8_general_ci 則能夠.

• 解決方案

• 應該使用utf8_bin進行查詢

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

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

來源：宜信技術學院    尹宏春