背景介紹
傳統行業在本文中是指在國内有一定體量，較為基礎的一些行業企業，此類企業有幾個特征：
- 企業體量較大
- 業務變化不大
- 客戶群體大
- 客戶數量變化不大
此類行業近幾年随着資料中台、人工智能、數字孿生等等概念的不斷洗刷，也因為本身業務發展的實際需要，資料體量連年增長。
随着國内開源軟體生态逐漸成熟，面向傳統行業的軟體企業傳遞的資料架構，也以開源軟體為主建構，逐漸的發展變化。本文主要介紹在開源的背景下，傳統行業資料架構近幾年的發展變化，以及每一步的掣肘和突破，作者總結下來感覺有一定的代表性，希望分享出來能夠提供一些思路。
資料架構的發展變化
作者所經曆的資料架構分三個階段：單一資料庫叢集、TP和AP分離、大資料的引入，現在正在經曆HTAP+雲原生這一階段。
單一資料庫叢集
作者所經曆的單一資料庫叢集階段，大約是在18年開始的，現在也會在項目開始階段較多的采用。架構圖如下：
單一資料庫并不是指就一個資料庫執行個體，而且整個架構的主體采用了一個資料庫産品，例如架構圖中是以Mysql官方分發版本為主體，通過MHA方案，搭建的高可用Mysql叢集，為了應對資料的增長，中間加了一個資料庫通路代理，我們采用的是mycat，分庫分表、讀寫分離都通過mycat做出來。
此架構模式下，資料量增長的一定規模之後，出現了一些問題：
- 跨分片通路性能不佳
- 彙總性能不佳、寬表支援較差
- 分析類需求支援不好，與實時業務争搶CPU和IO
這些原因搞過資料架構的都會很容易總結出來，歸根結底，是過多的把AP的需求讓Mysql來解決了。
TP和AP分離
基于項目越來越多的離線彙總需求和線上分析需求，整個項目引入了AP類型的資料庫。由于開源的GreenPlum在國内的火熱，企業内部多采用了GreenPlum資料庫，有較多的技術積累。
參考：Greenplum中文官網
內建了GP的資料架構如下：
參考：bireme
我們從Mysql到Greenplum建構了兩個通道，一個通道是通過kettle建構ETL任務批量抽取資料到Greenplum，一個通道是通過bireme+maxwell實時同步資料到Greenplum。從架構圖上可以看到，kettle寫入資料，實際上是與Greenplum的Segment（primary）節點打交道，效率比較高；bireme+maxwell是通過master寫入Greenplum叢集的，效率不高，特别是一些更新較頻繁的表，大量占用IO。
kettle支撐了我們很久，bireme+maxwell由于IO問題沒有徹底解決也就放棄了這條路線。20年Greenplum官方出了streaming-server元件，這個環節的問題得到了很好的解決，但那個時候我們換了方案，也就沒在實際生産中使用。
參考：streaming-server
随着資料量的增長，我們面對幾個棘手的問題，始終解決的不好，引起了客戶大量的投訴：
- 随着業務發展和資料量增長，ETL過程越來越長，ETL的視窗越來越短，抽數與正常業務逐漸的交疊在一起
- 因為Greenplum當時的幾個BUG，ETL之後的彙總任務不太穩定，彙總失敗之後的重算，又占用白天的查詢IO，AP業務基本不可用
基于以上原因，考慮從兩個方面解決問題：
- 放棄ETL，改用binlog同步
- 引入專業離線計算工具
綜合考慮當時的情況，決定引入Hadoop，采用HDP分發版本，結合HDF的一些思路，建構一個準實時的資料平台。
大資料的引入
引入Hadoop後，架構如下：
HDP、HDF已成為過去，不再提供連接配接供參考。
資料經過NIFI，采用binlog回放的方式，實時寫入Hbase，定時啟動Spark任務，進行彙總計算，計算結果輸出到GreenPlum中。
整體資料架構的職責劃分如下：
| 技術元件 | 服務能力 | 存儲期限 |
| Mysql（叢集） | 交易（核心） | 1個月 |
| Hadoop | 離線計算、明細查詢 | 全部 |
| Greenplum | 線上分析 | 半年 |
此架構的優勢是：
- 采用binlog回放，不存在ETL過程，對業務庫影響最小
- 采用Spark進行彙總計算，計算性能、穩定性都有大幅度的提升
- 彙總計算和線上分析實體隔離，重算、驗算、模型計算等任務使用Hadoop叢集，不影響線上分析業務的穩定性
- 對于需要實時的業務，采用Flink+Elasticsearch的方式滿足。
但同時這一套架構也有其局限性：
- Mysql的ddl變更，擴縮容非常繁瑣，需要尋找停機時間，也牽扯到大量人工操作
- 資料鍊路過長，實時業務需求存在開發門檻，不能提供實時AP業務支撐
- 部分業務計算完成後，需要回寫Mysql，效率很差，調優空間很小
- 資源需求起點高，部署元件多，運維難度大，運維人員要求高
本身團隊人員少，僅僅維護一個叢集尚能保證可用性，産品複制推廣後，運維和本地開發存在極大的困難。
HTAP+雲原生
在Hadoop引入過程中也在不斷嘗試簡化整個架構。先後研究過cockroachlabs、yugabyte、citusdb等多款分布式資料庫。也閱讀過很多TiDB的技術文章，參考：HTAP 會成為資料庫的未來嗎？。
經過對比，我們認為TiDB比較适合我們：
- 使用Mysql協定，相容Mysql 5.7，遷移成本很小
- 所有的HTAP資料庫中，對接Spark是最好的
- 中文資料詳實、國内支援較好
OceanBase因開源時間較晚，開源時生态并不豐富，對多租戶的模式需求不高等多種原因沒有深入進行相關測試。
引入TiDB之後的架構：
其中：
- 整個架構以TiDB為核心，不再關注分片、無法執行ddl變更、離線擴縮容等等一系列問題
- 輕度的AP工作，不需要額外的ETL動作，擴充TiFlash副本就可以
- Spark上我們做了大量的離線計算的封裝，TiSpark的回寫效率不錯，我們做了一些适配工作，降低了離線計算這一塊的改造難度
- Spark、Api、Presto等我們都跑在了k8s上，極大的降低了計算資源的管理與運維難度
- 從架構上去掉了Flink，是因為Flink原來進行的計算在TiDB能夠通過實時的查詢解決
其中最關鍵的我認為是TiSpark，Spark在離線計算領域的效率、穩定性不可替代。
我們仍然在路上
HTAP+雲原生我們仍然在改造過程中，或許有一些認知錯誤，但HTAP+雲原生這條路給我們的開發、運維都極大地減輕了工作量，我們會不斷走下去。
文章來源：TiDB 社群幹貨傳送門_https://zhuanlan.zhihu.com/p/536517345