TiDB 在用電信息采集系統(tǒng)的應(yīng)用與實(shí)踐

朱霖，厲文婕，陳輝

（江蘇方天電力技術(shù)有限公司，南京211000）

0 引言

用電信息采集系統(tǒng)服務(wù)于全省電力用戶，是一個(gè)通過前置采集終端自動(dòng)采集電力用戶的用電數(shù)據(jù)，并在后期進(jìn)行多維度的用電分析、數(shù)據(jù)發(fā)布展示和實(shí)時(shí)監(jiān)控的系統(tǒng)。

目前，用采系統(tǒng)每日的采集分析數(shù)據(jù)增量達(dá)到200GB。隨著用采系統(tǒng)自身業(yè)務(wù)應(yīng)用的不斷深化改造，對(duì)數(shù)據(jù)的精度、范圍和質(zhì)量要求也會(huì)不斷的提高，例如，改造配變終端15 分鐘間隔的準(zhǔn)實(shí)時(shí)信息數(shù)據(jù)采集，不僅提高了數(shù)據(jù)精度為15 分鐘，而且還補(bǔ)充采集了電壓、電流等曲線數(shù)據(jù)。用采系統(tǒng)正面臨著海量數(shù)據(jù)存儲(chǔ)變慢、不易擴(kuò)展，核心業(yè)務(wù)數(shù)據(jù)分析效率降低等壓力。

為了應(yīng)對(duì)日益增加的海量用電信息數(shù)據(jù)，實(shí)現(xiàn)高效的挖掘分析和便捷的可擴(kuò)展存儲(chǔ)能力，優(yōu)化解決現(xiàn)有架構(gòu)內(nèi)的瓶頸和問題顯得十分必要。

用采系統(tǒng)目前使用的Oracle RAC 數(shù)據(jù)庫(kù)，與分布式數(shù)據(jù)庫(kù)相比，后者存在兩點(diǎn)明顯的優(yōu)勢(shì)：1）分布式數(shù)據(jù)庫(kù)支持的節(jié)點(diǎn)多，增加節(jié)點(diǎn)后性能基本為線性增加；Oracle RAC 支持的節(jié)點(diǎn)數(shù)少，增加節(jié)點(diǎn)性能不是線性增加。2）Oracle 最大的問題在于shared everything 的架構(gòu)，導(dǎo)致I/O 的處理能力有限，而且擴(kuò)展能力也有限；而分布式數(shù)據(jù)庫(kù)是shared nothing 架構(gòu)，在I/O 處理能力和擴(kuò)展能力上要優(yōu)于前者[1]。

TiDB 是一款開源的HTAP 的分布式數(shù)據(jù)庫(kù)。它結(jié)合了傳統(tǒng)的RDBMS 和NoSQL 的最佳特性，其優(yōu)勢(shì)在于兼容MySQL，支持無限的水平擴(kuò)展，具備強(qiáng)一致性和高可用性。目前已經(jīng)被500 余家不同行業(yè)的企業(yè)應(yīng)用在實(shí)際生產(chǎn)環(huán)境中。

綜上所述，為了優(yōu)化和解決用電信息采集系統(tǒng)中存在的數(shù)據(jù)存儲(chǔ)擴(kuò)展問題和海量數(shù)據(jù)實(shí)時(shí)分析應(yīng)用的問題。我們嘗試在不改變現(xiàn)有系統(tǒng)架構(gòu)應(yīng)用的前提下，把TiDB 分布式數(shù)據(jù)庫(kù)引入到用電信息采集系統(tǒng)內(nèi)，逐步觀察、分析及驗(yàn)證其實(shí)際適用范圍和效果情況。

1 TiDB應(yīng)用部署介紹

如圖1 所示是TiDB 的部署示意圖[2]。本次搭建TiDB 集群的測(cè)試環(huán)境共規(guī)劃了12 個(gè)節(jié)點(diǎn)。

詳細(xì)清單信息如表1 所示。

圖1 TiDB部署示意圖

表1 TiDB 集群測(cè)試環(huán)境清單

1.1 TiDB組件

我們應(yīng)用了TiDB 集群三個(gè)核心組件：TiDB Serv?er、PD Server 和TiKV Server。下面將針對(duì)各組件功能進(jìn)行介紹。

（1）TiDB Server

負(fù)責(zé)SQL 邏輯處理。它是無狀態(tài)的，支持水平擴(kuò)展，本身不存儲(chǔ)數(shù)據(jù)，只負(fù)責(zé)接收SQL 請(qǐng)求(遵守MySQL 協(xié)議)，并做解析處理，獲取到請(qǐng)求的SQL 后進(jìn)行語(yǔ)法解析和驗(yàn)證、執(zhí)行計(jì)劃的制定和優(yōu)化等工作。

