資料蔣堂 | 資料分段討論

資料派THU發表於2018-01-19

640?wx_fmt=png&wxfrom=5&wx_lazy=1

來源:資料蔣堂

作者:蔣步星

本文共1600字,建議閱讀5分鍾。
本文和大家討論了關於資料庫怎麼高效的將資料分段。


640?wx_fmt=png&wxfrom=5&wx_lazy=1



現代計算機一般都有多CPU核,而日益廣泛應用的固態硬碟也有較強地併發能力,這些硬體資源都為平行計算提供了有力的保證。不過,要實現平行計算還需要有較好的資料分段技術,也就是能方便地把待計算的資料拆分成若干部分,讓每個執行緒(或程式,這裡以多執行緒為例討論,多程式情況是類似的)分別處理。

640?wx_fmt=png

設計資料分段方案時,有這麼幾個目標:

1. 每段的資料量基本相同

並行任務的最終耗時是以那個最慢的執行緒為準的,而同一機器中各執行緒的處理能力基本相當,因此資料分段要能做到儘量平均,使各執行緒的計算時間基本相同。

2. 分段數可靈活動態指定

在資料準備階段經常並不清楚實際計算用機器的CPU數,而且即使知道,執行緒數也不能簡單地按機器CPU核數去算,因為硬碟的併發能力常常小於CPU;並且,在有併發計算時,能有多少CPU核用到本計算任務也不能事先預知。實際計算用的執行緒數最好是根據當時場景動態決定,範圍從幾個到幾十個都有可能,這要求能夠按隨意的數量將資料分段。

3. 每個分段是連續緊湊儲存的

因為硬碟不適合頻繁隨機訪問(即使固態硬碟也不適合頻繁小量的隨機訪問),為了保證遍歷效能,我們希望每個執行緒要處理的資料在硬碟上要儘量連續儲存,而不是頻繁跳躍。

4. 允許資料追加

資料並不是固定不變的,會隨著時間不斷增長,我們當然希望每次追加資料時不必重新整理所有資料,只需要把追加的資料補上即可。

640?wx_fmt=png

使用文字檔案儲存資料時,可以同時保證這4個目標。只要簡單地按總位元組數把檔案分成多段,每個執行緒讀取其中一段即可。

文字中用回車作為記錄(行)的分隔符,文字記錄的資料本身中不可能出現回車字元,所以用它用為記錄的分隔符不會產生歧義。按檔案位元組數分段時,分段點可能會落到某一行的中間,這時使用去頭補尾的方法進行調整,即就是每個分段從分段點繼續讀到一個回車符才開始,而越過下一個分段點繼續讀到一個回車符時才結束,這樣就可以保證每個分段都只包含完整的記錄(行),這也是HADOOP常用的方法。

但是,文字本身的解析實在太慢了,我們還是要考慮二進位制的儲存方案。

640?wx_fmt=png

二進位制資料中沒有回車這種可用於分隔記錄的字元,任何位元組數值都可能是資料本身,這時就無法識別出記錄何時結束。如果一定要人為製造一個分隔符,那就要足夠長才能避免和資料本身重複的可能性,每條記錄上都增加這麼一段位元組,會增加大量無意義的資料量、降低效能;而且,這也只能降低出錯率而不能徹底杜絕。

改進的方法是使用區塊,把資料存入若干相同大小的區塊,分段時以區塊為單位,只要總區塊數量足夠多,每個執行緒分配到的區塊數量也就相對比較平均,也就能滿足目標1和目標2了。不過目標3卻有些問題,區塊大小是儲存資料之前就確定的,不大可能正好和記錄長度匹配,如果要求每個區塊中都儲存完整的記錄,就可能造成區塊中的空間浪費(剩餘空間存不下一條完整記錄時只能作廢)。在區塊較小且記錄欄位較多時這個浪費會很嚴重,影響目標3希望的緊湊性。如果允許一條記錄被拆分到兩個區塊,那又不能按區塊為單位來分段了,否則可能造成某個分段將只處理半條記錄的情況。

這時候可以借鑑文字的去頭補尾方案,允許同一記錄拆分到兩個區塊,在讀取分段的第一個區塊時跳過第一條(可能是半條)記錄,而讀取最後一個區塊時再繼續讀下一個區塊把當前區塊中最後的記錄讀完整,這樣可以保證資料的緊湊性了。這種方法要求在區塊中有個標記表明本區塊中第一條記錄是否是上一區塊記錄的延續以及最後一條記錄是否完整,空間成本不算高,但在遍歷資料時總要被這些標記打斷,處理起來麻煩不少,會影響效能。

640?wx_fmt=png

資料庫一般也使用區塊方案,但由於資料庫將所有表的資料儲存在一起,它的區塊分配演算法不會去保證同表資料所佔用的區塊之間的連續性。而為提高資料的連續性,就要讓區塊更大,這和區塊多又有點矛盾。如果再考慮到資料的可追加性,則還需要一個不斷變大的索引表來管理這些區塊,在區塊數量很多時,這個索引表本身的連續性也不容易得到保證(它的長度事先不知道,在資料追加過程中動態增長)。

