摘要：選型指標支持容量及性能的水平彈性擴縮支持對使用協議的應用程序的便捷穩定的遷移，無需修改程序滿足業務故障自恢復的高可用，且易維護強一致的分布式事務處理支持，可支撐機器學習應用集群狀態可視化監控，方便運行維護。

西安銳益達風電技術有限公司成立于 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 在我司的數據中心部署的應用情況如下：

改造之前，主要用 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 耗時對比 (越低越好)

從 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 年第至今，參與公司大數據平臺項目的研發，該項目主要是圍繞著大數據、工業物聯網及分布式系統進行一些方法、中間件及解決方案的一些研究，而作者本身參與該項目關于數據的接入及治理方法及方案的研究工作，過程中對于數據接入融合及數據治理所面臨的問題、痛點深有體會，積累了豐富經驗及心得。