TiDB 在用電信息采集系統的應用與實踐

朱霖，厲文婕，陳輝

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

0 引言

用電信息采集系統服務于全省電力用戶，是一個通過前置采集終端自動采集電力用戶的用電數據，并在后期進行多維度的用電分析、數據發布展示和實時監控的系統。

目前，用采系統每日的采集分析數據增量達到200GB。隨著用采系統自身業務應用的不斷深化改造，對數據的精度、范圍和質量要求也會不斷的提高，例如，改造配變終端15 分鐘間隔的準實時信息數據采集，不僅提高了數據精度為15 分鐘，而且還補充采集了電壓、電流等曲線數據。用采系統正面臨著海量數據存儲變慢、不易擴展，核心業務數據分析效率降低等壓力。

為了應對日益增加的海量用電信息數據，實現高效的挖掘分析和便捷的可擴展存儲能力，優化解決現有架構內的瓶頸和問題顯得十分必要。

用采系統目前使用的Oracle RAC 數據庫，與分布式數據庫相比，后者存在兩點明顯的優勢：1）分布式數據庫支持的節點多，增加節點后性能基本為線性增加；Oracle RAC 支持的節點數少，增加節點性能不是線性增加。2）Oracle 最大的問題在于shared everything 的架構，導致I/O 的處理能力有限，而且擴展能力也有限；而分布式數據庫是shared nothing 架構，在I/O 處理能力和擴展能力上要優于前者[1]。

TiDB 是一款開源的HTAP 的分布式數據庫。它結合了傳統的RDBMS 和NoSQL 的最佳特性，其優勢在于兼容MySQL，支持無限的水平擴展，具備強一致性和高可用性。目前已經被500 余家不同行業的企業應用在實際生產環境中。

綜上所述，為了優化和解決用電信息采集系統中存在的數據存儲擴展問題和海量數據實時分析應用的問題。我們嘗試在不改變現有系統架構應用的前提下，把TiDB 分布式數據庫引入到用電信息采集系統內，逐步觀察、分析及驗證其實際適用范圍和效果情況。

1 TiDB應用部署介紹

如圖1 所示是TiDB 的部署示意圖[2]。本次搭建TiDB 集群的測試環境共規劃了12 個節點。

詳細清單信息如表1 所示。

圖1 TiDB部署示意圖

表1 TiDB 集群測試環境清單

1.1 TiDB組件

我們應用了TiDB 集群三個核心組件：TiDB Serv?er、PD Server 和TiKV Server。下面將針對各組件功能進行介紹。

（1）TiDB Server

負責SQL 邏輯處理。它是無狀態的，支持水平擴展，本身不存儲數據，只負責接收SQL 請求(遵守MySQL 協議)，并做解析處理，獲取到請求的SQL 后進行語法解析和驗證、執行計劃的制定和優化等工作。

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

與TiKV 交互可以獲取和修改實際數據，并最終返回結果。

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

（2）PD Server

負責整個集群的調度和管理。它收集信息的來源分為2 類，一類是每個Tikv 節點定期匯報節點整體信息；另一類是每個Raft Group 的Leader 定期匯報的Re?gion 信息。通過對這些信息的收集整理，PD 可以做到管理維護TiKV 存儲集群中的元信息以及控制TiKV進行調度和負載均衡。另外，其還能為TiDB Server 提供全局唯一且遞增的事務ID。

（3）TiKV Server

負責存儲數據，是一個提供事務的分布式Key-Value 存儲引擎。以Region 為基本單位，每個節點上會有多個Region，每個Region 會存儲一段Key 區間的Key-Values 數據。默認情況下，一個Region 有3 個副本，分別存在于3 個節點上。

TiKV 對磁盤I/O 要求較高。TiKV 硬盤大小建議不超過500G，以防止硬盤損害時，數據恢復耗時過長。

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

（4）TiSpark

負責處理解決復雜的OLAP 需求。TiSpark 整合了Spark Catalyst 引擎, 并且可以高效的讀取TiKV 中的數據，結合索引實現高速查詢。我們目前將其用于各類報表的統計分析。

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

1.2 中控機

我們配置一臺服務器主機作為中控機，它可以控制TiDB 集群環境中的其他主機設備，具有最高權限。整個集群的部署、參數配置和版本升級都可以通過中控機操作來完成。

1.3 數據服務接口

本文將TiDB 定位成一個可分析的綜合性的查詢服務平臺。

