## 公司簡介
西安銳益達風電技術有限公司成立於 2012 年 1 月 4 日，是一家專業化的工業測量儀器系統、機電產品和計算機軟體研發、設計和製造公司，是北京威銳達測控系統有限公司在西安成立的全資子公司。依託大學的科研實力，矢志不渝地從事儀器儀表及測量系統的研究和應用開發，積累了豐富的專業知識和實踐經驗，具備自主開發高階儀器系統和工程實施的完整技術能力。
為了適應我國大型風電運營商裝置維護管理的需求，破解風電監測技術難題，經過多年艱苦研發，研製了一種具有完全自主智慧財產權的網路化、模組化、整合化的風電機組狀態監測與故障診斷系統，為風電機組全生命週期的執行維護管理提供一套完整的解決方案。
業務描述
威銳達 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 的需求，但不同的產品之間存在資源爭搶和制約，叢集非常難於維護，非一步到位的最佳方案。
改造之後，TiDB + TiSpark 的解決方案，解決了之前方案的不足，系統資料中介軟體產品種類簡化，OLTP + OLAP 一攬子解決方案，系統資料儲存和查詢計算叢集結構簡單，較少人工參與系統節點維護，降低運維複雜度，是一個比較理想的解決方案。
測試叢集配置
TiDB 測試叢集總體配置如下：
TiSpark 測試叢集總體配置如下：
測試資料查詢效能對比
我們使用 TiDB 1.0 版本搭建測試叢集，然後我們進行了簡單的查詢效能測試，我們對 WindRDS 的 5 種型別的資料進行查詢測試，從業務應用中選擇了針對每種資料型別的耗時、複雜的關聯 SQL 語句，分別在 MySQL 上和 TiDB 上進行執行，多次執行取平均值，如下圖所示，明顯的，TiDB 的響應時間要小於 MySQL，可見 TiDB 的查詢性在我們業務模型中表現明顯優於 MySQL 。
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 年第至今，參與公司大資料平臺專案的研發，該專案主要是圍繞著大資料、工業物聯網及分散式系統進行一些方法、中介軟體及解決方案的一些研究，而作者本身參與該專案關於資料的接入及治理方法及方案的研究工作，過程中對於資料接入融合及資料治理所面臨的問題、痛點深有體會，積累了豐富經驗及心得。