企業儲存分級

前陣子紛紛揚揚的刪庫跑路事件以其狗血的劇情給我們這些封閉在家的碼農們很大的歡樂，歡樂之餘，大家也在探討企業IT治理方面的問題。老白也寫了一篇文章，關於從技術角度，如何有效的避免類似悲劇發生的問題。其中提到了一個概念“企業資料分級管理”。本文和大家談到的內容和那個話題有關。

隨著建設資訊化企業工作的深入，企業資料的增長呈現爆炸性的趨勢。以某公司為例，在最近幾年裡的用於資料儲存的裝置上線也呈加速增長的態勢。   2014年該企業的SAN儲存容量與NAS儲存容量載入一起剛剛突破1PB，到2018年，就已經翻了3倍了。從2017年開始，出現了更為高速增長的趨勢。這些企業資料包括企業管理業務中產生的資料，面向裝置採集的資料，也包括企業從外部購買的資料。這些資料大多數都儲存在各種資料庫系統中。公司已經建設了180多套資料庫系統，用於儲存各種各樣的資料，而為了進一步支撐業務的開展，還需要再建設100多套資料庫系統。這些用傳統方式煙囪式建設的資料庫系統帶來的管理難度已經讓運維部門叫苦不迭。

另外一個方面，由於各種資料與應用系統的的建設缺乏統一規劃，這180多套資料庫系統包括了Oracle、DB2、MySQL、GBASE 8a、Mongodb、達夢、HIVE、HBASE等，再按資料庫的版本統計，已經高達20多種。紛亂複雜的資料庫種類，不同資料庫版本之間的運維與建設差異，更是讓運檢部門深感頭疼。

為了在一個新的建設高峰到來之前先釐清現狀，做好頂層設計，企業決定進行資料分層儲存的頂層設計。首先把家底梳理清楚，然後進行整理分析，確定資料分類分級的標準，然後針對不同類級的資料制定統一的資料儲存規範，採用統一的資料儲存架構，減少資料庫的種類，統一資料庫的版本。

經過對企業資料的現狀進行梳理，我們發現目前的企業資料儲存邏輯架構是這樣的：

企業中的結構化資料主要儲存在關係型資料庫中，而非結構化資料主要儲存在大資料平臺和物件儲存中。非結構化資料的儲存與處理起步較晚，因此規劃基本合理，平臺也比較統一。最大的問題是結構化資料。不同的業務需求與建設要求並沒有在一個統一的頂層框架中統一考慮，因此不同規模，不同種類的資料庫系統在不同的階段被建設起來。很多資料庫系統高峰期的併發訪問量不超過5個，造成了絕大的資源浪費。另外一個極端是，有些資料庫系統雖然已經使用了最為豪華的硬體配置，其處理能力已經嚴重不足，而企業很快將面臨硬體擴無可擴的窘境。

為了解決目前企業的困境，同時為今後幾年物聯網建設所面臨的幾十PB的裝置資料接入做好準備，企業決定顛覆原有的資料儲存架構，按照資料分級儲存的總體原則，規劃統一資料儲存的頂層方案。

新的頂層設計從兩個方面進行考慮，首先根據系統的特點不同，支援多種分級承載的方案，透過儲存分層，為應用提供全面的支撐；其次規範資料庫的種類與版本，建立資料庫標準化編排能力，逐步實現資料庫部署自動化，最終實現全棧自動化編排。對於傳統業務應用系統，資料分為線上資料、歷史資料、歸檔資料等，根據訪問特性不同採用不同檔次的儲存模式，儲存方式主要以傳統大型資料庫系統為主；對於物聯網應用，資料分為實時線上資料、熱線上資料、溫線上資料、本地歷史資料、分散式歷史資料等，不同的資料採用不同儲存形式，資料以分散式方式儲存，部分明細資料儲存於邊緣側，資料主要儲存於分散式關係型資料庫；對於網際網路特徵應用，學習網際網路企業的經驗，線上資料儲存在記憶體緩衝層，熱資料儲存於高效能儲存裝置，冷資料儲存於海量分散式儲存，資料庫採用分散式關係型資料庫和分散式記憶體資料庫。