專欄作者簡介

640?

潤乾軟體創始人、首席科學家


清華大學計算機碩士,著有《非線性報表模型原理》等,1989年,中國首個國際奧林匹克數學競賽團體冠軍成員,個人金牌;2000年,創立潤乾公司;2004年,首次在潤乾報表中提出非線性報表模型,完美解決了中國式複雜報表製表難題,目前該模型已經成為報表行業的標準;2014年,經過7年開發,潤乾軟體釋出不依賴關係代數模型的計算引擎——集算器,有效地提高了複雜結構化大資料計算的開發和運算效率;2015年,潤乾軟體被福布斯中文網站評為“2015福布斯中國非上市潛力企業100強”;2016年,榮獲中國電子資訊產業發展研究院評選的“2016年中國軟體和資訊服務業十大領軍人物”;2017年, 自主創新研發新一代的資料倉儲、雲資料庫等產品即將面世。


資料蔣堂

《資料蔣堂》的作者蔣步星,從事資訊系統建設和資料處理長達20多年的時間。他豐富的工程經驗與深厚的理論功底相互融合、創新思想與傳統觀念的相互碰撞,虛擬與現實的相互交織,產生出了一篇篇的瀝血之作。此連載的內容涉及從資料呈現、採集到加工計算再到儲存以及挖掘等各個方面。大可觀資料世界之遠景、小可看技術疑難之細節。針對資料領域一些技術難點,站在研發人員的角度從淺入深,進行全方位、360度無死角深度剖析;對於一些業內觀點,站在技術人員角度闡述自己的思考和理解。蔣步星還會對大資料的發展,站在業內專家角度給予預測和推斷。靜下心來認真研讀你會發現,《資料蔣堂》的文章,有的會讓使用者避免重複前人走過的彎路,有的會讓攻城獅面對扎心的難題茅塞頓開,有的會為初入行業的讀者提供一把開啟資料世界的鑰匙,有的甚至會讓業內專家大跌眼鏡,產生思想交鋒。


往期回顧:

資料蔣堂 | JOIN延伸 - 維度其它應用

資料蔣堂 | JOIN延伸 - 維度查詢語法

資料蔣堂 | JOIN延伸 - 維度概念

資料蔣堂 | JOIN提速 - 有序歸併

資料蔣堂 | JOIN提速 - 外來鍵指標的衍生

資料蔣堂 | JOIN提速 - 外來鍵指標化

資料蔣堂 | JOIN簡化 - 意義總結

資料蔣堂 | JOIN簡化-消除關聯

資料蔣堂 | JOIN簡化 - 維度對齊

資料蔣堂 | JOIN運算剖析

資料蔣堂 | 迭代聚合語法

資料蔣堂 | 非常規聚合

資料蔣堂 | 再談有序分組

資料蔣堂 | 有序分組

資料蔣堂 | 非等值分組

資料蔣堂 | 還原分組運算的本意

資料蔣堂 | 有序遍歷語法

資料蔣堂 | 常規遍歷語法

資料蔣堂 | 從SQL語法看離散性

資料蔣堂 | 從SQL語法看集合化

資料蔣堂 | SQL用作大資料計算語法好嗎?

資料蔣堂 | SQL的困難源於關係代數

資料蔣堂 | SQL像英語是個善意的錯誤

資料蔣堂 | 開放的計算能力為資料庫瘦身

資料蔣堂 | 計算封閉性導致臃腫的資料庫

資料蔣堂 | 怎樣看待儲存過程的移植困難

資料蔣堂 | 儲存過程的利之弊

資料蔣堂 | 不要對自助BI期望過高

資料蔣堂 | 報表的資料計算層

資料蔣堂 | 報表應用的三層結構

資料蔣堂 | 列式儲存的另一面

資料蔣堂 | 硬碟的效能特徵

資料蔣堂 | 我們需要怎樣的OLAP?

資料蔣堂 | 1T資料到底有多大?

資料蔣堂 | 索引的本質是排序

資料蔣堂 | 功夫都在報表外--漫談報表效能優化

資料蔣堂 | 非結構化資料分析是忽悠?

資料蔣堂 | 多維分析的後臺效能優化手段


校對:林亦霖

為保證發文質量、樹立口碑,資料派現設立“錯別字基金”,鼓勵讀者積極糾錯

若您在閱讀文章過程中發現任何錯誤,請在文末留言,或到後臺反饋,經小編確認後,資料派將向檢舉讀者發8.8元紅包

同一位讀者指出同一篇文章多處錯誤,獎金不變。不同讀者指出同一處錯誤,獎勵第一位讀者。

感謝一直以來您的關注和支援,希望您能夠監督資料派產出更加高質的內容。

640?wx_fmt=jpeg

相關文章