最簡單的大資料效能估算方法

大資料的效能是個永恆的話題。不過，在實際工作中我們發現，許多人都不知道如何進行最簡單的效能估算，結果經常被大資料廠商忽悠:)。

這個辦法我在以往的文章中也提到過，不過沒有以這個題目明確地點出來。

其實很簡單，就是算一下這些資料從硬碟上取出來用的時間。除了個別按索引取數的運算外，絕大多數運算都會涉及對資料的整體遍歷，比如分組匯**計、按條件查詢（非索引字段）；那麼，這些運算耗用的時間，無論如何不可能小於硬碟訪問的時間，我們就能算出乙個理論上的極限值。

比如，有人宣稱實現 10t 資料的 olap 彙總只需要 3 秒。那麼這意味著什麼呢？

常見的 15000 轉硬碟，在作業系統下的訪問速度也就不到 200m/ 秒，ssd 會快一些，但也沒數量級的提公升，大概 3 秒讀 1g 的樣子。這樣，從單塊硬碟中讀出 10t 資料就需要 30000 秒以上，如果想在 3 秒內完成彙總，那就需要 1 萬塊硬碟！作為使用者，你是否做了這個準備呢？

當然，硬碟及硬碟在不同環境下的速度不盡相同，可能更快或更慢，但總之都可以用這個簡單的辦法去估算。不知道自家硬碟的速度？那弄個大檔案讀一下試試就知道了，拿到實驗資料再去計算會更準確。要強調的是，不能簡單地看硬碟廠商標稱的效能指標，在檔案系統下，那個理想值常常連一半都達不到，還是實測的最可靠。

這樣，我們就能知道某個大資料問題最理想的情況能夠達到什麼效能，比這個指標還好的期望，在用於估算指標的硬體條件下都是不可能實現的，沒有必要再去琢磨軟體產品和技術方案了。

這種估算也指明了乙個優化方向，就是減少儲存量和訪問量。

減少儲存量當然不能減少資料本身，用於計算的資料一條也不能少，否則就出現錯誤結果。減少儲存量要靠資料壓縮的手段。10t 的原始資料，如果有好的壓縮手段，實際在硬碟上儲存下來可能只有 1t 甚至更少，這時候 3 秒彙總這些資料就不再需要 1 萬塊硬碟了。

在儲存量不能再減少的情況下，還有些軟體手段來減少訪問量，常用的方法就是列存。乙個資料表有 100 列佔了 10t，如果只訪問三列進行彙總，那大概只需要訪問 300g 資料，這時候 3 秒完成彙總當然也不需要 1 萬塊硬碟了。

不過，大資料廠商在宣稱 10t、3 秒這種效能指標時，一般不會明確指出採用壓縮或列存技術後儲存量和訪問量能降到多少。這就容易給使用者造成錯覺，以為這個技術能夠通用地解決大資料問題，而經常，有些資料的壓縮率無法做得很高，對於訪問列較多的運算列存也沒啥優勢。

要更準確地估算效能極限，也要考慮減少儲存量和訪問量的手段。嘗試一下自己的資料能有多大的壓縮率（用常規的 zip 軟體就可以），並且檢查運算是否是從很多列中取出很少列的情況。