摘要：選型指標(biāo)支持容量及性能的水平彈性擴(kuò)縮支持對使用協(xié)議的應(yīng)用程序的便捷穩(wěn)定的遷移，無需修改程序滿足業(yè)務(wù)故障自恢復(fù)的高可用，且易維護(hù)強(qiáng)一致的分布式事務(wù)處理支持，可支撐機(jī)器學(xué)習(xí)應(yīng)用集群狀態(tài)可視化監(jiān)控，方便運(yùn)行維護(hù)。

西安銳益達(dá)風(fēng)電技術(shù)有限公司成立于 2012 年 1 月 4 日，是一家專業(yè)化的工業(yè)測量儀器系統(tǒng)、機(jī)電產(chǎn)品和計算機(jī)軟件研發(fā)、設(shè)計和制造公司，是北京威銳達(dá)測控系統(tǒng)有限公司在西安成立的全資子公司。依托大學(xué)的科研實(shí)力，矢志不渝地從事儀器儀表及測量系統(tǒng)的研究和應(yīng)用開發(fā)，積累了豐富的專業(yè)知識和實(shí)踐經(jīng)驗，具備自主開發(fā)高端儀器系統(tǒng)和工程實(shí)施的完整技術(shù)能力。

為了適應(yīng)我國大型風(fēng)電運(yùn)營商設(shè)備維護(hù)管理的需求，破解風(fēng)電監(jiān)測技術(shù)難題，經(jīng)過多年艱苦研發(fā)，研制了一種具有完全自主知識產(chǎn)權(quán)的網(wǎng)絡(luò)化、模塊化、集成化的風(fēng)電機(jī)組狀態(tài)監(jiān)測與故障診斷系統(tǒng)，為風(fēng)電機(jī)組全生命周期的運(yùn)行維護(hù)管理提供一套完整的解決方案。

威銳達(dá) WindRDS 遠(yuǎn)程診斷與運(yùn)維中心，是以設(shè)備健康監(jiān)測為核心，實(shí)現(xiàn)企業(yè)設(shè)備全生命周期的健康監(jiān)測和基于狀態(tài)的預(yù)知性設(shè)備運(yùn)營維護(hù)的管理平臺。

本平臺以多維、豐富的數(shù)據(jù)為基礎(chǔ)，結(jié)合傳統(tǒng)的診斷分析方法，并充分發(fā)揮利用大數(shù)據(jù)智能化的技術(shù)手段，快速及時的發(fā)現(xiàn)、分析定位設(shè)備運(yùn)轉(zhuǎn)及企業(yè)運(yùn)維過程中的問題，并以流程化、自動化的軟件系統(tǒng)輔助用戶高效的跟蹤、處理問題，目標(biāo)提升企業(yè)設(shè)備運(yùn)維管理的能力，節(jié)約運(yùn)維成本，為企業(yè)創(chuàng)造價值。

                             圖 1：WindRDS 系統(tǒng)交互圖

WindRDS 的數(shù)據(jù)平臺，對于數(shù)據(jù)的存儲當(dāng)前選用流行的 MySQL 數(shù)據(jù)庫，面對每年 T 級的數(shù)據(jù)增長量，以及隨著數(shù)據(jù)量的快速增長導(dǎo)致訪問性能的急劇下降，目前也只是通過傳統(tǒng)的分表、分庫等解決方案進(jìn)行優(yōu)化，但性能提升未達(dá)到預(yù)期，且后續(xù)維護(hù)升級復(fù)雜麻煩，不能很好的滿足存儲和性能彈性水平擴(kuò)展的需求。

本項目同時具有 OLTP 和 OLAP 應(yīng)用需求，也曾設(shè)計構(gòu)建混合型的數(shù)據(jù)存儲方案（MySQL+ HDFS + Hive + Kylin + HBase + Spark），功能上可同時滿足 OLTP 和 OLAP 應(yīng)用需求，但問題也很明顯，如：

要滿足一定程度的實(shí)時在線分析，還需要做一些數(shù)據(jù)遷移同步工作，需要開發(fā)實(shí)時同步 ETL 中間件，實(shí)時從存儲事務(wù)數(shù)據(jù)的關(guān)系數(shù)據(jù)庫向存儲面向分析的 Hive、HBase 數(shù)據(jù)庫同步數(shù)據(jù)，實(shí)時性及可靠性不能保證；

對于基于 SQL 數(shù)據(jù)訪問的應(yīng)用程序的切換到該數(shù)據(jù)平臺構(gòu)成很大挑戰(zhàn)，應(yīng)用程序的數(shù)據(jù)訪問層都需要進(jìn)行修改適配，工作量大，切換成本高；

