TiDB 在威銳達 WindRDS 遠程診斷及運維中心的應用

## 公司簡介

西安銳益達風電技術有限公司成立於 2012 年 1 月 4 日，是一家專業化的工業測量儀器系統、機電產品和計算機軟件研發、設計和製造公司，是北京威銳達測控系統有限公司在西安成立的全資子公司。依託大學的科研實力，矢志不渝地從事儀器儀表及測量系統的研究和應用開發，積累了豐富的專業知識和實踐經驗，具有自主開發高端儀器系統和工程實施的完整技術能力。

爲了適應我國大型風電運營商設備維護管理的需求，破解風電監測技術難題，通過多年艱苦研發，研製了一種具備徹底自主知識產權的網絡化、模塊化、集成化的風電機組狀態監測與故障診斷系統，爲風電機組全生命週期的運行維護管理提供一套完整的解決方案。

業務描述

威銳達 WindRDS 遠程診斷與運維中心，是以設備健康監測爲核心，實現企業設備全生命週期的健康監測和基於狀態的預知性設備運營維護的管理平臺。

本平臺以多維、豐富的數據爲基礎，結合傳統的診斷分析方法，並充分發揮利用大數據智能化的技術手段，快速及時的發現、分析定位設備運轉及企業運維過程當中的問題，並以流程化、自動化的軟件系統輔助用戶高效的跟蹤、處理問題，目標提高企業設備運維管理的能力，節約運維成本，爲企業創造價值。

圖 1：WindRDS 系統交互圖

痛點、選型指標

痛點

• WindRDS 的數據平臺，對於數據的存儲當前選用流行的 MySQL 數據庫，面對每一年 T 級的數據增加量，以及隨着數據量的快速增加致使訪問性能的急劇降低，目前也只是經過傳統的分表、分庫等解決方案進行優化，但性能提高未達到預期，且後續維護升級複雜麻煩，不能很好的知足存儲和性能彈性水平擴展的需求。

• 本項目同時具備 OLTP 和 OLAP 應用需求，也曾設計構建混合型的數據存儲方案（MySQL+ HDFS + Hive + Kylin + HBase + Spark），功能上可同時知足 OLTP 和 OLAP 應用需求，但問題也很明顯，如：

• 要知足必定程度的實時在線分析，還須要作一些數據遷移同步工做，須要開發實時同步 ETL 中間件，實時從存儲事務數據的關係數據庫向存儲面向分析的 Hive、HBase 數據庫同步數據，實時性及可靠性不能保證；

• 對於基於 SQL 數據訪問的應用程序的切換到該數據平臺構成很大挑戰，應用程序的數據訪問層都須要進行修改適配，工做量大，切換成本高；

• 對於面向大數據的的分佈式數據庫產品（Hive、HBase 等）投入成本高且維護複雜，容易出錯，可維護性差。

選型指標

• 支持容量及性能的水平彈性擴縮；

• 支持對使用 MySQL 協議的應用程序的便捷穩定的遷移，無需修改程序；

• 知足業務故障自恢復的高可用，且易維護；

• 強一致的分佈式事務處理；

• 支持 Spark，可支撐機器學習應用；

• 集羣狀態可視化監控，方便運行維護。

咱們大部分應用程序數據訪問用的是 MySQL 的協議，TiDB 數據庫完美的支持了 MySQL 的 SQL 語法，咱們現有的應用程序幾乎不用作任何修改，就可直接切換到 TiDB 上使用，而且可以很好的知足咱們的 OLTP 需求和複雜 OLAP 的需求。另外，TiSpark 是創建在 Spark 引擎之上的，Spark 在機器學習領域上仍是比較成熟的。考慮到將來咱們的平臺也會用到機器學習的一些業務應用，綜合上述方面，TiDB + TiSpark 成爲了咱們首選的技術解決方案。

TiDB 上線前測試

TiDB 在我司的數據中心部署的應用狀況以下：

部署架構

改造以前，主要用 MySQL 多實例的方式承載 WindRDS 全部的業務數據存儲和應用，隨着數據增加，存儲容量接近單機的磁盤極限，單機的磁盤 IO 繁忙且易阻塞，查詢性能難以知足業務增加的需求。數據量大了之後，傳統的 MySQL 水平擴展能力弱，性能和穩定性容易產生問題，現有傳統關係數據庫已不能知足業務的擴展和應用，已成爲制約業務發展的瓶頸。

而爲了知足大數據可視化 BI 分析、機器學習的 OLAP 場景，選用了多種數據中間件產品 HBase、Hive、Kylin 及 Spark 進行組合，造成一個複雜的多種數據中間件產品混合型集羣，必定程度知足了 OLAP 的需求，但不一樣的產品之間存在資源爭搶和制約，集羣很是難於維護，非一步到位的最佳方案。

