MaxCompute數倉維護心得-五葉草

在維護客戶基於MaxCompute搭建的數據倉庫時，我們遇到過一些問題，踩過一些坑，同時積累了一些經驗，也初步形成了一套操作流程規範，在這裏與大家以Tip的形式與大家分享一下。

Tip1.避免同步視圖

同步的源數據要避免使用視圖，在客戶的生產環境上曾經出現過這樣的情況：由於生成視圖的存儲過程優化不好，同步視圖在同步任務發起請求後很久沒有生成出來，導致同步任務及後續的ETL掛起達數小時之久，所以後續和數據提供方接洽，將數據源從視圖換為表，保證在同步之前同步表裏的內容已經更新。

在測試環境下，通過修改數據集成中的同步任務實現數據源從視圖切換成表。再確認不同的數據源的表數據結構完全一致之後，修改如下同步腳本中的table值為新的表名。

100562c002dda61b4073106b2d80cde29a3463fc

由於在同步腳本裏truncate字段為true，所以再次同步數據時該分區內的舊數據會被擦除，在修改之後可以直接通過補數據節點得到新數據源裏的數據，同時該節點之後的節點也需要重跑，確保所有任務數據的正確性、一致性。

核對數據也是保證修改前後數據正確性、一致性的辦法之一。核對主要是與數據提供方核對數據。這裏以驗證銷量數據為例，雙方核對的標準如下

客戶編碼Code	客戶姓名Name	年月 BILL_DATE	數據行數	銷售數量PROD_QUANTITY	銷售金額 PROD_AMOUNT

如果連續一周與數據提供方的數據一致，那麼可以認為數據源修改成功

Tip2.Maxcompute數據同步到AnalyticDB

AnalyticDB常常作為MaxCompute與QuickBI之前的數據加速層，那麼MaxCompute到AnalyticDB的數據同步就是必須的。按照通常的數據集成操作來配置，我們可以建立一個數據同步任務，但是當我們嚐試運行這個同步任務時就會發現任務運行失敗。

0f7a4eb1855a9d96bc21e0a3aa6859813b463962

起初在授權策略、網絡方麵查錯，但是依舊沒有解決問題。最終了解到MaxCompute到AnalyticDB的數據同步必須進行下麵的操作：

由於使用的公有雲，要將 garuda_build@aliyun.com 和 garuda_data@aliyun.com兩個公用雲賬號添加到MaxCompute的工程中：

ADD USER ALIYUN$garuda_build@aliyun.com;
ADD USER ALIYUN$ garuda_data@aliyun.com

在添加賬號之後需要將Describe,Select權限賦給這兩個賬號：


GRANT Describe,Select ON TABLE rpt_outlet_report_daily_april  TO USER ALIYUN$garuda_build@aliyun.com;
GRANT Describe,Select ON TABLE rpt_outlet_report_daily_april  TO USER ALIYUN$garuda_data@aliyun.com;

之後再運行這個同步任務，發現同步成功！

Tip3.數據刪除

數據提供方對上個月的曆史數據進行了修改，刪除了部分不符合業務邏輯的數據，為保證數據一致性，我們也需要將這部分曆史數據刪除。由於數據同步是增量的，每天隻同步變更日期大於{bdp.system.bizdate}的數據，並用這部分數據替換掉全量數據裏的舊數據。數據更新的示例代碼如下，其中dwd_dummy_data為全量基礎表，存放全量數據；ods_dummy_data為增量同步表，存放今天的增量數據，ds為分區列

3788b365a72d74b45551290a663bc9af6c589813

由於數據提供方已經沒有不符合業務邏輯的數據，那麼每日的同步數據一定是符合業務邏輯的，所以並不用做數據刪除。那麼需要刪除的數據就在全量數據中，即示例中的dwd_dummy_data表中。從示例代碼可以看出數據更新隻使用到分區為兩天前的全量數據，所以更新所有分區的的全量數據是沒有必要的，但是同時也說明了數據刪除操作必須在數據更新任務觸發時間前完成，否則完成刪除操作的數據全量數據並不會用於新一輪的數據更新。

在明確了這些注意點之後，我們在測試環境中對要進行操作的分區的數據進行備份，方便回滾。由於MaxCompute沒有update操作，我們通過insert overwrite來實現數據的刪除，下麵以刪除dwd_dummy_data表中col3小於1000的數據為例，實現的邏輯如下

ee5668f9b141989fc18624457d91236fd4a07cc6

注意在where中限定分區列ds，否則將會插入所有分區中符合條件的數據，產生重複數據。

同樣的，數據刪除之後也需要和數據提供方核對數據。一旦數據差異較大時，且問題無法短時定位時要及時回滾數據，即將備份的數據重新插入到操作的分區，同時保留操作時的腳本，用於和數據提供方核查數據刪除邏輯。當確定沒有修改ETL腳本時，重跑對應業務日期的任務也可以實現數據回滾。

在確定刪除邏輯正確，數據可以核對上之後，就可以對生產環境上的數據進行操作。操作時需要通知客戶操作的開始時間、預計的操作時長、操作的表、操作的邏輯，如果可能造成影響比較大，也要將可能的影響告知客戶。在客戶郵件同意之後方可進行操作。同樣的，在測試環境操作時的一切準則在生產環境同樣要遵守，在連續數據核對一周之後，如果數據沒有差異那麼操作完成，相關的操作、操作日期、操作人員需要記錄下來。

Tip4.ETL腳本修改

ETL腳本修改的準則與數據刪除進本類似，但要記得將修改前的腳本備份。另外，對腳本盡量小的改動。舉例來說，比如要A字段的值由其他字段依據某些邏輯生成，後麵改動時需要將A字段為特定值的數據過濾掉，我們可以選擇在生成邏輯裏麵進行修改，但是這樣可能對原來的邏輯產生影響，於是可以在不顯著影響執行效率的情況下，考慮再加一層select查詢，同時用where限定條件過濾掉數據。

修改完成之後，在腳本的頭部注釋上添加Modify信息，例如下圖：

75668d5295855291b7c7dd8430664a7c1a850234