對于面向大數(shù)據(jù)的的分布式數(shù)據(jù)庫產(chǎn)品（Hive、HBase 等）投入成本高且維護(hù)復(fù)雜，容易出錯，可維護(hù)性差。

支持容量及性能的水平彈性擴(kuò)縮；

支持對使用 MySQL 協(xié)議的應(yīng)用程序的便捷穩(wěn)定的遷移，無需修改程序；

滿足業(yè)務(wù)故障自恢復(fù)的高可用，且易維護(hù)；

強(qiáng)一致的分布式事務(wù)處理；

支持 Spark，可支撐機(jī)器學(xué)習(xí)應(yīng)用；

集群狀態(tài)可視化監(jiān)控，方便運(yùn)行維護(hù)。

我們大部分應(yīng)用程序數(shù)據(jù)訪問用的是 MySQL 的協(xié)議，TiDB 數(shù)據(jù)庫完美的支持了 MySQL 的 SQL 語法，我們現(xiàn)有的應(yīng)用程序幾乎不用做任何修改，就可直接切換到 TiDB 上使用，并且能夠很好的滿足我們的 OLTP 需求和復(fù)雜 OLAP 的需求。另外，TiSpark 是建立在 Spark 引擎之上的，Spark 在機(jī)器學(xué)習(xí)領(lǐng)域上還是比較成熟的。考慮到未來我們的平臺也會用到機(jī)器學(xué)習(xí)的一些業(yè)務(wù)應(yīng)用，綜合上述方面，TiDB + TiSpark 成為了我們首選的技術(shù)解決方案。

TiDB 在我司的數(shù)據(jù)中心部署的應(yīng)用情況如下：

改造之前，主要用 MySQL 多實(shí)例的方式承載 WindRDS 所有的業(yè)務(wù)數(shù)據(jù)存儲和應(yīng)用，隨著數(shù)據(jù)增長，存儲容量接近單機(jī)的磁盤極限，單機(jī)的磁盤 IO 繁忙且易阻塞，查詢性能難以滿足業(yè)務(wù)增長的需求。數(shù)據(jù)量大了以后，傳統(tǒng)的 MySQL 水平擴(kuò)展能力弱，性能和穩(wěn)定性容易產(chǎn)生問題，現(xiàn)有傳統(tǒng)關(guān)系數(shù)據(jù)庫已不能滿足業(yè)務(wù)的擴(kuò)展和應(yīng)用，已成為制約業(yè)務(wù)發(fā)展的瓶頸。

而為了滿足大數(shù)據(jù)可視化 BI 分析、機(jī)器學(xué)習(xí)的 OLAP 場景，選用了多種數(shù)據(jù)中間件產(chǎn)品 HBase、Hive、Kylin 及 Spark 進(jìn)行組合，形成一個復(fù)雜的多種數(shù)據(jù)中間件產(chǎn)品混合型集群，一定程度滿足了 OLAP 的需求，但不同的產(chǎn)品之間存在資源爭搶和制約，集群非常難于維護(hù)，非一步到位的最佳方案。

                              圖 2：改造前 WindRDS 系統(tǒng)架構(gòu)

改造之后，TiDB + TiSpark 的解決方案，解決了之前方案的不足，系統(tǒng)數(shù)據(jù)中間件產(chǎn)品種類簡化，OLTP + OLAP 一攬子解決方案，系統(tǒng)數(shù)據(jù)存儲和查詢計算集群結(jié)構(gòu)簡單，較少人工參與系統(tǒng)節(jié)點(diǎn)維護(hù)，降低運(yùn)維復(fù)雜度，是一個比較理想的解決方案。

                             圖 3：改造后 WindRDS 部署架構(gòu)

TiDB 測試集群總體配置如下：

TiSpark 測試集群總體配置如下：

我們使用 TiDB 1.0 版本搭建測試集群，然后我們進(jìn)行了簡單的查詢性能測試，我們對 WindRDS 的 5 種類型的數(shù)據(jù)進(jìn)行查詢測試，從業(yè)務(wù)應(yīng)用中選擇了針對每種數(shù)據(jù)類型的耗時、復(fù)雜的關(guān)聯(lián) SQL 語句，分別在 MySQL 上和 TiDB 上進(jìn)行執(zhí)行，多次執(zhí)行取平均值，如下圖所示，明顯的，TiDB 的響應(yīng)時間要小于 MySQL，可見 TiDB 的查詢性在我們業(yè)務(wù)模型中表現(xiàn)明顯優(yōu)于 MySQL 。

                           圖 4：測試數(shù)據(jù)關(guān)鍵操作對比 MySQL vs TiDB

                       圖 5：測試數(shù)據(jù)關(guān)鍵操作 MySQL vs TiDB 耗時對比 (越低越好)

