我們在etl測試過程中經常甚至是必須要檢測某一批資料中的某些維度在表範圍內是否重複。
本文就介紹兩種檢測資料重複的簡單方法。
方法1：
sql法
如果這些資料在資料庫中，那完全簡單而且ok。具體方法為：
select (sum(c)-count(c)) uniq
from (
select count(1) c
from table_t
group by col1,col2,....coln
) a
方法2：
linux命令法
有時候，我們得到乙個體積較大的資料檔案（從資料倉儲匯出做別用），想要檢查這個檔案中的某些個字段維度上是否滿足唯一性要求。當然，我們可以將這個檔案導回到資料庫，然後再寫上面的sql語句搞定。但是這樣做難免小題大作了。因為，我們的需求很簡單，而且由於資料檔案較大，搞到資料庫裡對儲存、計算、資源維護都是一種浪費。
現在分量中情況處理：
（1）資料待檢查維度上有序：
我們可以通過如下命令來解決這個問題：
cut -d "[分隔符]" -f [你需要的維度] [你的資料檔案] | uniq -c | grep -v -e '^ \+1 ' | wc -l上面的方法，採用最粗暴的遍歷檔案方法搞定，同樣也是最簡單的，比其匯入資料庫，分配額外儲存空間，建立索引，sql查詢計算等來講簡直是太簡單了。
而且單從sql與linux command執行效率來講，sql中的group by效率不見得比linux command高。
如果我們需要統計所有維度上有無重複資料，則更簡便，方法為：
uniq -c [你的資料檔案] | grep -v -e '^ \+1 ' | wc -l
乙個實際示例：
乙個千萬級的資料檔案進行維度唯一性檢查時，在我的台式電腦上安裝的虛擬機器上（哈哈，性能夠差的）執行大概需要10秒左右的樣子。
（2）資料待檢查維度上無序：
面對這樣的資料，uniq要想發揮作用，則必須在uniq之前進行sort，而對於大資料來講sort是不可行的。
因為無論如何sort也需要nlogn的時間複雜度才能ok，而接著uniq也需要n的複雜度。而且，sort需要將全部資料讀入記憶體。
**稍作修改，count.awk 檔案如下：
begin此時，借助count.awk的功能，實現方案為：else
}end
}
grep -v -e '^$' [你的檔案] | cut -d "[分隔符]" -f [維度] | awk -f count.awk | grep -v -e '^1:' | wc -l
首先去除空行，然後選取需要檢查的維度，傳入count.awk檔案中統計維度上資料出現的次數，最後計算出現不止一次的資料又多少個。
如果結果為0，則說明檢查維度上資料唯一，否則不唯一。
例如，乙個檔案為：
a,b,c
a,c,e
a,b,e
a,c,f
a,d,g
a,e,g
執行上述命令檢查前兩個維度上是否有重複，結果為：
2 --a,b和a,c分別都出現了兩次。
如果檢查全部維度上的唯一性，則上述命令中的 [cut] 部分就可以不用了。
在EO中對資料的重複性進行驗證
只有在資料提交到eo中的時候才會執行set方法進行驗證。如果想要實現實時驗證，可以在輸入引數的地方新增事件，但是無需為此事件建立方法。我的理解 1.我們在頁面上對內容進行修改的時候，oaf框架僅僅是將內容快取到了元件當中，只有當執行了submit處理之後，才會將元件中的值執行vo中set方法提交到v...
兩種attach to process的方法
背景 今天在做keepalive的實驗，設法模擬keepalive不成功的場景，從而達到 the local tcp will keep sending keep alive packet in an interval of keepaliveinterval for tcpmaxdataretra...
兩種attach to process的方法
背景 今天在做keepalive的實驗，設法模擬keepalive不成功的場景，從而達到 the local tcp will keep sending keep alive packet in an interval of keepaliveinterval for tcpmaxdataretra...