下載本文檔
版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)
文檔簡介
1、在實際的工作環(huán)境下,許多人會遇到海量數(shù)據(jù)這個復(fù)雜而艱巨的問題,它的主要難點有以下幾個方面:一、數(shù)據(jù)量過大,數(shù)據(jù)中什么情況都可能存在。如果說有10條數(shù)據(jù),那么大不了每條去逐一檢查,人為處理,如果有上百條數(shù)據(jù),也可以考慮,如果數(shù)據(jù)上到千萬級別,甚至過億,那不是手工能解決的了,必須通過工具或者程序進行處理,尤其海量的數(shù)據(jù)中,什么情況都可能存在,例如,數(shù)據(jù)中某處格式出了問題,尤其在程序處理時,前面還能正常處理,突然到了某個地方問題出現(xiàn)了,程序終止了。二、軟硬件要求高,系統(tǒng)資源占用率高。對海量的數(shù)據(jù)進行處理,除了好的方法,最重要的就是合理使用工具,合理分配系統(tǒng)資源。一般情況,如果處理的數(shù)據(jù)過TB級,小型
2、機是要考慮的,普通的機子如果有好的方法可以考慮,不過也必須加大CPU和內(nèi)存,就象面對著千軍萬馬,光有勇氣沒有一兵一卒是很難取勝的。三、要求很高的處理方法和技巧。這也是本文的寫作目的所在,好的處理方法是一位工程師長期工作經(jīng)驗的積累,也是個人的經(jīng)驗的總結(jié)。沒有通用的處理方法,但有通用的原理和規(guī)則。下面我們來詳細介紹一下處理海量數(shù)據(jù)的經(jīng)驗和技巧:一、選用優(yōu)秀的數(shù)據(jù)庫工具現(xiàn)在的數(shù)據(jù)庫工具廠家比較多,對海量數(shù)據(jù)的處理對所使用的數(shù)據(jù)庫工具要求比較高,一般使用Oracle或者DB2,微軟公司最近發(fā)布的SQL Server 2005性能也不錯。另外在BI領(lǐng)域:數(shù)據(jù)庫,數(shù)據(jù)倉庫,多維數(shù)據(jù)庫,數(shù)據(jù)挖掘等相關(guān)工具也
3、要進行選擇,象好的ETL工具和好的OLAP工具都十分必要,例如Informatic,Eassbase等。筆者在實際數(shù)據(jù)分析項目中,對每天6000萬條的日志數(shù)據(jù)進行處理,使用SQL Server 2000需要花費6小時,而使用SQL Server 2005則只需要花費3小時。二、編寫優(yōu)良的程序代碼處理數(shù)據(jù)離不開優(yōu)秀的程序代碼,尤其在進行復(fù)雜數(shù)據(jù)處理時,必須使用程序。好的程序代碼對數(shù)據(jù)的處理至關(guān)重要,這不僅僅是數(shù)據(jù)處理準確度的問題,更是數(shù)據(jù)處理效率的問題。良好的程序代碼應(yīng)該包含好的算法,包含好的處理流程,包含好的效率,包含好的異常處理機制等。三、對海量數(shù)據(jù)進行分區(qū)操作對海量數(shù)據(jù)進行分區(qū)操作十分必要
4、,例如針對按年份存取的數(shù)據(jù),我們可以按年進行分區(qū),不同的數(shù)據(jù)庫有不同的分區(qū)方式,不過處理機制大體相同。例如SQL Server的數(shù)據(jù)庫分區(qū)是將不同的數(shù)據(jù)存于不同的文件組下,而不同的文件組存于不同的磁盤分區(qū)下,這樣將數(shù)據(jù)分散開,減小磁盤I/O,減小了系統(tǒng)負荷,而且還可以將日志,索引等放于不同的分區(qū)下。四、建立廣泛的索引對海量的數(shù)據(jù)處理,對大表建立索引是必行的,建立索引要考慮到具體情況,例如針對大表的分組、排序等字段,都要建立相應(yīng)索引,一般還可以建立復(fù)合索引,對經(jīng)常插入的表則建立索引時要小心,筆者在處理數(shù)據(jù)時,曾經(jīng)在一個ETL流程中,當插入表時,首先刪除索引,然后插入完畢,建立索引,并實施聚合操作
5、,聚合完成后,再次插入前還是刪除索引,所以索引要用到好的時機,索引的填充因子和聚集、非聚集索引都要考慮。五、建立緩存機制1 / 3當數(shù)據(jù)量增加時,一般的處理工具都要考慮到緩存問題。緩存大小設(shè)置的好差也關(guān)系到數(shù)據(jù)處理的成敗,例如,筆者在處理2億條數(shù)據(jù)聚合操作時,緩存設(shè)置為100000條/Buffer,這對于這個級別的數(shù)據(jù)量是可行的。六、加大虛擬內(nèi)存如果系統(tǒng)資源有限,內(nèi)存提示不足,則可以靠增加虛擬內(nèi)存來解決。筆者在實際項目中曾經(jīng)遇到針對18億條的數(shù)據(jù)進行處理,內(nèi)存為1GB,1個P4 2.4G的CPU,對這么大的數(shù)據(jù)量進行聚合操作是有問題的,提示內(nèi)存不足,那么采用了加大虛擬內(nèi)存的方法來解決,在6塊磁
6、盤分區(qū)上分別建立了6個4096M的磁盤分區(qū),用于虛擬內(nèi)存,這樣虛擬的內(nèi)存則增加為 4096*6 + 1024 = 25600 M,解決了數(shù)據(jù)處理中的內(nèi)存不足問題。七、分批處理海量數(shù)據(jù)處理難因為數(shù)據(jù)量大,那么解決海量數(shù)據(jù)處理難的問題其中一個技巧是減少數(shù)據(jù)量??梢詫A繑?shù)據(jù)分批處理,然后處理后的數(shù)據(jù)再進行合并操作,這樣逐個擊破,有利于小數(shù)據(jù)量的處理,不至于面對大數(shù)據(jù)量帶來的問題,不過這種方法也要因時因勢進行,如果不允許拆分數(shù)據(jù),還需要另想辦法。不過一般的數(shù)據(jù)按天、按月、按年等存儲的,都可以采用先分后合的方法,對數(shù)據(jù)進行分開處理。八、使用臨時表和中間表數(shù)據(jù)量增加時,處理中要考慮提前匯總。這樣做的目的
7、是化整為零,大表變小表,分塊處理完成后,再利用一定的規(guī)則進行合并,處理過程中的臨時表的使用和中間結(jié)果的保存都非常重要,如果對于超海量的數(shù)據(jù),大表處理不了,只能拆分為多個小表。如果處理過程中需要多步匯總操作,可按匯總步驟一步步來,不要一條語句完成,一口氣吃掉一個胖子。九、優(yōu)化查詢SQL語句在對海量數(shù)據(jù)進行查詢處理過程中,查詢的SQL語句的性能對查詢效率的影響是非常大的,編寫高效優(yōu)良的SQL腳本和存儲過程是數(shù)據(jù)庫工作人員的職責(zé),也是檢驗數(shù)據(jù)庫工作人員水平的一個標準,在對SQL語句的編寫過程中,例如減少關(guān)聯(lián),少用或不用游標,設(shè)計好高效的數(shù)據(jù)庫表結(jié)構(gòu)等都十分必要。筆者在工作中試著對1億行的數(shù)據(jù)使用游標
8、,運行3個小時沒有出結(jié)果,這是一定要改用程序處理了。十、使用文本格式進行處理對一般的數(shù)據(jù)處理可以使用數(shù)據(jù)庫,如果對復(fù)雜的數(shù)據(jù)處理,必須借助程序,那么在程序操作數(shù)據(jù)庫和程序操作文本之間選擇,是一定要選擇程序操作文本的,原因為:程序操作文本速度快;對文本進行處理不容易出錯;文本的存儲不受限制等。例如一般的海量的網(wǎng)絡(luò)日志都是文本格式或者csv格式(文本格式),對它進行處理牽扯到數(shù)據(jù)清洗,是要利用程序進行處理的,而不建議導(dǎo)入數(shù)據(jù)庫再做清洗。十一、定制強大的清洗規(guī)則和出錯處理機制海量數(shù)據(jù)中存在著不一致性,極有可能出現(xiàn)某處的瑕疵。例如,同樣的數(shù)據(jù)中的時間字段,有的可能為非標準的時間,出現(xiàn)的原因可能為應(yīng)用程
9、序的錯誤,系統(tǒng)的錯誤等,這是在進行數(shù)據(jù)處理時,必須制定強大的數(shù)據(jù)清洗規(guī)則和出錯處理機制。十二、建立視圖或者物化視圖視圖中的數(shù)據(jù)來源于基表,對海量數(shù)據(jù)的處理,可以將數(shù)據(jù)按一定的規(guī)則分散到各個基表中,查詢或處理過程中可以基于視圖進行,這樣分散了磁盤I/O,正如10根繩子吊著一根柱子和一根吊著一根柱子的區(qū)別。十三、避免使用32位機子(極端情況)目前的計算機很多都是32位的,那么編寫的程序?qū)?nèi)存的需要便受限制,而很多的海量數(shù)據(jù)處理是必須大量消耗內(nèi)存的,這便要求更好性能的機子,其中對位數(shù)的限制也十分重要。十四、考慮操作系統(tǒng)問題海量數(shù)據(jù)處理過程中,除了對數(shù)據(jù)庫,處理程序等要求比較高以外,對操作系統(tǒng)的要求也
10、放到了重要的位置,一般是必須使用服務(wù)器的,而且對系統(tǒng)的安全性和穩(wěn)定性等要求也比較高。尤其對操作系統(tǒng)自身的緩存機制,臨時空間的處理等問題都需要綜合考慮。十五、使用數(shù)據(jù)倉庫和多維數(shù)據(jù)庫存儲數(shù)據(jù)量加大是一定要考慮OLAP的,傳統(tǒng)的報表可能5、6個小時出來結(jié)果,而基于Cube的查詢可能只需要幾分鐘,因此處理海量數(shù)據(jù)的利器是OLAP多維分析,即建立數(shù)據(jù)倉庫,建立多維數(shù)據(jù)集,基于多維數(shù)據(jù)集進行報表展現(xiàn)和數(shù)據(jù)挖掘等。十六、使用采樣數(shù)據(jù),進行數(shù)據(jù)挖掘基于海量數(shù)據(jù)的數(shù)據(jù)挖掘正在逐步興起,面對著超海量的數(shù)據(jù),一般的挖掘軟件或算法往往采用數(shù)據(jù)抽樣的方式進行處理,這樣的誤差不會很高,大大提高了處理效率和處理的成功率。一般采樣時要注意數(shù)據(jù)的完整性和,防止過大的偏差。筆者曾經(jīng)對1億2千萬行的表數(shù)據(jù)進行采樣,抽取出400萬行,經(jīng)測試軟件測試處理的誤差為千分之五,客戶可以接受。還有一些方法,需要在不同的情況和場合下運用,例如使用代理鍵等操
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 二零二五年度城鎮(zhèn)土地使用權(quán)轉(zhuǎn)讓及配套設(shè)施建設(shè)合同協(xié)議3篇
- 二零二五年度小額貸款個人信用借款合同范本2篇
- 二零二五年度電子商務(wù)銷售結(jié)算合同3篇
- 二零二五年度建筑施工安全環(huán)保事故處理協(xié)議3篇
- 二零二五年度個人住宅買賣合同示范范本
- 酒店管理工作中的風(fēng)險管控
- 醫(yī)院行業(yè)美工的醫(yī)療廣告
- 培訓(xùn)行業(yè)課程安全操作指南
- 電子工程師的領(lǐng)域探索
- 二零二五年度農(nóng)產(chǎn)品直銷銷售合同范本
- 《帶一本書去讀研:研究生關(guān)鍵學(xué)術(shù)技能快速入門》筆記
- 知識圖譜智慧樹知到答案2024年浙江大學(xué)
- 2024年度-美團新騎手入門培訓(xùn)
- 高一數(shù)學(xué)寒假講義(新人教A專用)【復(fù)習(xí)】第05講 三角函數(shù)(學(xué)生卷)
- 農(nóng)村高中思想政治課時政教育研究的中期報告
- 醫(yī)院定崗定編方案文檔
- 4-熔化焊與熱切割作業(yè)基礎(chǔ)知識(一)
- 2023年200MW儲能電站儲能系統(tǒng)設(shè)計方案
- 個人安全與社會責(zé)任的基本知識概述
- 簡易勞務(wù)合同電子版
- 明代文學(xué)緒論
評論
0/150
提交評論