過去,TiDB 由於不支持存儲過程、大事務的使用也存在一些限制,使得在 TiDB 上進行一些複雜的數據批量處理變得比較複雜。
TiDB 在面向這種超大規模數據的批處理場景,其能力也一直在演進,其複雜度也變得越來越低:
○ 從 TiDB 5.0 開始,TiFlash 支持 MPP 並行計算能力,在大批量數據上進行聚合、關聯的查詢性能有了極大的提升
○ 到了 TiDB 6.1 版本,引入了 BATCH DML ( https://docs.pingcap.com/zh/tidb/stable/non-transactional-dml ) 功能,該功能可以將一個大事務自動拆成多個批次去處理,在單表基礎上進行大批量更新、刪除、寫入時能夠大幅提升處理效率,同時避免了大事務所產生的一些影響。
○ 而到了 7.1 LTS 版本,正式 GA 了 TiFlash 查詢結果物化 ( https://docs.pingcap.com/zh/tidb/stable/tiflash-results-materialization#tiflash-查詢結果物化 ) 的功能,使得 insert/replace into ... select ... 這種操作中的複雜 select 能夠利用 TiFlash MPP 並行處理的能力,大幅提升了這種操作的處理性能。
○ 前不久剛發佈的 7.5 LTS,正式 GA 了一個 IMPORT INTO ( https://docs.pingcap.com/zh/tidb/stable/sql-statement-import-into#import-into ) 的功能,該功能將原本 tidb-lightning 的物理導入能力集成到 TiDB 計算節點上,使用一條 SQL 語句就可以完成大批量數據的導入,大幅簡化了超大規模數據寫入時的複雜度。
TiDB 上之前有哪些批處理方案
- INSERT INTO ... SELECT 完成查詢和寫入
● 現狀:適用於小批量數據處理,性能較高
● 挑戰:大批量數據寫入時,會產生大事務,消耗內存較高
● 說明:寫入+單表查詢場景可使用 BATCH DML 功能自動拆批
- 針對 INSERT INTO/INSERT INTO ... ON DUPLICATE .../REPLACE INTO 這些 SQL 使用批量接口執行,降低應用與數據庫之間的交互次數,提升批量寫入時的性能
● 現狀:在合適的拆批方案、表結構設計上,處理性能非常高
● 挑戰:編碼不合理、表結構設計不合理時,可能會遇到熱點問題,導致性能不佳
- 通過 ETL 和調度平臺提供的數據讀取和寫入能力實現大批量數據的處理
● 現狀:主流的 ETL 平臺,如 datax、spark、kettle 等,在合理表結構設計時,性能也比較高
● 挑戰:多線程並行寫入時,也有可能會遇到熱點問題
- 針對上游傳過來的 csv 文件的數據,使用 LOAD DATA 來完成批量數據的寫入,提升批量寫入時的性能
● 現狀:在對文件進行拆分+多線程並行後,處理性能非常高
● 挑戰:當 LOAD DATA 一個大文件時此時是大事務,導致性能不佳;多線程處理時也有可能遇到熱點問題,導致性能不佳
針對以上幾種批處理方案,以及最新推出的 IMPORT INTO 功能,我們開展了一次測試,探索哪種批處理方案效率最高,消耗資源更低,以及使用上更加簡單。
TiDB 中不同批處理方案的測試
1 測試環境
- TiDB 資源:3 臺 16VC/64GB 虛擬機 + 500GB SSD 雲盤(3500 IOPS + 250MB/S 讀寫帶寬)
a. TiDB 版本:TiDB V7.5.0 LTS
b. TiDB 組件:TiDB/PD/TiKV/TiFlash(混合部署)
- 存儲資源:8C/64GB 虛擬機 + 500GB SSD 雲盤(3500 IOPS + 250MB/S 讀寫帶寬)
● 存儲服務:NFS 服務、Minio 對象存儲
- 測試資源:8C/64GB 虛擬機 + 500GB SSD 雲盤(3500 IOPS + 250MB/S 讀寫帶寬)
● datax + Dolphin 調度/java 程序/dumpling、tidb-lightning 工具以及 MySQL 客戶端
2 測試場景
將大批量查詢結果快速寫入到目標表,既考驗查詢性能,同時也考驗批量寫入的性能。
2.1 查詢部分:多表關聯+聚合
基於 TPCH 100GB 數據,擴展 Q10 查詢中的字段和查詢範圍,返回 8344700 行數據。
select c_custkey,c_name,sum(l_extendedprice * (1 - l_discount)) as revenue,
c_acctbal,n_name,c_address,c_phone,c_comment,min(C_MKTSEGMENT),min(L_PARTKEY),
min(L_SUPPKEY,min(L_LINENUMBER),min(L_QUANTITY), max(L_TAX), max(L_LINESTATUS),
min(L_SHIPDATE), min(L_COMMITDATE), min(L_RECEIPTDATE), min(L_SHIPINSTRUCT),
max(L_SHIPMODE), max(O_ORDERSTATUS), min(O_TOTALPRICE), min(O_ORDERDATE),
max(O_ORDERPRIORITY), min(O_CLERK), max(O_SHIPPRIORITY),
@@hostname as etl_host,current_user() as etl_user,current_date() as etl_date
from
tpch.customer,tpch.orders,tpch.lineitem,tpch.nation
where
c_custkey = o_custkey and l_orderkey = o_orderkey
and o_orderdate >= date '1993-10-01' and o_orderdate < date '1994-10-01'
and l_returnflag = 'R' and c_nationkey = n_nationkey
group by
c_custkey,c_name,c_acctbal,c_phone,n_name,c_address,c_comment
order by c_custkey;
源表數據量
2.2 寫入:29 列,1 個主鍵+2 個索引
CREATE TABLE `tpch_q10` (
`c_custkey` bigint(20) NOT NULL,
`c_name` varchar(25) DEFAULT NULL,
`revenue` decimal(15,4) DEFAULT NULL,
...
`etl_host` varchar(64) DEFAULT NULL,
`etl_user` varchar(64) DEFAULT NULL,
`etl_date` date DEFAULT NULL,
PRIMARY KEY (`c_custkey`) /*T![clustered_index] CLUSTERED */,
KEY `idx_orderdate` (`o_orderdate`),
KEY `idx_phone` (`c_phone`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;
3 測試結果
4 測試分析
4.1 JAVA 程序使用 SQL 進行批處理
使用 JAVA 處理時,StreamingResult 流式讀取+多併發寫入方式能夠獲得非常好的性能。 強烈不建議使用 limit 分頁這種形式拆批 ,這種邏輯數據庫將執行 844 條查詢 SQL,效率極低,消耗的資源極高。同時 StreamingResult 這種流式讀取還可以使用於數據導出的場景,對比使用 limit 分頁處理,效率也更高。
在程序 4 中,將原本查詢 SQL 裏的 order by c_custkey 換成了 order by revenue desc 後,對性能也有一定影響,原因主要是多線程寫入時 RPC 開銷嚴重放大。
在程序 5 中,將原本查詢 SQL 中的 c_phone 換成 '132-0399-0111' as c_phone,模擬索引熱點。
4.2 LOAD DATA 方式
如果使用 LOAD DATA 要獲得比較高的性能,建議對單個文件進行拆分,同時 csv 中文件的順序建議與目標表主鍵順序一致,如一個 CSV 文件存儲 20000 行,再通過多線程並行來寫入,此時寫入性能也比較高。
如果僅 LOAD DATA 導入單個大文件,那麼性能較低,且消耗內存較高。
4.3 ETL+調度平臺方式
● 作業類型:datax(mysqlreader + mysqlwriter),簡單,效率一般
調度平臺執行 datax 作業:使用 mysqlreader 方式讀取時,默認就使用流式讀取,但是對於多表查詢的 query 時,寫入時無法併發
● 作業類型:shell + datax(txtfileread + mysqlwriter),較複雜,效率較高
○ 調度平臺執行 shell:使用 dumpling 導出成多個 csv 文件
○ 再調度 datax 作業:使用 txtfilereader + mysqlwriter,此時可以多線程併發寫入,效率較高
● 作業類型:**SQL,簡單高效**
○ 調度平臺執行 SQL:select ... into outfile
○ 調度平臺執行 SQL:import into
4.4 SELECT ... INTO OUTFILE 導出查詢結果(當前僅支持導出到文件系統)
該功能大家平時可能使用比較少,但該功能非常有價值,它可以高效的將數據一批導出、並且數據是完全一致的狀態,可以用於:
a. 批量數據處理:JAVA 程序可直接執行該 SQL 完成結果的導出
b. 在簡單的數據導出場景,使用導出 csv 替換原本 limit 處理邏輯,應用將查詢結果導出到一個共享 NFS/S3 對象存儲中,再讀取 NFS/S3 對象存儲中的 CSV,進行結果的處理,極大的降低了數據庫的壓力,同時性能將比之前使用 limit 分批處理更高。
4.5 IMPORT INTO 導入 CSV(當前支持 S3 協議對象存儲以及文件系統)
該功能 7.5.0 引入,極大的簡化了數據導入的難度,JAVA 程序可直接執行該 SQL 完成 CSV 數據的導入,在進行批處理時應用節點幾乎不需要消耗 CPU/內存資源。以下是使用示例:
IMPORT INTO test.tpch_q10 FROM '/mnt/nfs/test.tpch_q10.csv' with FIELDS_TERMINATED_BY='\t',split_file,thread=8;
需要注意的是:IMPORT INTO 導入過程中,不會產生日誌,所以針對需要 CDC 同步或 Kafka 分發的場景,該方案不適用。
5 測試小結
部分測試代碼示例 : https://github.com/Bowen-Tang/batch-samples
總結與展望
TiDB 7.5.0 引入的 IMPORT INTO 功能,結合 SELECT ... INTO OUTFILE、以及 NFS/對象存儲,讓 TiDB 上增加了一種更加簡單且非常高效的批處理方案,JAVA 應用程序處理時更加簡單,ETL 調度也更簡單。
以下是 TiDB 使用 IMPORT INTO、SELECT ... INTO OUTFILE 的架構示例:
I MPORT INTO 功能當前僅支持 CSV 導入,未來 TiDB 8.x 版本中 IMPORT INTO 將直接集成 IMPORT INTO ... SELECT ... 功能,極致簡化批處理操作,性能也更進一步提升(187 秒),敬請大家期待 :