與PD 交互可以獲取到所需數(shù)據(jù)在TiKV 中的實(shí)際位置，同時(shí)也能獲取到全局唯一的事務(wù)ID，以便事務(wù)的維護(hù)。

與TiKV 交互可以獲取和修改實(shí)際數(shù)據(jù)，并最終返回結(jié)果。

需要注意的是，在當(dāng)前3.0 版中，事務(wù)默認(rèn)開啟的是樂觀鎖模式，所有修改操作在事務(wù)提交前均只影響到TiDB Server，提交成功后才會(huì)持久化到TiKV 中。

（2）PD Server

負(fù)責(zé)整個(gè)集群的調(diào)度和管理。它收集信息的來源分為2 類，一類是每個(gè)Tikv 節(jié)點(diǎn)定期匯報(bào)節(jié)點(diǎn)整體信息；另一類是每個(gè)Raft Group 的Leader 定期匯報(bào)的Re?gion 信息。通過對(duì)這些信息的收集整理，PD 可以做到管理維護(hù)TiKV 存儲(chǔ)集群中的元信息以及控制TiKV進(jìn)行調(diào)度和負(fù)載均衡。另外，其還能為TiDB Server 提供全局唯一且遞增的事務(wù)ID。

（3）TiKV Server

負(fù)責(zé)存儲(chǔ)數(shù)據(jù)，是一個(gè)提供事務(wù)的分布式Key-Value 存儲(chǔ)引擎。以Region 為基本單位，每個(gè)節(jié)點(diǎn)上會(huì)有多個(gè)Region，每個(gè)Region 會(huì)存儲(chǔ)一段Key 區(qū)間的Key-Values 數(shù)據(jù)。默認(rèn)情況下，一個(gè)Region 有3 個(gè)副本，分別存在于3 個(gè)節(jié)點(diǎn)上。

TiKV 對(duì)磁盤I/O 要求較高。TiKV 硬盤大小建議不超過500G，以防止硬盤損害時(shí)，數(shù)據(jù)恢復(fù)耗時(shí)過長(zhǎng)。

值得說明的是，TiKV 并沒有真正將數(shù)據(jù)寫入磁盤以持久化，而只是將數(shù)據(jù)存于RocksDB 中，具體寫入磁盤是由RocksDB 負(fù)責(zé)的。

（4）TiSpark

負(fù)責(zé)處理解決復(fù)雜的OLAP 需求。TiSpark 整合了Spark Catalyst 引擎, 并且可以高效的讀取TiKV 中的數(shù)據(jù)，結(jié)合索引實(shí)現(xiàn)高速查詢。我們目前將其用于各類報(bào)表的統(tǒng)計(jì)分析。

TiSpark 在寫入TiKV 時(shí)，還不支持直接寫入，需要通過TiDB Server 寫入。

1.2 中控機(jī)

我們配置一臺(tái)服務(wù)器主機(jī)作為中控機(jī)，它可以控制TiDB 集群環(huán)境中的其他主機(jī)設(shè)備，具有最高權(quán)限。整個(gè)集群的部署、參數(shù)配置和版本升級(jí)都可以通過中控機(jī)操作來完成。

1.3 數(shù)據(jù)服務(wù)接口

本文將TiDB 定位成一個(gè)可分析的綜合性的查詢服務(wù)平臺(tái)。

為了方便用采系統(tǒng)的開發(fā)人員和測(cè)試人員訪問請(qǐng)求TiDB 數(shù)據(jù)庫(kù)服務(wù)而單獨(dú)研發(fā)了一套數(shù)據(jù)服務(wù)接口。此接口服務(wù)可以友好地協(xié)助初學(xué)者使用TiDB 數(shù)據(jù)庫(kù)，還可以統(tǒng)一且高效的監(jiān)控和管理所有的數(shù)據(jù)請(qǐng)求服務(wù)。

2 TiDB比較好的特性

支持SQL 標(biāo)準(zhǔn)：TiDB 支持SQL 標(biāo)準(zhǔn)，故對(duì)于已有的SQL 語(yǔ)句可以在語(yǔ)法適量的修改下實(shí)現(xiàn)原有功能。TiDB 對(duì)MySQL 兼容性很好，支持MySQL 傳輸協(xié)議和大多數(shù)語(yǔ)法，致使大多數(shù)情況下無需修改代碼即可從MySQL 輕松遷移至TiDB。

