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

導讀：數據總線（DBus）專注于數據的實時采集與實時分發，可以對IT系統在業務流程中產生的數據進行匯聚，經過轉換處理后成為統一JSON的數據格式（UMS），提供給不同數據使用方訂閱和消費，充當數倉平臺、大數據分析平臺、實時報表和實時營銷等業務的數據源。

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

一、分片策略

對于傳統的關系型數據庫，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.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的分片機制是通過將“字符串”映射為“數字”，根據數字計算出分片上下界，然后將以數字表達的分片上下界映射回字符串，以此字符串作為分片的上/下界。如下所示：

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

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

三、分片經驗

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

1)現象

• 無錯誤輸出，但全量抽取進程輸出一部分分片后卡死，無任何輸出
• 經過檢查，發現30秒后， storm worker被莫名其妙重啟了？

2)分析

• nimbus.task.timeout.secs的缺省時間為30秒，nimbus發現worker無響應，就重啟動worker
• 為什么worker無響應？
• 字符串的插值是任意可能的，例如：
• splitcol >= ‘abc’ and splitcol < ‘fxxx’xx’

3)解決辦法

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

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

1)現象

• 顯示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 中的一種字符集，只支持最長三個字節的 UTF-8字符
• 三個字節的全部編碼空間： 000000~ 00FFFF
• MySQL在5.5.3之后增加了這個utf8mb4的編碼，mb4就是most bytes 4的意思，專門用來兼容四字節的unicode
• 四個字節新增的編碼空間：010000~10FFFF
• 似乎生成了utf8mb4的碼的字符串， splitcol和生成的插值字符串，屬于不同的字符集,無法進行比較，Splitcol屬于utf8字符集，而插值屬于utf8mb4字符集

3)檢查發現

• 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）
• 包含了最常用的字符
• 實際字符需要除去代理區，也就是從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區間很小

6)解決方案

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

↓↓↓

3.3 拉取總數不對

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

1)現象

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

2)分析

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

3)解決方案

• 應該使用utf8_bin進行查詢

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

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

作者：尹宏春

來源：宜信技術學院