近期有發現一些使用者在咨詢，為什麼資料從資料源出來後，經過了一些計算，結果不符合預期了。最常見的是說，為什麼我的資料在mysql裡有xx條，怎麼到maxcompute裡算了下結果變了。因為這是兩個不同的系統，我們又沒辦法拿兩邊的記錄直接做個full outer join看看少的是哪些資料。本文拿2個實際的例子，做了簡化友善了解，給出排查過程，希望能給大家帶來一些思路。
這是一個常見的場景，為什麼我資料同步過來後，就直接用sql做了count，結果就不對了。
先在mysql裡建立一張使用者表，并插入一些資料：
然後在maxcompute裡配置了個接受的表：
然後配置了一個同步任務和sql任務用于統計結果資料條數如圖：
最後做成工作流
任務上線後，跑了第一天，結果還是對的。
但是第二天插入幾條新的資料後，為什麼統計結果就不對了呢：
預期的是第二天的資料是4。
我們需要先理清楚資料的走向。這個例子的思路很簡單，資料從mysql同步到maxcompute的表裡，然後針對結果表做了彙總。走向圖為myuser(mysql)=>ods_user(maxcompute)=>dws_usercnt(maxcompute)。
目前我們通過在mysql裡查詢，已經确認mysql裡就是4條記錄，dws_usercnt裡的結果也看到是6，那需要先定位到是ods_user裡的結果是多少條，進而定位到是同步的時候出現的問題，還是同步後彙總出現的問題。
我們先看了一下ods_user，先用<code>select count(*) from ods_user;</code>看到為6。因為是分區表，對麼個分區查一下，用<code>select count(*) as cnt,ds from ods_user group by ds;</code>，發現結果是
然後配合同步任務的日志
我們可以看到，我們一共同步了4條資料（<code>如果是這裡對不上的話，我們需要檢查一下同步任務的where表達式對不對了</code>）。然後最後彙總的時候，我們看下日志：
我們可以看到我們在sql裡是通路了2個分區的資料做了彙總。
是以這個問題的原因是在同步的時候，是做了每天的全量同步，但是在sql彙總的時候，當成是增量同步了，或者是忘記寫分區的過濾條件了，導緻彙總是查詢了全部的資料。針對這個問題的解法是先要确定這個表到底是需要增量同步，還是需要全量同步。如果是需要增量同步，那需要修改同步的時候，在配置項裡配置過濾條件隻同步增量資料。如果是需要每天同步全量資料，那在彙總的時候，就隻需要讀最後一個分區就可以了。
有一些使用者希望針對資料的某個屬性進行分區，比如希望根據學生的年級進行分區。
我們先在mysql裡建立一張學生表，插入一些資料
同樣的，在maxcompute這邊也需要配置一個ods表和一個dwd表
然後配置一個同步任務:
和對應的sql任務
同步後看到第一天的結果是對的。
後來這些學生都到了新年級了，3年級的學生畢業了
再同步一下，不對了，資料怎麼還是3條。
我們這裡測試的資料比較少，可以直接select出來一看就明白了。但是真實的業務裡，我們的資料可能有數以億計，根本沒辦法肉眼看出來。是以還是以前的思路，我們先理清楚資料的走向。資料是從student（mysql）=>ods_student（maxcompute）=>dwd_student（maxcompute）。
第二天，mysql裡的student表裡資料其實是隻有2條了。而ods_student表裡的最新的分區也是2條。但是dwd_student裡是3條。這說明ods=>dwd的過程中，資料出了問題。這個就是一個sql問題了。我們用sql
看到1年級，資料裡ods表裡沒有1年級的資料了，但是dwd裡還是有1條1年級的資料。這下就很清楚了，這條資料是第一天的資料。後來升了年級後，用insert overwrite覆寫寫入的時候，2年級和3年級是有新資料進來的，是以資料被覆寫了。但是1年級因為沒有資料進來，是以也沒覆寫。我們也可以用desc partition指令看下每個分區的建立時間和修改時間來确認這個問題。
對于這種情況，其實這種分區方法有一些問題的。建議dwd表裡不要做這樣的分區。如果确實需要分區，也不要直接在曆史分區上做覆寫寫入，可以寫到新的分區裡，比如做2級分區，1級分區是日期字段，二級分區才是這樣的業務分區字段。
如果有問題，可以加入我們的釘釘群來咨詢