資料蔣堂 | 資料分段討論
來源:資料蔣堂
作者:蔣步星
本文共1600字,建議閱讀5分鍾。
本文和大家討論了關於資料庫怎麼高效的將資料分段。
現代計算機一般都有多CPU核,而日益廣泛應用的固態硬碟也有較強地併發能力,這些硬體資源都為平行計算提供了有力的保證。不過,要實現平行計算還需要有較好的資料分段技術,也就是能方便地把待計算的資料拆分成若干部分,讓每個執行緒(或程式,這裡以多執行緒為例討論,多程式情況是類似的)分別處理。
設計資料分段方案時,有這麼幾個目標:
1. 每段的資料量基本相同
並行任務的最終耗時是以那個最慢的執行緒為準的,而同一機器中各執行緒的處理能力基本相當,因此資料分段要能做到儘量平均,使各執行緒的計算時間基本相同。
2. 分段數可靈活動態指定
在資料準備階段經常並不清楚實際計算用機器的CPU數,而且即使知道,執行緒數也不能簡單地按機器CPU核數去算,因為硬碟的併發能力常常小於CPU;並且,在有併發計算時,能有多少CPU核用到本計算任務也不能事先預知。實際計算用的執行緒數最好是根據當時場景動態決定,範圍從幾個到幾十個都有可能,這要求能夠按隨意的數量將資料分段。
3. 每個分段是連續緊湊儲存的
因為硬碟不適合頻繁隨機訪問(即使固態硬碟也不適合頻繁小量的隨機訪問),為了保證遍歷效能,我們希望每個執行緒要處理的資料在硬碟上要儘量連續儲存,而不是頻繁跳躍。
4. 允許資料追加
資料並不是固定不變的,會隨著時間不斷增長,我們當然希望每次追加資料時不必重新整理所有資料,只需要把追加的資料補上即可。
使用文字檔案儲存資料時,可以同時保證這4個目標。只要簡單地按總位元組數把檔案分成多段,每個執行緒讀取其中一段即可。
文字中用回車作為記錄(行)的分隔符,文字記錄的資料本身中不可能出現回車字元,所以用它用為記錄的分隔符不會產生歧義。按檔案位元組數分段時,分段點可能會落到某一行的中間,這時使用去頭補尾的方法進行調整,即就是每個分段從分段點繼續讀到一個回車符才開始,而越過下一個分段點繼續讀到一個回車符時才結束,這樣就可以保證每個分段都只包含完整的記錄(行),這也是HADOOP常用的方法。
但是,文字本身的解析實在太慢了,我們還是要考慮二進位制的儲存方案。
二進位制資料中沒有回車這種可用於分隔記錄的字元,任何位元組數值都可能是資料本身,這時就無法識別出記錄何時結束。如果一定要人為製造一個分隔符,那就要足夠長才能避免和資料本身重複的可能性,每條記錄上都增加這麼一段位元組,會增加大量無意義的資料量、降低效能;而且,這也只能降低出錯率而不能徹底杜絕。
改進的方法是使用區塊,把資料存入若干相同大小的區塊,分段時以區塊為單位,只要總區塊數量足夠多,每個執行緒分配到的區塊數量也就相對比較平均,也就能滿足目標1和目標2了。不過目標3卻有些問題,區塊大小是儲存資料之前就確定的,不大可能正好和記錄長度匹配,如果要求每個區塊中都儲存完整的記錄,就可能造成區塊中的空間浪費(剩餘空間存不下一條完整記錄時只能作廢)。在區塊較小且記錄欄位較多時這個浪費會很嚴重,影響目標3希望的緊湊性。如果允許一條記錄被拆分到兩個區塊,那又不能按區塊為單位來分段了,否則可能造成某個分段將只處理半條記錄的情況。
這時候可以借鑑文字的去頭補尾方案,允許同一記錄拆分到兩個區塊,在讀取分段的第一個區塊時跳過第一條(可能是半條)記錄,而讀取最後一個區塊時再繼續讀下一個區塊把當前區塊中最後的記錄讀完整,這樣可以保證資料的緊湊性了。這種方法要求在區塊中有個標記表明本區塊中第一條記錄是否是上一區塊記錄的延續以及最後一條記錄是否完整,空間成本不算高,但在遍歷資料時總要被這些標記打斷,處理起來麻煩不少,會影響效能。
資料庫一般也使用區塊方案,但由於資料庫將所有表的資料儲存在一起,它的區塊分配演算法不會去保證同表資料所佔用的區塊之間的連續性。而為提高資料的連續性,就要讓區塊更大,這和區塊多又有點矛盾。如果再考慮到資料的可追加性,則還需要一個不斷變大的索引表來管理這些區塊,在區塊數量很多時,這個索引表本身的連續性也不容易得到保證(它的長度事先不知道,在資料追加過程中動態增長)。
專欄作者簡介
潤乾軟體創始人、首席科學家
清華大學計算機碩士,著有《非線性報表模型原理》等,1989年,中國首個國際奧林匹克數學競賽團體冠軍成員,個人金牌;2000年,創立潤乾公司;2004年,首次在潤乾報表中提出非線性報表模型,完美解決了中國式複雜報表製表難題,目前該模型已經成為報表行業的標準;2014年,經過7年開發,潤乾軟體釋出不依賴關係代數模型的計算引擎——集算器,有效地提高了複雜結構化大資料計算的開發和運算效率;2015年,潤乾軟體被福布斯中文網站評為“2015福布斯中國非上市潛力企業100強”;2016年,榮獲中國電子資訊產業發展研究院評選的“2016年中國軟體和資訊服務業十大領軍人物”;2017年, 自主創新研發新一代的資料倉儲、雲資料庫等產品即將面世。
資料蔣堂
《資料蔣堂》的作者蔣步星,從事資訊系統建設和資料處理長達20多年的時間。他豐富的工程經驗與深厚的理論功底相互融合、創新思想與傳統觀念的相互碰撞,虛擬與現實的相互交織,產生出了一篇篇的瀝血之作。此連載的內容涉及從資料呈現、採集到加工計算再到儲存以及挖掘等各個方面。大可觀資料世界之遠景、小可看技術疑難之細節。針對資料領域一些技術難點,站在研發人員的角度從淺入深,進行全方位、360度無死角深度剖析;對於一些業內觀點,站在技術人員角度闡述自己的思考和理解。蔣步星還會對大資料的發展,站在業內專家角度給予預測和推斷。靜下心來認真研讀你會發現,《資料蔣堂》的文章,有的會讓使用者避免重複前人走過的彎路,有的會讓攻城獅面對扎心的難題茅塞頓開,有的會為初入行業的讀者提供一把開啟資料世界的鑰匙,有的甚至會讓業內專家大跌眼鏡,產生思想交鋒。
往期回顧:
資料蔣堂 | 常規遍歷語法
校對:林亦霖
為保證發文質量、樹立口碑,資料派現設立“錯別字基金”,鼓勵讀者積極糾錯。
若您在閱讀文章過程中發現任何錯誤,請在文末留言,或到後臺反饋,經小編確認後,資料派將向檢舉讀者發8.8元紅包。
同一位讀者指出同一篇文章多處錯誤,獎金不變。不同讀者指出同一處錯誤,獎勵第一位讀者。
感謝一直以來您的關注和支援,希望您能夠監督資料派產出更加高質的內容。
相關文章
- 資料蔣堂|倍增分段技術
- 資料蔣堂 | 倍增分段技術
- 資料蔣堂|Hadoop中理論與工程的錯位Hadoop
- 資料蔣堂 | JOIN延伸 - 維度其它應用
- 【資料蔣堂】第48期:Hadoop中理論與工程的錯位Hadoop
- 資料分析主題討論
- 關於大資料和資料庫的討論大資料資料庫
- 資料庫系統架構討論資料庫架構
- 基於MySQL資料庫討論虛擬機器資料恢復MySql資料庫虛擬機資料恢復
- 討論幾種資料列Column的特性(上)
- 討論幾種資料列Column的特性(下)
- [技術討論]多使用者(多公司)的資料庫設計討論資料庫
- 【MySQL】資料安全性討論思維導圖MySql
- 關於資料庫作業系統的討論資料庫作業系統
- [技術討論]資料許可權中的理論和實際
- 關於BSS資料化轉型的幾點討論
- iOS App 效能資料自動化收集討論、徵集貼iOSAPP
- 和開發討論的一個資料變更需求
- 關於如何節約資料庫連線的討論?資料庫
- 對話蔣傑、丁奇,騰訊雲資料庫之路資料庫
- 蔣鴻翔:網易資料基礎平臺建設
- 【案例討論】災難與拯救 資料安全精彩案例大討論!歡迎大家踴躍參與!
- 一個XML資料統計問題,期待大家的討論XML
- REST實戰討論組的文件資料在什麼地方?REST
- 資料倉儲專題(4)-分散式資料倉儲事實表設計思考---討論精華分散式
- oracle 分頁sql 分段查資料和分段求和 sql語句 和java程式碼OracleSQLJava
- 大資料技術之大資料概論大資料
- 資料庫概論 (一)資料庫概念資料庫
- NoSQL資料庫探討 -- 非關係型資料庫SQL資料庫
- 關於資料庫 Block 儲存細節問題的討論資料庫BloC
- 讓資料探勘工作起來-DM大討論[轉自Ken North]
- 討論一下專案的資料校驗實現方案。
- 最新小牛學堂大資料24期大資料
- 資料倉儲資料質量的問題探討(轉)
- 大資料相關資料論文小結大資料
- 大資料技術與應用課堂測試-資料清洗同步大資料
- 大資料技術之Hadoop(入門) 第2章 從Hadoop框架討論大資料生態大資料Hadoop框架
- 基於 JSONModel 資料模型的列表控制元件顯示資料的深入討論試讀版JSON模型控制元件