圖 2：改造前 WindRDS 系統架構

改造以後，TiDB + TiSpark 的解決方案，解決了以前方案的不足，系統數據中間件產品種類簡化，OLTP + OLAP 一攬子解決方案，系統數據存儲和查詢計算集羣結構簡單，較少人工參與系統節點維護，下降運維複雜度，是一個比較理想的解決方案。

圖 3：改造後 WindRDS 部署架構

測試集羣配置

TiDB 測試集羣整體配置以下：

TiSpark 測試集羣整體配置以下：

測試數據查詢性能對比

咱們使用 TiDB 1.0 版本搭建測試集羣，而後咱們進行了簡單的查詢性能測試，咱們對 WindRDS 的 5 種類型的數據進行查詢測試，從業務應用中選擇了針對每種數據類型的耗時、複雜的關聯 SQL 語句，分別在 MySQL 上和 TiDB 上進行執行，屢次執行取平均值，以下圖所示，明顯的，TiDB 的響應時間要小於 MySQL，可見 TiDB 的查詢性在咱們業務模型中表現明顯優於 MySQL 。

圖 4：測試數據關鍵操做對比 MySQL vs TiDB

圖 5：測試數據關鍵操做 MySQL vs TiDB 耗時對比 (越低越好)

TiDB 上線

從 1 月初測試環境搭建完成到上線，TiDB 穩定運行四個多月，平均 QPS 穩定在數千。TiDB 在性能、可用性、穩定性上徹底超出了咱們的預期。

測試及上線過程當中的一些問題

因爲前期咱們對 TiDB 的瞭解還不深，在此遷移期間碰到的一些兼容性的問題，簡單列舉以下：

• 好比 TiDB 的自增 ID 的機制；

• 表外鍵級聯機制；

• 排序的時候須要使用字段名等。

以上問題諮詢 TiDB 的工程師後，很快的獲得瞭解決，很是感謝 TiDB 團隊的支持以及快速響應。

另外，在使用 TiDB 1.0 版本的過程當中咱們也遇到過以下問題：

• 集羣中某個 TiKV 節點的 SSD 滿了，可是集羣不認爲滿了，繼續要求該節點寫入數據，致使進程宕機。

• 集羣中任何一個節點 IO 能力降低，都會致使整個集羣若依賴他的操做都受到影響，所以，該分佈式的數據庫等組件，雖然提升了性能和擴展性，可是維護也同樣比較棘手，任何瓶頸，都有可能拉低整個集羣的性能。

以上問題再升級到 TiDB 2.0 版本後解決，諮詢 TiDB 官方團隊答覆以下：

• 第一個問題，在 TiDB 2.0 版本有對應的優化，TiDB 在空間不足時會根據剩餘空間進行調度，下降此問題發生的機率。

• 第二個問題，TiDB 2.0 版本會充分考慮機器負載，響應時間等維度進行調度，儘量避免單點成爲整個系統的瓶頸。

後續和展望

咱們對 TiDB 愈來愈瞭解，後續咱們計劃對 TiDB 進行大規模推廣使用，具體包括：

• 公司後續關於風電領域大數據中心的開發建設，考慮選型 TiDB 做爲數據存儲，並推薦給咱們的合做客戶。

• 公司 WindRDS、WindCMS 等既有應用系統將考慮逐步切換到 TiDB 上來。

• WindRDS 後續關於大數據多維度可視化分析、專家系統及機器學習等應用功能的開發，對於數據的存儲和查詢應用，計劃選用 TiDB + TiSpark 進行底層中間件的支持。

最終經過 TiDB 造成一個同時兼容分析型和事務型（HTAP）的統一數據庫平臺解決方案。

做者介紹：郭凱樂，應用軟件工程師，從公司成立入職工做至今共 6 年半時間，起初主要負責公司的應用系統的服務器端程序的設計開發，對於公司的核心業務及系統架構很是熟悉。2015 年到 2016 年，主持開發了基於規則的智能診斷系統（專家系統）,該系統的開發，使自身對於專家系統有了深入的瞭解和認識，並積累了豐富的經驗，成爲該領域的資深工程師。2016 年第至今，參與公司大數據平臺項目的研發，該項目主要是圍繞着大數據、工業物聯網及分佈式系統進行一些方法、中間件及解決方案的一些研究，而做者自己參與該項目關於數據的接入及治理方法及方案的研究工做，過程當中對於數據接入融合及數據治理所面臨的問題、痛點深有體會，積累了豐富經驗及心得。