數據歸檔那些事兒

時間 2019-11-07

標籤數據歸檔那些事兒简体版

原文原文鏈接

在熱點帳戶問題和經常使用解決方案【中】這篇文章中提到，解決熱點讀性能的一個很是通用方式是數據歸檔。本篇小拽總結下在操做數據歸檔過程當中遇到的一些問題和經驗！

1、數據歸檔

所謂數據歸檔就是把部分低頻訪問的歷史數據從線上庫遷移到歸檔庫的過程。在設計數據歸檔方案的時候一般須要思考三個問題網絡

歸檔前：如何進行存儲選型
歸檔中：如何保證遷移準確
歸檔後：如何處理數據完整性破壞所引發的問題

下面也着重從這三部分來聊聊運維

2、存儲選型

存儲選型是歸檔前要作的最重要的一件事情，目前市面上的存儲方式多如牛毛，如何選擇可以支撐當前業務環境的存儲選型，就很是重要！分佈式

2.1 歸檔的數據特色

既然是要選型數據歸檔的存儲，首先來須要梳理下歸檔數據的特色性能

讀性能：歸檔數據對讀性能沒啥要求，可以讀出來就能夠
寫性能：儘量好的批量寫入性能，可以批量1w+達標
壓縮比：儘量的節省空間，採用高壓縮比的存儲引擎
分佈式：最好可以分佈式，考慮到目前單片都40T了，非分也可
數據量級：上限盡量高，考慮到實際狀況，10TB+目前達標
一致性保證：歸檔是兜底，儘量高的保證數據不會出現異常丟失

2.2 通用選型因素

除了考慮歸檔數據的特色，還要考慮一些通用因素，例如ui

公司是否運維支持：大廠這個因素很重要，若是運維支持背書，最好不過！
開源活躍程度：活躍度過低不能選
廣泛使用場景：跳出存儲給的通用場景的不能選

2.3 備選存儲的特性

也初步總結和梳理了下可能用到的集中存儲的特性spa

結合歸檔數據的特色和不一樣存儲的優點，最終選用了.net

rocksDB：做爲存儲歸檔數據引擎，性能和數據壓縮比都不錯，最主要是公司DBA願意支持
ES：做爲在線查詢，公司運維支持
HIVE：做爲財務數倉核心數據和全量數據中心，哈哈，爲下一篇財務數據中臺作鋪墊^_^
fusion：做爲冪等健破壞後的冪等健KV池

3、一致性保證

歸檔過程存在會刪除線上數據，是個很是高危的操做，因此操做過程當中和操做以後都須要特別注意數據一致性的保證。設計

對於操做過程的一致性保證相對簡單，過程一般兩步
step1 插入確認：查詢線上庫->插入歸檔庫->查詢歸檔庫->確認插入
step2 刪除確認：刪除線上庫->查詢線上庫->確認刪除
注意：過程當中儘量的保證讀取和寫入的時間，刪除會鎖庫，大批量讀會搶網絡和IO，防止對線上業務形成壓力，儘量調優批量數據，推薦條目在200-1000條一次，數據量在5M-100M一次code

4、歸檔後問題

數據歸檔後，必然破壞了數據的完整性，會形成下面幾個問題,，須要提早考慮blog

4.1 讀數據穿透問題

低頻歷史數據歸檔後，形成線上數據缺失，查詢數據穿透和範圍關係查詢損失都會存在。所以，數據歸檔後，對於讀操做有兩種處理方式

歸檔數據不讀：最簡單，可是對於某些場景可能確實不太合適。
讀proxy兼容：經過讀proxy，穿透性的選擇各類存儲截止。

針對讀數據，還有一種比較特殊的狀況，就是跨區間範圍關係聚合，這樣就須要有一份完整數據來知足極端需求，目前財務系統對於這類需求統一走離線財務數倉來解決！

4.2 寫冪等破壞問題

對於寫數據最大的問題就是冪等健被破壞，歸檔了數據後，rds寫入惟一健破壞，在極端狀況下，可能會形成duplicate。考慮到問題的出現機率和實現成本，初期能夠忽略，採用人工干預的方式，歸檔最終要寫入全量，寫不進去就是duplicate了；後面能夠採用前置冪等健組來擋，作到最終一致！

4.3 數據一致性問題

不管是數倉數據仍是歸檔數據，做爲財務數據，一旦提供資金服務，那麼就必須保證強一致性，財務目前採用離線分天統計數據的金額和數量，來保證宏觀上的一致性。這裏面也有須要小坑，例如數據飄移，時間gap等，關於財務數倉中遇到的坑和解決方案，後續專項討論

5、最終歸檔方案

分析了歸檔前選型，歸檔中數據轉移，歸檔後數據完整性問題，初步的歸檔方案以下圖

簡單梳理下核心流程

寫數據流：寫數據寫入online rds[備註：目前沒有前置冪等攔截，後面擇機完善]，寫入後經過binlog準實時寫入es，提供線上讀服務；經過binlog小時級入hive，做爲分析數據和全量數據存儲；經過天級歸檔腳本，將歷史數據導入rocksdb歸檔。同時，若是有日切，也會天級進行數據日切和新表建立。
讀數據流：讀數據過proxy，非歸檔期間數據直接讀取es，歸檔數據和es沒有的數據都會穿透到rocksdb。
監控流：天級監控hive，es，rocksdb，三個不一樣來源的數據條目和總金額，保證一致性。