在經過重新規劃梳理的資料儲存架構中，關係型資料庫仍然佔據較為重要的位置，不過資料庫的種類經過整理後將會縮表為Oracle、MySQL、某種分散式關係型資料庫三種。Oracle資料庫仍然承載傳統的核心管理類應用系統，Mysql資料庫目前已經在企業內大規模使用，主要是在雲上的小型資料庫，分散式關係型資料庫的選型是下一步選型的要點。在分散式關係型資料庫選型時，根據企業資料分級儲存頂層設計的要求，需要備選資料庫滿足以下的要求：

（1）     支援ACID事務：對於關係型資料庫來說ACID是基本特性，但是在支援高併發的分散式場景中，在提升擴充套件性與系統效能的同時保證資料完整性與正確性成為了評估一款分散式資料庫系統的重要指標之一。

（2）     水平彈性擴充套件：集中式資料庫的架構使得資料庫成為了整個系統的瓶頸，已經逐漸無法滿足海量資料對儲存和計算能力的巨大需求。企業選擇的分散式資料庫系統不僅僅你要求能夠做橫向的水平彈性擴充套件，而且需要擴充套件時對現有生產業務的影響最小化。

（3）     高可用性：首先，分散式資料庫系統故障的恢復成本要遠遠高於普通的資料庫系統，因此分散式資料庫系統必須支援多副本自動容錯；其次，為了進一步提高核心資料的可靠性，對於分散式資料庫中的部分高可靠性要求的資料，還需要建立跨機房遠端災備，因此備選的分散式資料庫系統必須支援遠端增量複製，並且可以選擇性複製部分資料。

（4）     為OLTP和OLAP場景提供一站式的解決方案：隨著泛在電力物聯網業務的發展，大量的資料需要多次使用，這些資料的量級是PB級的，因此透過搬資料的方式建立OLTP與OLAP兩套資料庫來滿足不同的計算要求的成本太高，分散式關係型資料庫必須支援OLTP/OLAP混合計算。

（5）     為了減少應用遷移的工作量與今後運維的工作量，備選的分散式資料庫系統最好能與MySQL具有較好的相容性。

經過對國內外的數十種資料庫的比對分析，最終TiDB脫穎而出，作為分散式關係型資料庫的首選。主要用於作為物聯網的核心支撐資料庫系統。其應用模式分為三種模式：

（1）     物聯網資料採集大型分散式資料庫系統：建立大規模的資料庫叢集，用於海量物聯網資料的採集、儲存、共享、分析的核心資料庫系統；

（2）     多租戶資料庫雲服務：建立統一的資料庫雲服務，為企業各種小型資料庫應用提供統一的服務；

（3）     邊緣測資料中心的主資料庫：在物聯網建設過程中，各類邊緣側的場站中將會建設大量的小型資料中心，這些小型資料中心用於承擔邊緣側資料的儲存與計算任務，其資料庫要求支撐海量計算、高可用、易擴充套件、易維護。

  在資料分級儲存頂層設計原則指導下最佳化後的關係型應用系統，其部署架構被統一成三種模式。

對於傳統的核心業務系統，暫時無法進行雲化改造的，進一步加強其系統安全性，提升高可用等級，確保核心業務穩定執行。

對於重要性次一級的系統，可以採用MySQL或者Oracle（儘可能選擇MySQL），採用主從複製的方式實現高可用，這類資料庫系統可以部署在雲平臺上，也可以部署在物理機組成的裸金屬雲上，由資料庫運管平臺統一納管。

對於物聯網應用、邊緣側資料中心應用等應用場景，採用TiDB分散式資料庫系統，採用多租戶的方式，為各類應用系統提供資料庫服務。

經過對資料儲存模式的梳理，在資料分級儲存的頂層架構指導下，企業資料儲存架構更為合理，資料庫種類得到了有效的控制，資料庫部署架構更為規範。TiDB分散式資料庫的引入填補了以往海量資料處理與時序資料處理方面的空白，使資料處理的範圍與能力得到了極大的擴充套件。在新的資料儲存架構下，企業將可以從容面對未來資料高速增長與資料處理需求不斷提升的需求，為建設資訊化企業提供了有力的保障。