水平彈性擴(kuò)展：TiDB 支持節(jié)點(diǎn)的擴(kuò)容和縮容。通過簡(jiǎn)單地新增TiDB Server 節(jié)點(diǎn)即可實(shí)現(xiàn)計(jì)算能力的提升，新增TiKV Server 節(jié)點(diǎn)即可實(shí)現(xiàn)存儲(chǔ)容量的擴(kuò)容。如此便可以輕松應(yīng)對(duì)高并發(fā)、海量數(shù)據(jù)的應(yīng)用場(chǎng)景。

支持分布式事務(wù)：TiDB 支持在節(jié)點(diǎn)間進(jìn)行ACID事務(wù)。

運(yùn)行穩(wěn)定性高：在不出現(xiàn)大規(guī)模的節(jié)點(diǎn)故障或不丟失大多數(shù)副本的前提下，可以實(shí)現(xiàn)故障的自動(dòng)恢復(fù)，無需人工介入。

3 數(shù)據(jù)遷移與同步

用采系統(tǒng)使用的是Oracle 數(shù)據(jù)庫(kù)，無法方便地使用TiDB 官方提供的Syncer 工具進(jìn)行數(shù)據(jù)的遷移同步。所以，我們選用Oracle 的GoldenGate 產(chǎn)品，用來做數(shù)據(jù)的增量同步和全量遷移。同步。

由于當(dāng)前應(yīng)用場(chǎng)景不多，數(shù)據(jù)的同步規(guī)模不大，同步數(shù)據(jù)傳輸?shù)姆逯邓俣戎挥?Mb/s，且數(shù)據(jù)延遲不超過1 分鐘。

4 應(yīng)用場(chǎng)景簡(jiǎn)介

4.1 場(chǎng)景1：離線電表日電量計(jì)算

電表日電量是指全省3000 多萬用電用戶下所有電表的每日的用電量計(jì)算，需要用到用電用戶相關(guān)信息、表計(jì)相關(guān)信息和每日的采集數(shù)據(jù)。主站每日采集并存儲(chǔ)到Oracle 庫(kù)的全省用電用戶日末凍結(jié)示數(shù)約3400 萬條，通過OGG 方式同步至TiDB。

離線電量計(jì)算可以分為三步，第一步是根據(jù)凍結(jié)示數(shù)進(jìn)行日電量計(jì)算；第二步是計(jì)算結(jié)果的清理；第三步是異常電量數(shù)據(jù)的合理性替代。

我們使用TiSpark 來實(shí)現(xiàn)離線電量的計(jì)算邏輯，并與實(shí)際業(yè)務(wù)電量數(shù)據(jù)進(jìn)行比對(duì)，確保了數(shù)據(jù)的完整性和正確性。

執(zhí)行耗時(shí)比如表2 所示。

表2 執(zhí)行耗時(shí)對(duì)比

圖2 OGG同步數(shù)據(jù)示意圖

OGG 首先在源端Oracle 數(shù)據(jù)庫(kù)以一定間隔讀取REDO 日志，獲得變更信息。然后生成Trail 文件，再同樣以一定間隔的將本地的Trail 隊(duì)列發(fā)送至目標(biāo)端，由目標(biāo)端接收后，從Trail 文件生成SQL 語(yǔ)句在TiDB 中執(zhí)行[3]。

在用采系統(tǒng)中為配合在TiDB 中進(jìn)行業(yè)務(wù)功能和性能測(cè)試，共選用了十多張檔案表和數(shù)據(jù)表，合計(jì)超過30 億條數(shù)據(jù)做全量遷移和每日接近1 億條數(shù)據(jù)做增量

由此可見，在大量數(shù)據(jù)的計(jì)算分析上，TiDB 要比Oracle 數(shù)據(jù)庫(kù)快很多。具體表現(xiàn)在離線電表日電量計(jì)算上總體快了約8 倍。

4.2 場(chǎng)景2：采集成功率統(tǒng)計(jì)

采集成功率統(tǒng)計(jì)是反映全省數(shù)據(jù)采集質(zhì)量的一個(gè)重要指標(biāo)。我們按地區(qū)、分高低壓、終端的型號(hào)和廠家等維度來分析統(tǒng)計(jì)各類數(shù)據(jù)項(xiàng)(電能示值類、需量類)的當(dāng)日采集完成情況。

目前，用采系統(tǒng)中該統(tǒng)計(jì)功能在Oracle 數(shù)據(jù)庫(kù)中以多個(gè)存儲(chǔ)過程，制定JOB 任務(wù)鏈的方式，每天定時(shí)執(zhí)行3 次，每次平均耗時(shí)60 分鐘，生成基礎(chǔ)信息、統(tǒng)計(jì)信息和失敗清單信息累計(jì)近千萬條數(shù)據(jù)。