從 1 月初測試環(huán)境搭建完成到上線，TiDB 穩(wěn)定運(yùn)行四個多月，平均 QPS 穩(wěn)定在數(shù)千。TiDB 在性能、可用性、穩(wěn)定性上完全超出了我們的預(yù)期。

由于前期我們對 TiDB 的了解還不深，在此遷移期間碰到的一些兼容性的問題，簡單列舉如下：

比如 TiDB 的自增 ID 的機(jī)制；

表外鍵級聯(lián)機(jī)制；

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

以上問題咨詢 TiDB 的工程師后，很快的得到了解決，非常感謝 TiDB 團(tuán)隊的支持以及快速響應(yīng)。

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

集群中某個 TiKV 節(jié)點(diǎn)的 SSD 滿了，但是集群不認(rèn)為滿了，繼續(xù)要求該節(jié)點(diǎn)寫入數(shù)據(jù)，導(dǎo)致進(jìn)程宕機(jī)。

集群中任何一個節(jié)點(diǎn) IO 能力下降，都會導(dǎo)致整個集群若依賴他的操作都受到影響，因此，該分布式的數(shù)據(jù)庫等組件，雖然提高了性能和擴(kuò)展性，但是維護(hù)也一樣比較棘手，任何瓶頸，都有可能拉低整個集群的性能。

以上問題再升級到 TiDB 2.0 版本后解決，咨詢 TiDB 官方團(tuán)隊答復(fù)如下：

第一個問題，在 TiDB 2.0 版本有對應(yīng)的優(yōu)化，TiDB 在空間不足時會根據(jù)剩余空間進(jìn)行調(diào)度，降低此問題發(fā)生的概率。

第二個問題，TiDB 2.0 版本會充分考慮機(jī)器負(fù)載，響應(yīng)時間等維度進(jìn)行調(diào)度，盡可能避免單點(diǎn)成為整個系統(tǒng)的瓶頸。

我們對 TiDB 越來越了解，后續(xù)我們計劃對 TiDB 進(jìn)行大規(guī)模推廣使用，具體包括：

公司后續(xù)關(guān)于風(fēng)電領(lǐng)域大數(shù)據(jù)中心的開發(fā)建設(shè)，考慮選型 TiDB 作為數(shù)據(jù)存儲，并推薦給我們的合作客戶。

公司 WindRDS、WindCMS 等既有應(yīng)用系統(tǒng)將考慮逐步切換到 TiDB 上來。

WindRDS 后續(xù)關(guān)于大數(shù)據(jù)多維度可視化分析、專家系統(tǒng)及機(jī)器學(xué)習(xí)等應(yīng)用功能的開發(fā)，對于數(shù)據(jù)的存儲和查詢應(yīng)用，計劃選用 TiDB + TiSpark 進(jìn)行底層中間件的支持。

最終通過 TiDB 形成一個同時兼容分析型和事務(wù)型（HTAP）的統(tǒng)一數(shù)據(jù)庫平臺解決方案。

作者介紹：郭凱樂，應(yīng)用軟件工程師，從公司成立入職工作至今共 6 年半時間，起初主要負(fù)責(zé)公司的應(yīng)用系統(tǒng)的服務(wù)器端程序的設(shè)計開發(fā)，對于公司的核心業(yè)務(wù)及系統(tǒng)架構(gòu)非常熟悉。2015 年到 2016 年，主持開發(fā)了基于規(guī)則的智能診斷系統(tǒng)（專家系統(tǒng)）,該系統(tǒng)的開發(fā)，使自身對于專家系統(tǒng)有了深刻的了解和認(rèn)識，并積累了豐富的經(jīng)驗，成為該領(lǐng)域的資深工程師。2016 年第至今，參與公司大數(shù)據(jù)平臺項目的研發(fā)，該項目主要是圍繞著大數(shù)據(jù)、工業(yè)物聯(lián)網(wǎng)及分布式系統(tǒng)進(jìn)行一些方法、中間件及解決方案的一些研究，而作者本身參與該項目關(guān)于數(shù)據(jù)的接入及治理方法及方案的研究工作，過程中對于數(shù)據(jù)接入融合及數(shù)據(jù)治理所面臨的問題、痛點(diǎn)深有體會，積累了豐富經(jīng)驗及心得。