457
ComputeColStats UDF中 近似算法的介紹(續)
在前一篇文章的最後提到，對於準確率的提升是後續需要做的事情之一。接下來看看對於提升準確率，還有哪些事情可以做。
一，回顧
首先回顧下前一篇文章最後得到的結果，如下：
執行時間先忽略，隻看準確率。對於上麵８個字段，有些在sample為２５（采樣比例１／２５）的情況下還是相當準確的，比如odps_task_type，start_time；而有些則存在一定差距，比如project_name，fuxi_ceil_mem等；還有些存在比較大的差距，比如odps_inst_id，fuxi_avg_cpu。同樣的采樣算法，同樣的估計算法，對於不同的數據會得到截然不同的結果。這種差異相信決大部分來自於數據本身。
下麵就從數據本身來看下到底差異是如何出現的。
二，數據差異
不同的字段存儲的數據不同，不同數據可能會存在唯一值上的差異。比如說對於主鍵，比如說對於緯度直，兩者肯定在DistinctValue的分布上肯定是完全不同的。
1，如果該字段為主鍵，那麼RowCount（X軸）和DistinctValue（Y軸）關係類似下圖：
這是一條斜率為1的直線。
對於這種情況，目前的算法肯定可以非常準確的估算出DistinctValue值。
2，如果該字段為緯度值（唯一值非常少），那麼RowCount（X軸）和DistinctValue（Y軸）關係類似下圖：
隨著RowCount的增加，DistinctValue也在增加，但到了某個點後DistinctValue基本保持不變。
3，如果該字段為一般字段，隨著RowCount的增加而DistinctValue也緩慢增加，類似下圖：
三，數據差異導致的DistinctValue的計算誤差？
上麵一部分列舉了三種可能的RowCount和DistinctValue關係。第一種類型是比較簡單的，也能很準確的估算出DistinctValue值。而對於第二種和第三種則要困難的多，從測試的結果來看是這樣的。
我們采樣的前提是，采樣算法能保證采樣是隨機的，每條數據被訪問的幾率是相同的。但實際上這樣的前提是不存在的。這也是目前對第三種的估算也可能存在較大差異的原因。因為按道理來說，其實第三種我們也應該能很好的預估才對。目前的采樣算法並不是隨機的，數據本身分布對采樣的結果影響極大。為了性能和實現起來簡單，目前采樣的算法是隔n條取1條的方式實現的，並不是真正意義上的隨機采樣。
針對同一次估算過程，我嚐試過不同的擬合回歸算法，結果並沒有特別的不同，問題並不是在算法上，而是在數據本身上。下麵通過對存在較大誤差的fuxi_avg_cpu來看下，不同的采樣比例下的RowCount和DistinctValue關係的差異。
上麵幾張圖對下對比，能看得出來在不同的采樣比例下圖形的狀態會有很大的變化。差異這麼大的話想要比較準確的預估顯然是不太現實的。
四，總結
目前看來DistinctValue估算的差異大部分原因是因為采樣，想要提高準確率增加采樣比例就可以了。而具體回歸的算法，則沒那麼重要了。
最後更新：2017-07-25 11:02:50