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

2021-08-20 15:29:58 字數 1241 閱讀 7061

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

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

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

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

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

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

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

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

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

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

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

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

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

大資料的效能是個永恆的話題。不過,在實際工作中我們發現,許多人都不知道如何進行最簡單的效能估算,結果經常被大資料廠商忽悠 這個辦法我在以往的文章中也提到過,不過沒有以這個題目明確地點出來。其實很簡單,就是算一下這些資料從硬碟上取出來用的時間。除了個別按索引取數的運算外,絕大多數運算都會涉及對資料的整...

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

大資料的效能是個永恆的話題。不過,在實際工作中我們發現,許多人都不知道如何進行最簡單的效能估算,結果經常被大資料廠商忽悠 這個辦法我在以往的文章中也提到過,不過沒有以這個題目明確地點出來。其實很簡單,就是算一下這些資料從硬碟上取出來用的時間。除了個別按索引取數的運算外,絕大多數運算都會涉及對資料的整...

公升級R最簡單最直接的方法

公升級r一直是一件比較痛苦的事情,你需要先安裝新的r,然後在逐一安裝以前裝過的包。最快的辦法也是把以前的包資料夾拷到新的r中,然後在新的版本中執行包更新。由於官方的源一般都提供最新r版本的二進位制檔案,所以為了更好的穩定性一般也要跟著公升級。所以這是一件相對痛苦又不得不做的事情。現在installr...