經驗之談 - 教你如何驗證結果 (Check數)
當筆者在以前和到今天的工作中，處理過不少的Report，無論在Excel，網頁的，在製作的方式和介面會有些少不同，但在數學上和經驗上都是共通的。有時候筆者都很迷惘，到底自己做的結果到底是否正確，尤其已經把整個過程自動化，反而會令自己忘記某些的Special Handling或更detail level的設定，就算記得的話，也不可能每一條記錄都跑去做驗證，這太浪費人力物力了。那麼應該用什麼的方法去做Checking呢？我會有這樣的看法：
Back to the Basic，我們做一個報表的時候是先由一組的Records開始，例如每月交易的記錄，都是由買家和賣家雙方交易的資料所紀錄下來，而Report中的當月的交易量，其實是由所有的交易量的總和。只要把所有的交易量加起來，看看跟答案是否一致，別看不起這個驗證方法，因為有時你把交易量加起來不一就是Report的總數，因為建立一個報表可以涉及複雜的程式運算，尤其是那個報表不是由自己Build的工具Generate出離，當你根本不知道裡面的程式搞什麼鬼的時侯，這個驗證方法往往讓你能了解該程式的運作。
而現實中，一個量值可以包含多個維度(Dimension)，即是交易量也可以有兩個維度，也可以N個，視乎你的數據有多少的維度。假設我們的數據只包括交易量和業務種類，而業務範圍包括黃，賭，毒三種（免責聲明：本文並非宣傳任何不良的意識）。一個非常簡單的問題：如果計算總交易量？很明顯就是把黃，賭，毒的交易量加起來完事了。對，但是如果加起來發現跟總交易量不同的話，那是什麼玩意了？你可能會覺得不可能發生，但現實上偏偏出現在一些Mapping不完整的問題，很多時候我們有的數據的資訊未必足夠，例如在交易記錄中，若果沒有業務種類的話，我們只有從業務活動中，推敲出那是什麼的業務總類，只需要一個Mapping的Table（看下表）便能達到這個目的。
回到剛才的問題，為何加起來的交易量，原因其實很簡單，就是剛才的Mapping遺漏了某些業務活動，導致沒法分類為黃，賭，毒那一個種類。所以正確的交易量是由黃，賭，毒再加上一些未能分類的業務活動的交易總額：
$$Amount_黃 + Amount_賭 + Amount_毒 + Amount_? = Amount_All $$
由此，當我們想驗證結果保證這些Mapping沒有任何錯漏的時候，我們可以利用檢查所以有值的總和，令結果更準確無誤，這個技巧我們廣東話俗稱"夾大數"。這個方法的主要好處就是讓你要檢查的範圍縮少，不用來重新檢查每一項記錄便能找出問題的根源，大大節省了時間成本，假若發現黃，賭，毒的交易量總和不同於當月交易量，那就明顯是Mapping的問題，直接找出那個活動遺漏了就可以了，不用在每一項記錄找錯處。
第二種的方法，就是利用Common Sense去觀察結果的合理性，假設我們有賣方的資料，其中我們會用賣方所得的收益除以交易金額，從數學上來看這是一個比例 (Revenue / Transaction Amount)，兩個正數的比例也必定是正數，若果我們發現這個比例是一個負數的話，那麼，憑著Common Sense也知道這是錯誤的結果；另外，在Business的角度出發，收益是交易金額再減去成本，Revenue = Transaction Amount - Cost，所以收益是永遠等於或少於交易金額，當它們相除的時候一定會少於或等於1，若果結果是大於1的話，請砍掉重練吧。來到這裡，相信讀者們都會有一個疑問：那有時間檢查每一項記錄，要解決這個問題，先從你的工具開始，Excel的用家可以conditional formatting或者formula來檢查，Database Administrator可以用SQL等資料庫語言Filter和回傳這些錯誤記錄，達到自動偵錯的效果。對於一些Ad hoc的任務，這方法省時，還讓你有更多時間去忙其他事情。
很多公司常說什麼Big Data，但自己還在擁抱著Excel, Access，連RDB的系統也沒有，他們很喜歡在面試的時候問你，過往的工作經驗中，曾處理的數據量有多少。我的看法是，貴公司如果還在用Excel, Access這些工具的話，數據量根本不是一個問題，更沒有資格說什麼Big Data，如果數據量太大的話，早就利用Hadoop或者Spark來處理，還輪到Excel出場嗎？況且在Reporting的世界，數據的多寡不會影響你的計算結果，只會影響你的速度，至於速度的話，就算不強化演算法，直接增大CPU或者平行運算就已經解決了，但要驗證你的結果，便要採用剛才所討論的方法，根本不用理會數據量，所以學會這些技巧基本上，會讓你在看數字的時候更有觸覺，更容易知道得出的結果是否合理和現實相乎，先從奇怪的結果出發，再推敲那些地方出了錯，這會大大的節省花在驗證結果的時間。
就算當下以為自己的方法是對的，但最後的結果可能並不是你想像中的。
《賭場風雲》電視截圖
Back to the Basic，我們做一個報表的時候是先由一組的Records開始，例如每月交易的記錄，都是由買家和賣家雙方交易的資料所紀錄下來，而Report中的當月的交易量，其實是由所有的交易量的總和。只要把所有的交易量加起來，看看跟答案是否一致，別看不起這個驗證方法，因為有時你把交易量加起來不一就是Report的總數，因為建立一個報表可以涉及複雜的程式運算，尤其是那個報表不是由自己Build的工具Generate出離，當你根本不知道裡面的程式搞什麼鬼的時侯，這個驗證方法往往讓你能了解該程式的運作。
而現實中，一個量值可以包含多個維度(Dimension)，即是交易量也可以有兩個維度，也可以N個，視乎你的數據有多少的維度。假設我們的數據只包括交易量和業務種類，而業務範圍包括黃，賭，毒三種（免責聲明：本文並非宣傳任何不良的意識）。一個非常簡單的問題：如果計算總交易量？很明顯就是把黃，賭，毒的交易量加起來完事了。對，但是如果加起來發現跟總交易量不同的話，那是什麼玩意了？你可能會覺得不可能發生，但現實上偏偏出現在一些Mapping不完整的問題，很多時候我們有的數據的資訊未必足夠，例如在交易記錄中，若果沒有業務種類的話，我們只有從業務活動中，推敲出那是什麼的業務總類，只需要一個Mapping的Table（看下表）便能達到這個目的。
業務種類
|
業務活動
|
黃
|
妓院
|
賭
|
百家樂
|
賭
|
麻雀
|
毒
|
白粉
|
毒
|
大麻
|
回到剛才的問題，為何加起來的交易量，原因其實很簡單，就是剛才的Mapping遺漏了某些業務活動，導致沒法分類為黃，賭，毒那一個種類。所以正確的交易量是由黃，賭，毒再加上一些未能分類的業務活動的交易總額：
$$Amount_黃 + Amount_賭 + Amount_毒 + Amount_? = Amount_All $$
由此，當我們想驗證結果保證這些Mapping沒有任何錯漏的時候，我們可以利用檢查所以有值的總和，令結果更準確無誤，這個技巧我們廣東話俗稱"夾大數"。這個方法的主要好處就是讓你要檢查的範圍縮少，不用來重新檢查每一項記錄便能找出問題的根源，大大節省了時間成本，假若發現黃，賭，毒的交易量總和不同於當月交易量，那就明顯是Mapping的問題，直接找出那個活動遺漏了就可以了，不用在每一項記錄找錯處。
第二種的方法，就是利用Common Sense去觀察結果的合理性，假設我們有賣方的資料，其中我們會用賣方所得的收益除以交易金額，從數學上來看這是一個比例 (Revenue / Transaction Amount)，兩個正數的比例也必定是正數，若果我們發現這個比例是一個負數的話，那麼，憑著Common Sense也知道這是錯誤的結果；另外，在Business的角度出發，收益是交易金額再減去成本，Revenue = Transaction Amount - Cost，所以收益是永遠等於或少於交易金額，當它們相除的時候一定會少於或等於1，若果結果是大於1的話，請砍掉重練吧。來到這裡，相信讀者們都會有一個疑問：那有時間檢查每一項記錄，要解決這個問題，先從你的工具開始，Excel的用家可以conditional formatting或者formula來檢查，Database Administrator可以用SQL等資料庫語言Filter和回傳這些錯誤記錄，達到自動偵錯的效果。對於一些Ad hoc的任務，這方法省時，還讓你有更多時間去忙其他事情。
很多公司常說什麼Big Data，但自己還在擁抱著Excel, Access，連RDB的系統也沒有，他們很喜歡在面試的時候問你，過往的工作經驗中，曾處理的數據量有多少。我的看法是，貴公司如果還在用Excel, Access這些工具的話，數據量根本不是一個問題，更沒有資格說什麼Big Data，如果數據量太大的話，早就利用Hadoop或者Spark來處理，還輪到Excel出場嗎？況且在Reporting的世界，數據的多寡不會影響你的計算結果，只會影響你的速度，至於速度的話，就算不強化演算法，直接增大CPU或者平行運算就已經解決了，但要驗證你的結果，便要採用剛才所討論的方法，根本不用理會數據量，所以學會這些技巧基本上，會讓你在看數字的時候更有觸覺，更容易知道得出的結果是否合理和現實相乎，先從奇怪的結果出發，再推敲那些地方出了錯，這會大大的節省花在驗證結果的時間。
Comments
Post a Comment