羅瑞星，易果集團數據架構專家，TiDB User Group (TUG) 上海區 Leader。
TiDB的應用
易果集團的實時數倉其實很早就已經存在了，在業務量還沒有那麼大的時候，當時我們只用了一臺SQL Server就能夠滿足需求了，因為數據量不大，所以存儲過程一般也就1-2分鐘就能跑完，同時也能夠保證實時和T+1數據的一致性。
回過頭來看，這樣做的好處也顯而易見，一臺機器比較好維護，在數據量不大的時候還是非常適合的，但是一旦碰到大促或者搞活動的時候一些存儲過程就非常容易裝死了，有時候可能碰到30-40分鐘才能跑完的情況。
隨著業務的增長，在易果集團離線的部分已經由SQL Server切換成了Hadoop，實時的部分也需要一套能夠滿足未來業務增長的系統，根據業務和技術方面的綜合選擇，我們最終選定了TiDB+TiSpark的方案。基於此方案有幾個比較明顯的優勢：
由原來的存儲過程改成SQL相比於改成代碼的成本是非常小的，能夠
大大的節省改造成本；因為在之前的系統中使用了存儲過程，大部分存儲過程都比較負責，有很多update和delete等的操作，使用了TiDB這套方案之後依舊能夠保證實時和離線的一致，減少了很多的解釋成本；
顯而易見的是，由SQL Server到TiDB，從單機變成了分佈式，性能得到了提升，基本上很少會發生一個腳本30分鐘的情況了。
需要提到的是，我們在選型的時候有一個很重要的原因是因為有TiSpark這個項目，當時TiDB還是非常早期的版本，不像現在3.0有很大的提升，得益於TiSpark這個項目，能夠提供給分析師進行復雜分析的可能。
另外之前也說了，我們的離線集群是基於Hadoop的，這樣有了TiSpark之後，能夠用Spark統一引擎，等到未來TiSpark支持回寫之後，我們就基本可以做到一套腳本兩個集群通用了。
易果集團基於TiDB的實時數倉架構圖如下：
TiFlash和數據中臺
這一套架構雖然很方便，但是同樣也存在一些問題，最顯而易見的就是AP和TP互相干擾，這在初期是HTAP系統無法避免的問題。在18年的時候TiDB就提出了TiFlash的項目，這個項目目前的資料很多，這裡也就不做過多介紹了。TiFlash的出現在物理上隔離了AP和TP的需求，從根本上解決了AP和TP衝突的問題，使得TiDB往HTAP更近了一步。
我們是在18年的時候開始進行一些性能和功能上的測試，初步找了一些數據量大但是場景比較小流量也比較小的場景進行了測試，整體測試效果比較滿意，目前已經有一小部分場景的部分流量在正式環境中運行，對於年底的正式版本還是相當期待。
TiFlash是從物理層面解決AP/TP衝突，18年開始，數據中臺的概念非常火熱，從另一個角度看，從中臺角度出發，也需要有一些管理手段來緩解AP/TP的衝突。
下圖是Hadoop和TiDB ETL過程的簡單對比，從圖中可以看出，Hadoop的ETL多是基於表為單位的，這樣對於資源的影響相對而言比較小，影響範圍不大，即使出現一張表不使用的情況，對於資源的利用率可能也不會立即體現。
而以TiDB的ETL過程大多是以實例或者DB為單位的，通過DM或者Syncer把MySQL同步到TiDB，這樣做非常節省時間，但是相比於Hadoop的ETL，如果出現大部分數量不使用或者數據情況糟糕經常變更的情況，對於資源就會產生一定影響。
基於此，不管是Hadoop還是TiDB，所有的同步都應該有一個數據編目。數據編目項目是屬於數據中臺的一部分，該項目由業務中臺或者前期由DBA進行主導，初步評估數據的可用性，同時也維護數據一定的業務屬性，只有在數據達到一定標準了之後，後面的大數據部門才能夠去接入數據。同時也配合OneData以及數據接入流程，來進一步管控指標，表，任務的對應關係，方便對資源進行管控。
最後TiDB也是OneService的重要出口，OneService在易果是數據部門對外提供統一接口的服務，目前主要提供的是Restful的接口，在接口系統裡，我們對每個系統都做了業務屬性和責任人的管理，同時在當前版本中也有接口版本的管理，業務方只需要在頁面上按照步驟配置就能夠生成一個可用的接口，在後續的計劃中，我們還準備加入接口的判重機制，避免出現重複接口的現象。
隨著數據中臺概念的提出，企業越來越重視數據的價值，數據雖然消耗著傳統意義上的資產，但是數據也同時作為企業資產的一部分。因此，數據需要越來越精細化的管理，從接入到用起來，從用起來到能夠充分利用，每一步都需要付出很多探索。
未來
HTAP、NewSQL等系統的出現，不僅解決了業務上一些分庫分表等問題，也慢慢的影響到了大數據領域，在未來，大數據也會慢慢和NewSQL進行融合，越來越像一個完整的數據庫。
作為一個HTAP系統，會有各種角色的人去維護管理或者使用系統，每個人關注的點可能也不太一樣。
對於傳統DBA比較關注穩定和性能；大數據的工程師除此之外還會關注任務的效率，每個任務的資源佔有率；
-
建模工程師會根據分析師的使用情況去調整模型，判斷模型的好壞；
而分析師則希望能夠易用方便等等。
每個角色關注的點不一樣，那麼所需要做的監控除了平常的性能監控以外，用戶向的監控也越來越會受到關注，更不要說安全管理，資源的自動化管理等。相信隨著中臺的不斷髮展，TiDB的逐步進步，這些涉及到數據的方方面面都會都會得到提高和完善。
>>>>
活動推薦
11月15日，廣州：Gdevops全球敏捷運維峰會 將舉辦2019年度收官盛會，重點圍繞智慧運維、DevOps、數據庫領域，攜手阿里、騰訊、京東、螞蟻金服、新浪微博、甜橙金融、聯通大數據、微眾銀行、貝殼找房、新炬網絡等技術代表展開年度技術總結與發展趨勢展望，掃碼汲取全年技術精華。
閱讀更多 dbaplus社群 的文章