為了方便用采系統的開發人員和測試人員訪問請求TiDB 數據庫服務而單獨研發了一套數據服務接口。此接口服務可以友好地協助初學者使用TiDB 數據庫，還可以統一且高效的監控和管理所有的數據請求服務。

2 TiDB比較好的特性

支持SQL 標準：TiDB 支持SQL 標準，故對于已有的SQL 語句可以在語法適量的修改下實現原有功能。TiDB 對MySQL 兼容性很好，支持MySQL 傳輸協議和大多數語法，致使大多數情況下無需修改代碼即可從MySQL 輕松遷移至TiDB。

水平彈性擴展：TiDB 支持節點的擴容和縮容。通過簡單地新增TiDB Server 節點即可實現計算能力的提升，新增TiKV Server 節點即可實現存儲容量的擴容。如此便可以輕松應對高并發、海量數據的應用場景。

支持分布式事務：TiDB 支持在節點間進行ACID事務。

運行穩定性高：在不出現大規模的節點故障或不丟失大多數副本的前提下，可以實現故障的自動恢復，無需人工介入。

3 數據遷移與同步

用采系統使用的是Oracle 數據庫，無法方便地使用TiDB 官方提供的Syncer 工具進行數據的遷移同步。所以，我們選用Oracle 的GoldenGate 產品，用來做數據的增量同步和全量遷移。同步。

由于當前應用場景不多，數據的同步規模不大，同步數據傳輸的峰值速度只有3Mb/s，且數據延遲不超過1 分鐘。

4 應用場景簡介

4.1 場景1：離線電表日電量計算

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

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

我們使用TiSpark 來實現離線電量的計算邏輯，并與實際業務電量數據進行比對，確保了數據的完整性和正確性。

執行耗時比如表2 所示。

表2 執行耗時對比

圖2 OGG同步數據示意圖

OGG 首先在源端Oracle 數據庫以一定間隔讀取REDO 日志，獲得變更信息。然后生成Trail 文件，再同樣以一定間隔的將本地的Trail 隊列發送至目標端，由目標端接收后，從Trail 文件生成SQL 語句在TiDB 中執行[3]。

在用采系統中為配合在TiDB 中進行業務功能和性能測試，共選用了十多張檔案表和數據表，合計超過30 億條數據做全量遷移和每日接近1 億條數據做增量

由此可見，在大量數據的計算分析上，TiDB 要比Oracle 數據庫快很多。具體表現在離線電表日電量計算上總體快了約8 倍。

4.2 場景2：采集成功率統計

采集成功率統計是反映全省數據采集質量的一個重要指標。我們按地區、分高低壓、終端的型號和廠家等維度來分析統計各類數據項(電能示值類、需量類)的當日采集完成情況。

目前，用采系統中該統計功能在Oracle 數據庫中以多個存儲過程，制定JOB 任務鏈的方式，每天定時執行3 次，每次平均耗時60 分鐘，生成基礎信息、統計信息和失敗清單信息累計近千萬條數據。

我們針對存儲過程中的SQL 語句逐個進行改造后遷移至TiSpark 中執行。從運行效果上來看，執行效率明顯提升，平均耗時20 分鐘就能分析統計完成。

4.3 場景3：線損模塊數據查詢

在用采系統頁面功能中選取了線損模塊下的統計查詢、考核單元管理、臺區統計視圖等功能，在測試環境下做SQL 語句改造和必要的邏輯拆分工作，總共涉及近150 條SQL 語句。

我們通過用采系統應用服務調用數據服務接口，然后訪問TiDB 進行分析處理并返回結果集給應用服務。

SQL 改造中會有執行計劃與原Oracle 的執行計劃差別較大的情況，我們會嘗試重新收集統計信息、改變表關聯順序、篩選條件格式和位置等，最終達到了理想的查詢效率。

5 實踐中遇到的問題

TiDB 的應用已經有一段時間，在集群部署、環境參數配置以及業務測試應用階段或多或少遇到了一些問題。這些問題有的容易解決，有的尋求了TiDB 廠家的支持。

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

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

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

（4）TiDB 中執行SQL 查詢，偶爾會遇到執行變慢的問題，一般都是執行計劃改變引起，需要重新收集統計信息，相較與Oracle 的執行計劃還不夠穩定。

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

6 結語

結合我們的實際現狀，我們現階段主要將TiDB 定位為對外提供查詢服務的平臺。后期隨著應用的深入，也會不斷擴展其應用范圍，在其上進行更多的離線計算和業務分析OLAP 場景。