01 日常資料管理中的痛點
最近使用者小明遇到了問題，他在一次釋出之後，由于程式bug，導緻核心庫的資料出錯，急需訂正，這個時候小明希望能夠通過某種方式能夠查到這個庫在變更之前的資料，來進行變更的溯源。最後小明通過下載下傳備份集并本地導入的方式查到了資料，但是整體耗費的時間很長，耽誤了問題發生後的最佳止血時間。
事實上，現在很多使用者使用線上庫進行日常的自助取數，資料分析，在這個過程中，我們還遇到了很多其他問題：
● 線上庫查詢的速度慢，對線上業務穩定性有影響。 業務團隊往往有線上去統計資料，做一些簡單資料分析的需求，通常來說，基于本身的技術棧以及對資料的了解，業務同學往往會選擇在線上庫上去查找資料，但是直接線上上庫的查詢資料會有很多弊端：
○ 進行資料分析的需求往往是OLAP類的資料需求，一個分析類的查詢有可能會跨越多張表進行查詢，或者無法很好的命中線上庫的索引，一個查詢有可能會很大，吃掉線上執行個體過多的資源，甚至有可能影響業務庫的穩定性；
○ 進行分析查詢SQL往往運作時間較長，有可能會被線上庫判定為慢SQL并殺掉，導緻無法跑出結果。
● 無法分析曆史資料。在很多情況下，業務團隊往往需要通過去查詢線上庫的曆史資料來對資料進行分析，比如查詢曆史某一時刻的不同品類下的商品規模,不同時期組織架構下的人數等等，此時如果通過資料庫Created字段去區分可能會出現資料有變更，比如可能已經做了組織架構的調整等，導緻無法準确擷取到資料。
● 有資料漂移的問題。在企業有了成熟的資料倉庫之後，業務團隊需要定時将業務庫中的資料抽取到資料倉庫中，如果直接從線上庫抽取則有可能出現資料漂移的問題。
資料庫備份DBS團隊深耕備份領域，負責了整個阿裡雲各種資料庫的備份，沉澱了PB級的使用者曆史時刻的備份資料，備份團隊能否提供一種友善可靠的方式，讓使用者能夠解決上述的問題呢？
02 如何解決上述問題
結合上述對需求的分析，我們抽象出了兩類使用者在使用業務資料庫進行業務分析時常見case，并嘗試解決。
線上庫的查詢需求
在不影響線上庫穩定性的情況下快速獲得資料
使用者對于線上庫的查詢需求的主要在于查詢性能上，用于分析類的需求一般周遊資料較多，無法很好命中索引，是以會有查詢慢，甚至還會影響到線上庫的穩定性。
那麼如果我們通過備份恢複的能力，快速的從備份中恢複出一個按量付費的臨時執行個體來供業務方查詢，這樣就能完美的将OLAP的需求和OLTP的需求隔離出來，解決分析查詢可能會對資料庫造成影響或者被慢SQL殺掉的問題。
甚至更進一步，我們能否一次性很快的克隆出來多個臨時執行個體出來，通過大資料的手段來加速查詢，解決查詢慢的問題，提升使用者的查詢體驗。
曆史資料的查詢需求
能夠快速查詢曆史某個時間點的資料
上述有提到過，使用者在很多情況下，可能需要去查詢各個曆史時間點的資料，比如如下情況：
▶︎ 某使用者由于營運的誤操作導緻關鍵業務庫表資料的部分字段被改髒，希望能夠通過查詢這張業務表的曆史資料，找回被更改的資料；
▶︎ 某使用者最近一段時間各個不同部門下的使用者量，不同品類下商品量/素材量的變化，但是由于使用者的部門，商品的品類是在不斷變化的，是以如果在目前庫通過Created的方式去統計，可能結果會和事實有偏差；
▶︎ 由于業務庫中資料不斷變化，在做年度報告的時候，無法準确撈到年底準确時間點的資料，并且多次查詢的結果由于業務庫資料變化可能會不一緻；
▶︎ 在從業務庫抽取到數倉的過程中，可能會出現資料漂移的問題。
綜上，我們認為，可以基于目前資料庫備份的能力，拉起一個某時刻曆史時刻的臨時執行個體，讓使用者精确擷取到曆史某指定時間點的資料，進行資料的訂正和查詢。
甚至，針對使用者的分析場景，可以提供AS OF語義，讓使用者通過單個SQL能拉到曆史資料的變化趨勢。
綜上，我們可以通過目前阿裡雲的資料庫備份的Point-in-time recovery (PITR)以及快速恢複的能力，提供使用者可以按需使用，用時建立，用後釋放的計算資源，并使用大資料的技術來做資料的merge和分析。來解決使用者進行資料分析過程中的在種種問題。
03 備份資料查詢功能
基于上述的痛點及解決方案，阿裡雲資料庫備份DBS團隊聯合資料管理DMS團隊，共同推出了“備份資料查詢”功能，可拉起曆史時刻的計算資源，供使用者查詢和分析。功能有如下特性：
秒級： 利用雲盤秒級挂載以及本地盤CDM的能力可以很快的拉起臨時執行個體。
按需：僅在有需要時拉起，日常不會有資源的浪費。
自動釋放：DBS會管理所有拉起執行個體的生命周期，在執行個體沒有40分鐘沒有查詢後自動釋放。
基于上述功能，使用者可快速低成本地回溯到執行個體曆史時刻，進行對應的查詢和分析。（查詢備份資料）
如果你是RDS的使用者，你可以看到如下的全量備份時間點清單：
點選「連結」，登入DMS資料管理服務，登入執行個體。
即可看到左側備份資料查詢tab，點開tab之後可以看到執行個體所有的全量備份時間點，點選備份時間點均即可在DMS控制台頁面上發起查詢。
後續會支援直接從RDS頁面跳轉發起查詢，目前，備份資料查詢功能僅支援MySQL引擎，後續會逐漸推廣到其他引擎，并支援曆史任意時刻的查詢能力。
04 舉個栗子
小明是國内某電商平台的使用者，其使用了阿裡雲的資料庫的備份功能，11月8日上午，因為營運動作導緻類目标簽資料被誤改，現在希望找回這些被誤修改的資料。
小明通過RDS控制台備份資料頁面檢視執行個體備份，發現了在11月7号晚上11點有一個備份集，通過查詢這個備份集的資料即可找回資料：
小明通過DMS控制台登入了資料庫，并在控制台的左側找到了備份資料查詢，并選擇了在修改之前最近的一個備份集（11月7日晚上11點）。
輕按兩下展開備份集，成功"穿越"回了昨天，并通過id找到了昨天被誤修改的曆史資料。
通過備份查詢查找到曆史的标簽資訊。
随後使用者在控制台上完成了曆史資料的回溯并訂正了現在的庫。
成功消弭了一場災難。\^o^/
05 未來展望
未來資料庫備份DBS團隊及資料管理團隊會進一步挖掘備份資料的使用價值，在閃回，資料變更軌迹，資料訂正，曆史資料分析等領域為使用者提供更多的可能。