我們針對(duì)存儲(chǔ)過程中的SQL 語(yǔ)句逐個(gè)進(jìn)行改造后遷移至TiSpark 中執(zhí)行。從運(yùn)行效果上來看，執(zhí)行效率明顯提升，平均耗時(shí)20 分鐘就能分析統(tǒng)計(jì)完成。

4.3 場(chǎng)景3：線損模塊數(shù)據(jù)查詢

在用采系統(tǒng)頁(yè)面功能中選取了線損模塊下的統(tǒng)計(jì)查詢、考核單元管理、臺(tái)區(qū)統(tǒng)計(jì)視圖等功能，在測(cè)試環(huán)境下做SQL 語(yǔ)句改造和必要的邏輯拆分工作，總共涉及近150 條SQL 語(yǔ)句。

我們通過用采系統(tǒng)應(yīng)用服務(wù)調(diào)用數(shù)據(jù)服務(wù)接口，然后訪問TiDB 進(jìn)行分析處理并返回結(jié)果集給應(yīng)用服務(wù)。

SQL 改造中會(huì)有執(zhí)行計(jì)劃與原Oracle 的執(zhí)行計(jì)劃差別較大的情況，我們會(huì)嘗試重新收集統(tǒng)計(jì)信息、改變表關(guān)聯(lián)順序、篩選條件格式和位置等，最終達(dá)到了理想的查詢效率。

5 實(shí)踐中遇到的問題

TiDB 的應(yīng)用已經(jīng)有一段時(shí)間，在集群部署、環(huán)境參數(shù)配置以及業(yè)務(wù)測(cè)試應(yīng)用階段或多或少遇到了一些問題。這些問題有的容易解決，有的尋求了TiDB 廠家的支持。

（1）最初部署開發(fā)環(huán)境時(shí)，PD 只提供了2 個(gè)節(jié)點(diǎn)，集群的正常使用不受影響，但在調(diào)整環(huán)境參數(shù)需要集群滾動(dòng)升級(jí)時(shí)遇到了報(bào)錯(cuò)，問題的原因很簡(jiǎn)單，就是2個(gè)PD 節(jié)點(diǎn)升級(jí)，其中1 個(gè)節(jié)點(diǎn)下線后還未及時(shí)上線，另1 個(gè)節(jié)點(diǎn)暫時(shí)無法獲取到PD 信息而報(bào)錯(cuò)，只要再擴(kuò)容一個(gè)PD 節(jié)點(diǎn)就解決了。官方文檔建議配置奇數(shù)3個(gè)以上的PD，當(dāng)初沒有嚴(yán)格來做而埋下的隱患。

（2）OGG 數(shù)據(jù)同步時(shí)，遇到過TiDB 版本不支持的問題，通過升級(jí)版本，由V2.1.12 升級(jí)至當(dāng)前使用的V3.0.2 得到解決。

（3）SQL 語(yǔ)句改造時(shí)，Oracle 與MySQL 語(yǔ)句有些地方差別還是很大的，例如with..as..臨時(shí)表寫法在MySQL 中不支持；Oracle 中的空字符串’’就是null,而MySQL 中是區(qū)分null 和’’等。對(duì)于我們熟悉Oracle開發(fā)的人員改用MySQL 實(shí)現(xiàn)需要時(shí)間過渡。

（4）TiDB 中執(zhí)行SQL 查詢，偶爾會(huì)遇到執(zhí)行變慢的問題，一般都是執(zhí)行計(jì)劃改變引起，需要重新收集統(tǒng)計(jì)信息，相較與Oracle 的執(zhí)行計(jì)劃還不夠穩(wěn)定。

（5）我們目前生產(chǎn)環(huán)境TiDB 架構(gòu)部署存在一些問題，結(jié)合我們實(shí)際的硬件配置信息，為了獲得更多的數(shù)據(jù)吞吐和性能，TiDB 廠家建議我們將TiKV 集群的單機(jī)單實(shí)例部署改為單機(jī)三實(shí)例部署。這樣可以在整體存儲(chǔ)能力不變的前提下，提升KV 節(jié)點(diǎn)上磁盤I/O 使用率。

6 結(jié)語(yǔ)

結(jié)合我們的實(shí)際現(xiàn)狀，我們現(xiàn)階段主要將TiDB 定位為對(duì)外提供查詢服務(wù)的平臺(tái)。后期隨著應(yīng)用的深入，也會(huì)不斷擴(kuò)展其應(yīng)用范圍，在其上進(jìn)行更多的離線計(jì)算和業(yè)務(wù)分析OLAP 場(chǎng)景。