2019年測試ETL工具都應測試哪些方面_第1頁
2019年測試ETL工具都應測試哪些方面_第2頁
2019年測試ETL工具都應測試哪些方面_第3頁
2019年測試ETL工具都應測試哪些方面_第4頁
2019年測試ETL工具都應測試哪些方面_第5頁
已閱讀5頁,還剩51頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領

文檔簡介

1、是否支持流行的數(shù)據(jù)存儲,比如各種關(guān)系型數(shù)據(jù)庫,文件數(shù)據(jù)存儲等2、是否在ETL過程中支持"事務"3、加載數(shù)據(jù)的性能,如十萬條級別的數(shù)據(jù)的加載時間4、各種數(shù)據(jù)轉(zhuǎn)換的功能,自動調(diào)度運行等等測試分析測試點:ETL常規(guī)檢查:LETL腳本是否有運行錯誤,腳本運行時間(看執(zhí)行計劃).ETL腳本的錯誤處理機制是否完整(代碼review).ETL腳本是否支持回滾業(yè)務邏輯檢查:.數(shù)據(jù)量的檢查。核對記錄數(shù)是否和預期一致.唯一性檢查。主鍵是否重復(cookie_id,member_id是否重復).業(yè)務字段轉(zhuǎn)換正確性檢查。指標計算是否正確.抽樣檢查。需要注意的是這種參數(shù)表名包括databasetableinput或者executesqlscript,只要是參數(shù)作為表名的情況前面的輸入不能是從數(shù)據(jù)庫來的,應為沒有辦法執(zhí)行這種preparedStatement語句,從數(shù)據(jù)庫來的值后面的操作是"值操作",而不是字符串替換,只有argument或者sequence操作當作參數(shù)才是字符串替換.(這一點官方FAQ也有提到)updatetable和executesqlscript里面執(zhí)行update的區(qū)別執(zhí)行updatetable操作是比較慢的,它會一條一條基于comparekey對比數(shù)據(jù),然后決定是不是要執(zhí)行updatesql,如果你知道你要怎么更新數(shù)據(jù)盡可能的使用executesqlscript操作,在里面手寫updatesql(注意源數(shù)據(jù)庫和目標數(shù)據(jù)庫在哪),這種多行執(zhí)行方式(updatesql)肯定比單行執(zhí)行方式(updatetable操作)快的多。另一個區(qū)別是executesqlscript操作是可以接受參數(shù)的輸入的。它前面可以是一個跟它完全不關(guān)的表一個sql:selectfieldl,field2fieldsfromtableA后面執(zhí)行另一個表的更新操作:updatetableBsetfield4=?wherefield5=?Andfield6=?然后選中executesqlscript的executeforeachrow.注意參數(shù)是一一對應的.(field4對應fieldl的值,fields對應field2的值,field6對應field?的值)kettle的性能kettle本身的性能絕對是能夠應對大型應用的,一般的基于平均行長150的一條記錄,假設源數(shù)據(jù)庫,目標數(shù)據(jù)庫以及kettle都分別在幾臺機器上(最常見的桌面工作模式,雙核,1G內(nèi)存),速度大概都可以到5000行每秒左右,如果把硬件提高一些,性能還可以提升,但是ETL過程中難免遇到性能問題,下面一些通用的步驟也許能給你一些幫助.盡量使用數(shù)據(jù)庫連接池盡量提高批處理的commitsize盡量使用緩存,緩存盡量大一些(主要是文本文件和數(shù)據(jù)流)Kettle是Java做的,盡量用大一點的內(nèi)存參數(shù)啟動Kettle.可以使用sql來做的一些操作盡量用sqlGroup,merge,streamlookup,splitfield這些操作都是比較慢的,想辦法避免他們.,能用sql就用sql插入大量數(shù)據(jù)的時候盡量把索引刪掉盡量避免使用update,delete操作,尤其是update,如果可以把update變成先delete,后insert.能使用truncatetable的時候,就不要使用deleteallrow這種類似sql合理的分區(qū)如果刪除操作是基于某一個分區(qū)的,就不要使用deleterow這種方式(不管是deletesql還是delete步驟)直接把分區(qū)drop掉,再重新創(chuàng)建盡量縮小輸入的數(shù)據(jù)集的大?。ㄔ隽扛乱彩菫榱诉@個目的)盡量使用數(shù)據(jù)庫原生的方式裝載文本文件(Oracle的sqlloader,mysql的bulkloader步驟)盡量不要用kettle的calculate計算步驟,能用數(shù)據(jù)庫本身的sql就用sql,不能用sql就盡量想辦法用procedure,實在不行才是calculate步驟.要知道你的性能瓶頸在哪,可能有時候你使用了不恰當?shù)姆绞?,導致整個操作都變慢,觀察kettlelog生成的方式來了解你的ETL操作最慢的地方。遠程數(shù)據(jù)庫用文件+FTP的方式來傳數(shù)據(jù),文件要壓縮。(只要不是局域網(wǎng)都可以認為是遠程連接)描述物理環(huán)境源數(shù)據(jù)庫的操作系統(tǒng),硬件環(huán)境,是單數(shù)據(jù)源還是多數(shù)據(jù)源,數(shù)據(jù)庫怎么分布的,做ETL的那臺機器放在哪,操作系統(tǒng)和硬件環(huán)境是什么,目標數(shù)據(jù)倉庫的數(shù)據(jù)庫是什么才桑作系統(tǒng),硬件環(huán)境,數(shù)據(jù)庫的字符集怎么選,數(shù)據(jù)傳輸方式是什么,開發(fā)環(huán)境,測試環(huán)境和實際的生產(chǎn)環(huán)境有什么區(qū)別,是不是需要一個中間數(shù)據(jù)庫(staging數(shù)據(jù)庫),源數(shù)據(jù)庫的數(shù)據(jù)庫版本號是多少,測試數(shù)據(jù)庫的版本號是多少,真正的目標數(shù)據(jù)庫的版本號是多少.……這些信息也許很零散,但是都需要一份專門的文檔來描述這些信息,無論是你遇到問題需要別人幫助的時候描述問題本身,還是發(fā)現(xiàn)測試環(huán)境跟目標數(shù)據(jù)庫的版本號不一致,這份專門的文檔都能提供一些基本的信息procedure為什么我不能觸發(fā)procedure?這個問題在官方FAQ里面也有提到,觸發(fā)procedure和httpclient都需要一個類似與觸發(fā)器的條件,你可以使用generaterow步驟產(chǎn)生一個空的row,然后把這條記錄連上procedure步驟,這樣就會使這條沒有記錄的空行觸發(fā)這個procedure(如果你打算使用無條件的單次觸發(fā)),當然procedure也可以象tableinput里面的步驟那樣傳參數(shù)并且多次執(zhí)行.另外一個建議是不要使用復雜的procedure來完成本該ETL任務完成的任務,比如創(chuàng)建表,填充數(shù)據(jù),創(chuàng)建物化視圖等等.字符集Kettle使用Java通常使用的UTF8來傳輸字符集,所以無論你使用何種數(shù)據(jù)庫,任何數(shù)據(jù)庫種類的字符集,kettle都是支持的,如果你遇到了字符集問題,也許下面這些提示可以幫助你:.單數(shù)據(jù)庫到單數(shù)據(jù)庫是絕對不會出現(xiàn)亂碼問題的,不管原數(shù)據(jù)庫和目標數(shù)據(jù)庫是何種種類,何種字符集.多種不同字符集的原數(shù)據(jù)庫到一個目標數(shù)據(jù)庫,你首先需要確定多種源數(shù)據(jù)庫的字符集的最大兼容字符集是什么如果你不清楚最好的辦法就是使用UTF8來創(chuàng)建數(shù)據(jù)庫..不要以你工作的環(huán)境來判斷字符集:現(xiàn)在某一個測試人員手上有一個oracle的基于XXX字符集的已經(jīng)存在的數(shù)據(jù)庫,并且非常不幸的是XXX字符集不是utf8類型的,于是他把另一個基于yyy字符集的。racle數(shù)據(jù)庫要經(jīng)過某一個ETL過程轉(zhuǎn)換到。racle,后來他發(fā)現(xiàn)無論怎么樣設置都會出現(xiàn)亂碼,這是因為你的數(shù)據(jù)庫本身的字符集不支持,無論你怎么設置都是沒用的.測試的數(shù)據(jù)庫不代表最后產(chǎn)品運行的數(shù)據(jù)庫,尤其是有時候為了省事把多個不同的項目的不相關(guān)的數(shù)據(jù)庫裝在同一臺機器上,測試的時候又沒有分析清楚這種環(huán)境,所以也再次強調(diào)描述物理環(huán)境的重要性..你所看到的不一定代表實際儲存的:mysql處理字符集的時候是要在jdbe連接的參數(shù)里面加上字符集參數(shù)的,而oracle則是需要服務器端和客戶端使用同一種字符集才能正確顯示,所以你要明確你所看到的字符集亂碼不一定代表真的就是字符集亂碼,這需要你檢查在轉(zhuǎn)換之前的字符集是否會出現(xiàn)亂碼和轉(zhuǎn)換之后是否出現(xiàn)亂碼,你的桌面環(huán)境可能需要變動一些參數(shù)來適應這種變動.不要在一個轉(zhuǎn)換中使用多個字符集做為數(shù)據(jù)源..預定義時間維Kettle提供了一個小工具幫助我們預填充時間維,這個工具在kettle_home/samples/transformations/General-populatedatedimension.這個示例產(chǎn)生的數(shù)據(jù)不一定能滿足各種需要,不過你可以通過修改這個示例來滿足自己的需求..SQLtab和Optionstab在你創(chuàng)建一個數(shù)據(jù)庫連接的時候除了可以指定你一次需要初始化的連接池參數(shù)之外(在Pooling選項卡下面),還包括一個Options選項卡和一個SQL選項卡,Options選項卡里面主要設置一些連接時的參數(shù),比如autocommit是onoff,defaultFetchSize,useCursorFetch(mysql默認支持的)Qracle還支持比如defaultExecuteBatch,oracle.jdbc.StreamBufferSize,oracle.jdbc.FreeMemoryOnEnterlmplicitCache,你可以查閱對應數(shù)據(jù)庫所支持的連接參數(shù),另外一個小提示:在創(chuàng)建數(shù)據(jù)庫連接的時候,選擇你的數(shù)據(jù)庫類型然后選到Options選項卡,下面有一個Showhelptextonoptionsusage,點擊這個按鈕會把你帶到對應各個數(shù)據(jù)庫的連接參數(shù)的官方的一個參數(shù)列表頁面,通過查詢這個列表頁面你就可以知道那種數(shù)據(jù)庫可以使用何種參數(shù)了.對于SQL選項卡就是在你一連接這個Connection之后,Kettle會立刻執(zhí)行的sql語句,個人比較推薦的一個sqI是執(zhí)行把所有日期格式統(tǒng)一成同一格式的sql,比如在oracle里面就是:altersessionsetnls_date_format=xxxxxxxxxxxxxaltersessionsetnls_xxxxxxxxx=xxxxxxxxxxxx這樣可以避免你在轉(zhuǎn)換的時候大量使用to_date(),to_char函數(shù)而僅僅只是為了統(tǒng)一日期格式,對于增量更新的時候尤其適用..數(shù)據(jù)復制有的時候可能我們需要的是類似數(shù)據(jù)復制或者一個備份數(shù)據(jù)庫,這個時候你需要的是一種數(shù)據(jù)庫私有的解決方案,Kettle也許并不是你的第一選擇,比如對于Oracle來說,可能rman,oraclestream,oraclereplication等等,mysql也有mysqlrmaster/slave模式的replication等私有的解決方法,如果你確定你的需求不是數(shù)據(jù)集成這方面的,那么也許kettle并不是一個很好的首選方案,你應該咨詢一下專業(yè)的DBA人士也會會更好..如何控制版本變更Kettle的每一個transformation和job都有一個version字段(在你保存的時候),不過這個功能還不實用,如果你需要版本控制的話,還是建議你將transformation和job轉(zhuǎn)換成文本文件保存,然后用svn或cvs或任意你熟悉的版本控制系統(tǒng)將其保存,kettle將在下一個版本加入版本控制的功能(做的更易用)..支持的數(shù)據(jù)源Kettle支持相當廣的數(shù)據(jù)源,比如在數(shù)據(jù)庫里面的一些不太常見的Access,MaxDB(SAPDB),Hypersonic,SAPR/3system,BorlandInterbase,OracleRDB,Teradata和3.0新加入的SybaseIQ.另外還包括Excel,CSV,LDAP,以及OLAPServerMondrian,目前支持WebService不過暫時還不支持SOAP..調(diào)試和測試當ETL轉(zhuǎn)換出現(xiàn)不可預知的問題時,或是你不清楚某個步驟的功能是什么的情況下,你可能需要創(chuàng)建一個模擬環(huán)境來調(diào)適程序,下面一些建議可能會有所幫助:盡量使用generaterow步驟或者固定的一個文本文件來創(chuàng)建一個模擬的數(shù)據(jù)源模擬的數(shù)據(jù)源一定要有代表性,數(shù)據(jù)集一定盡量小(為了性能考慮)但是數(shù)據(jù)本身要足夠分散.創(chuàng)建了模擬的數(shù)據(jù)集后你應該清楚的知道你所要轉(zhuǎn)換之后的數(shù)據(jù)時什么樣的..錯誤處理在ETL任務中由于數(shù)據(jù)問題出現(xiàn)轉(zhuǎn)換錯誤是一件非常正常的事情,你不應該設計一個依賴于臨時表或者擁有事務特點的ETL過程,面對數(shù)據(jù)源質(zhì)量問題的巨大挑戰(zhàn),錯誤處理是并不可少的,kettle同樣提供非常方便的錯誤處理方式,在你可能會出錯的步驟點擊右鍵選擇DefineErrorhanding,它會要求你指定一個處理error的步驟,你可以使用文本文件或者數(shù)據(jù)庫的表來儲存這些錯誤信息,這些錯誤信息會包含一個id和一個出錯的字段,當你得到這些錯誤信息之后就需要你自己分析出錯的原因了,比如違反主鍵約束可能是你生成主鍵的方式有錯誤或者本身的數(shù)據(jù)有重復,而違反外鍵約束則可能是你依賴的一些表里面的數(shù)據(jù)還沒有轉(zhuǎn)換或者外鍵表本身過濾掉了這些數(shù)據(jù).當你調(diào)整了這些錯誤之后,確定所有依賴的數(shù)據(jù)都被正確的處理了kettleuserguide里面有更詳細的解釋,里面還附帶了一個使用javascript來處理錯誤的示例,這種方式可以作為處理簡單數(shù)據(jù)質(zhì)量的方式..文檔,文檔,文檔Kettle提供了豐富的文檔和使用手冊,小到一個數(shù)據(jù)庫連接怎么連,大到一個功能怎么實現(xiàn),所有的參數(shù)列表,對話框的每一個輸入輸出代表什么意思都有解釋,所以當你遇到問題你應該第一時間翻閱這些文檔,也許上面已經(jīng)告訴你怎么做了.另外kettle還有一個非?;钴S的社區(qū),你可以到上面提問,但是記住在你提問之前先搜索一下論壇看有沒有類似的問題已經(jīng)問過了,如果沒有記得描述清楚你的問題總結(jié)本系列文章主要討論了如何使用kettle來處理數(shù)據(jù)倉庫中的緩慢增長維,動態(tài)ETL如何設計,增量更新的一些設計技巧,在應用程序中如何集成kettle以及在使用kettle時的一些常見問題.如果你正在尋找一個工具來幫助你解決數(shù)據(jù)庫的集成問題或是你打算建立一個商業(yè)智能項目的數(shù)據(jù)倉庫,那么kettle是一個不錯的選擇,你不用支付任何費用就可以得到很多很多數(shù)據(jù)集成的特性,大量文檔和社區(qū)支持.難道這些不就是你希望從一個商業(yè)工具上的到的嗎?還在等什么,開始你的數(shù)據(jù)集成之旅吧關(guān)于PDI性能的簡單測試作者:PDI()發(fā)表于:2008.07.1521:31分類:PDI使用出處:PDI使用了下面的技術(shù)來提高性能:.數(shù)據(jù)庫連接池。.多線程并發(fā)進行數(shù)據(jù)轉(zhuǎn)換:轉(zhuǎn)換步驟是并發(fā)執(zhí)行的,使用生產(chǎn)者/消費者的模式,每個步驟由一個線程來執(zhí)行,當前步驟將一次處理完的數(shù)據(jù)放在緩存里,由下一個步驟的線程讀取并再處理這些數(shù)據(jù)。.數(shù)據(jù)批量裝載:表輸出步驟中設置批量裝載。.對于某些數(shù)據(jù)庫還利用了數(shù)據(jù)庫自身提供的裝載工具,如Oracle的SQLLoader.在PDI3.1中提供了該功能。.集群:主服務器(masterserver)將大任務分解為多個小任務,并將要處理的數(shù)據(jù)通過soket發(fā)送到從服務器(slaveserver),由多個從服務器同時處理.從服務器需要啟動carte服務,以便建立連接接受數(shù)據(jù)。一個簡單的性能測試:測試環(huán)境:CPU1.5GMemory1GOSWindows2000PDI3.1Oracle9i10/100M以太網(wǎng)測試內(nèi)容:從一臺機器的Oracle向另一臺機器的Oracle遷移數(shù)據(jù)測試結(jié)果:.當使用普通的tableoutput輸出步驟立匕量裝載設置為500,平均速度達到7998條記錄/秒..當使用SQLLoader輸出步驟,平均速度達到10021條記錄/秒線程同步問題酉己置svn在redhat2011-07-29源表和目標表各取一定數(shù)量記錄,判斷字段映射是否正確(映射字段)。指標計算是否正確(指標計算字段)4.隨機性驗證(隨機取幾條數(shù)據(jù),看是否有亂碼,異常數(shù)據(jù)等。測試重點項目中的關(guān)鍵業(yè)務,復雜邏輯部分作為測試重點用例劃分說明:按每個指標設計用例。測試策略:測試策略:增量測試(逐步提交測試)測試方法:基于查詢的測試(預期結(jié)果基于sql來展現(xiàn),做到數(shù)據(jù)變化,結(jié)果不變。另外便于回歸)2、標準數(shù)據(jù)集構(gòu)建造數(shù)據(jù)分2個方面,1個是直接抽取線上的數(shù)據(jù)1個是用腳本造異常數(shù)據(jù)。利用dblink抽取線上的數(shù)據(jù)。抽取線上數(shù)據(jù)時,需要注意,測試數(shù)據(jù)的全面性。即測試數(shù)據(jù)全面覆蓋。比如sex字段,在抽取線上數(shù)據(jù)時,需要抽取到ETL的一些概念(轉(zhuǎn))AnalysisWhatisalogicaldatamappingandwhatdoesitmeantotheETLteam?什么是邏輯數(shù)據(jù)映射?它對ETL項目組的作用是什么?答:邏輯數(shù)據(jù)映射(LogicalDataM叩)用來描述源系統(tǒng)的數(shù)據(jù)定義、目標數(shù)據(jù)倉庫的模型以及將源系統(tǒng)的數(shù)據(jù)轉(zhuǎn)換到數(shù)據(jù)倉庫中需要做操作和處理方式的說明文檔,通常以表格或Excel的格式保存如下的信息:目標表名:目標列名:目標表類型:注明是事實表、維度表或支架維度表。SCD類型:對于維度表而言。源數(shù)據(jù)庫名:源數(shù)據(jù)庫的實例名,或者連接字符串。源表名:源列名:轉(zhuǎn)換方法:需要對源數(shù)據(jù)做的操作,如Sum(amount)等。邏輯數(shù)據(jù)映射應該貫穿數(shù)據(jù)遷移項目的始終,在其中說明了數(shù)據(jù)遷移中的ETL在進行物理數(shù)據(jù)映射前進行邏輯數(shù)據(jù)映射對ETL項目組是重要的,它起著元數(shù)據(jù)的作用。項目中最好選擇能生成邏輯數(shù)據(jù)映射的數(shù)據(jù)遷移工具。Whataretheprimarygoalsofthedatadiscoveryphaseofthedatawarehouseproject?在數(shù)據(jù)倉庫項目中,數(shù)據(jù)探索階段的主要目的是什么?答:在邏輯數(shù)據(jù)映射進行之前,需要首先對所有的源系統(tǒng)進行分析。對源系統(tǒng)的分析通常包括兩個階段,一個是數(shù)據(jù)探索階段(DataDiscoveryPhase),另一個是異常數(shù)據(jù)檢測階段。數(shù)據(jù)探索階段包括以下內(nèi)容:.收集所有的源系統(tǒng)的文檔、數(shù)據(jù)字典等內(nèi)容。.收集源系統(tǒng)的使用情況,如誰在用、每天多少人用、占多少存儲空間等內(nèi)容。.判斷出數(shù)據(jù)的起始來源(System-of-Record\.通過數(shù)據(jù)概況(DataProfiling)來對源系統(tǒng)的數(shù)據(jù)關(guān)系進行分析。數(shù)據(jù)探索階段的主要目的是理解源系統(tǒng)的情況,為后續(xù)的數(shù)據(jù)建模和邏輯數(shù)據(jù)映射打下堅實的基礎。Howisthesystem-of-recorddetermined?如何確定起始來源數(shù)據(jù)?這個問題的關(guān)鍵是理解什么是System-of-RecordoSystem-of-Record和數(shù)據(jù)倉庫領域內(nèi)的其他很多概念一樣,不同的人對它有不同的定義。在Kimball的體系中,System-of-Record是指最初產(chǎn)生數(shù)據(jù)的地方,即數(shù)據(jù)的起始來源。在較大的企業(yè)內(nèi),數(shù)據(jù)會被冗余的保存在不同的地方,在數(shù)據(jù)的遷移過程中,會出現(xiàn)修改、清洗等操作,導致與數(shù)據(jù)的起始來源產(chǎn)生不同。起始來源數(shù)據(jù)對數(shù)據(jù)倉庫的建立有著非常重要的作用,尤其是對產(chǎn)生一致性維度來說。我們從起始來源數(shù)據(jù)的越下游開始建立數(shù)據(jù)倉庫,我們遇到垃圾數(shù)據(jù)的風險就會越大。ArchitectureWhatarethefourbasicDataFlowstepsofanETLprocess?在ETL過程中四個基本的過程分別是什么?Kimball數(shù)據(jù)倉庫構(gòu)建方法中,ETL的過程和傳統(tǒng)的實現(xiàn)方法有一些不同,主要分為四個階段,分別是抽取(extract\清洗(clean\一致性處理(comform)和交付(delivery),簡稱為ECCDO.抽取階段的主要任務是:讀取源系統(tǒng)的數(shù)據(jù)模型。連接并訪問源系統(tǒng)的數(shù)據(jù)。變化數(shù)據(jù)捕獲。抽取數(shù)據(jù)到數(shù)據(jù)準備區(qū)。.清洗階段的主要任務是:清洗并增補列的屬性。清洗并增補數(shù)據(jù)結(jié)構(gòu)。清洗并增補數(shù)據(jù)規(guī)則。增補復雜的業(yè)務規(guī)則。建立元數(shù)據(jù)庫描述數(shù)據(jù)質(zhì)量。將清洗后的數(shù)據(jù)保存到數(shù)據(jù)準備區(qū)。.一致性處理階段的主要任務是:一致性處理業(yè)務標簽,即維度表中的描述屬性。一致性處理業(yè)務度量及性能指標,通常是事實表中的事實。去除重復數(shù)據(jù)。國際化處理。將一致性處理后的數(shù)據(jù)保存到數(shù)據(jù)準備區(qū)。.交付階段的主要任務是:加載星型的和經(jīng)過雪花處理的維度表數(shù)據(jù)。產(chǎn)生日期維度。加載退化維度。加載子維度。加載1、2、3型的緩慢變化維度。處理遲到的維度和遲到的事實。加載多值維度。加載有復雜層級結(jié)構(gòu)的維度。加載文本事實到維度表。處理事實表的代理鍵。加載三個基本類型的事實表數(shù)據(jù)。加載和更新聚集。將處理好的數(shù)據(jù)加載到數(shù)據(jù)倉庫。從這個任務列表中可以看出,ETL的過程和數(shù)據(jù)倉庫建模的過程結(jié)合的非常緊密。換句話說,ETL系統(tǒng)的設計應該和目標表的設計同時開始。通常來說,數(shù)據(jù)倉庫架構(gòu)師和ETL系統(tǒng)設計師是同一個人。5.Whatarethepermissibledatastructuresforthedatastagingarea?Brieflydescribetheprosandconsofeach.在數(shù)據(jù)準備區(qū)中允許使用的數(shù)據(jù)結(jié)構(gòu)有哪些?各有什么優(yōu)缺點?答:.固定格式的文本文件。(FlatFile)FlatFile指的是一種保存在系統(tǒng)上的一種文本文件格式,它以類似數(shù)據(jù)庫的表的方式用行和列來保存數(shù)據(jù)。這種文件格式經(jīng)常用來進行數(shù)據(jù)交換。用于保存數(shù)據(jù)不太合適。.XML數(shù)據(jù)集。多用于數(shù)據(jù)交換,用戶保存數(shù)據(jù)不太合適。.關(guān)系數(shù)據(jù)庫的表。保存數(shù)據(jù)的較理想選擇。.獨立的數(shù)據(jù)庫表。獨立的數(shù)據(jù)庫表一般指建立的表和其他表沒有外鍵約束關(guān)系。這樣的表多用于數(shù)據(jù)處理。.三范式或者關(guān)系型模型。.非關(guān)系型數(shù)據(jù)源。非關(guān)系型數(shù)據(jù)源一般包括COBOLcopybooks.VSAM文件、Flat文件、Spreadsheets等。.維度模型。.原子事實表和聚集事實表。.代理鍵查找表。WhenshoulddatabesettodiskforsafekeepingduringtheETL?簡述ETL過程中哪個步驟應該出于安全的考慮將數(shù)據(jù)寫到磁盤上?答:Staging的意思就是將數(shù)據(jù)寫到磁盤上。出于安全及ETL能方便重新開始,在數(shù)據(jù)準備區(qū)(StagingArea)中的每個步驟中都應該將數(shù)據(jù)寫到磁盤上,即生成文本文件或者將建立關(guān)系表保存數(shù)據(jù),而不應該以數(shù)據(jù)不落地方式直接進行ETL。例如,在數(shù)據(jù)抽取階段,我們需要連接到源系統(tǒng),為了對源系統(tǒng)的影響盡量小,我們需要將抽取的數(shù)據(jù)保存成文本文件或者放入數(shù)據(jù)準備區(qū)的表中,這樣,當ETL過程出現(xiàn)錯誤而失敗時,我們就可以從這些文本文件開始ETL,而不需要再次影響源系統(tǒng)。male,female情況,而不能僅僅是male或female,這樣測試數(shù)據(jù)就會缺失。對于有關(guān)聯(lián)的表進行數(shù)據(jù)抽取時,可以先抽取主表,然后根據(jù)主表的數(shù)據(jù)有條件的抽取子表。3.2造異常數(shù)據(jù),異常數(shù)據(jù)可以從下面幾個方面進行考慮:字段類型、字段長度、空值、業(yè)務異常值、唯一約束值3、測試用例設計測試用例可以單獨設計,也可以采用調(diào)度的思想進行設計,采用調(diào)度方法進行設計時,能一次驗證多個用例,另外也方便回歸。這里說一下調(diào)度思想的測試用例的設計思路。設計思路:個人的一些想法:就像文中所說的,由于每個人的配置不一樣,可能你精通kettle,所以你測試出來的結(jié)果kettle會比較快,如果你精通talend,可能talend測試出來的比較快,所以一味的比較速度沒有意思,沒有辦法在統(tǒng)一環(huán)境下測試.另外就是個人覺得ETL工具的性能并不是ETL工具最先考慮的東西,功能和易用性和可管理性才是最重要的,kettle在功能和易用性上得分比較高,可管理性則是很一般.ExtractDescribetechniquesforextractingfromheterogeneousdatasources.簡述異構(gòu)數(shù)據(jù)源中的數(shù)據(jù)抽取技術(shù)。答:在數(shù)據(jù)倉庫項目中,需要抽取的數(shù)據(jù)經(jīng)常來自不同的數(shù)據(jù)源,它們的邏輯結(jié)構(gòu)和物理結(jié)構(gòu)都可能不同,即稱之為異構(gòu)數(shù)據(jù)源。在對異構(gòu)數(shù)據(jù)源進行整合抽取時,我們需要做的事情依次是標識出所有的源系統(tǒng),對源系統(tǒng)進行概況分析,定義數(shù)據(jù)匹配邏輯,建立篩選規(guī)則,生成一致性維度。對于源數(shù)據(jù)的操作系統(tǒng)平臺和數(shù)據(jù)平臺各不相同的情況,我們需要根據(jù)實際情況來確定如何進行數(shù)據(jù)抽取,通常的方法有建立ODBC連接、定義接口文件、建立DBLINK等方法。WhatisthebestapproachforhandlingERPsourcedata?從ERP源系統(tǒng)中抽取數(shù)據(jù)最好的方法是什么?答:ERP系統(tǒng)的產(chǎn)生是為了解決企業(yè)內(nèi)異構(gòu)數(shù)據(jù)的整合。這個問題也是數(shù)據(jù)倉庫系統(tǒng)面臨的主要問題。ERP的解決方案是將企業(yè)內(nèi)的各個應用包括銷售、會計、人力資源、庫存和產(chǎn)品等)建立在相同的平臺和相同的應用框架下,即在應用操作層將企業(yè)內(nèi)的數(shù)據(jù)進行了一致性處理。而數(shù)據(jù)倉庫是在應用操作層之上建立一致性的規(guī)則并進行一致性處理。目前比較流行的ERP系統(tǒng)有SAP、Peoples。代、Oracle.Baan和J.D.EDwards(大部分沒接觸過\如果企業(yè)內(nèi)只有一套ERP系統(tǒng),那么數(shù)據(jù)就已經(jīng)是一致的了,為數(shù)據(jù)抽取提供了方便。如果企業(yè)內(nèi)除了ERP外還有其他系統(tǒng),則數(shù)據(jù)抽取會變得復雜。因為目前的ERP系統(tǒng)的數(shù)據(jù)模型都非常復雜,可能有幾百幾千個表,并且較難理解。直接在ERP系統(tǒng)上建立數(shù)據(jù)捕獲和抽取是非常復雜的。最好的辦法是購買能針對ERP系統(tǒng)數(shù)據(jù)抽取提供功能的ETL工具,將ERP內(nèi)部的復雜性留給ETL廠商處理。ExplaintheprosandconsofcommunicatingwithdatabasesnativelyversusODBC.簡述直接連接數(shù)據(jù)庫和使用ODBC連接數(shù)據(jù)庫進行通訊的優(yōu)缺點。答:通常連接數(shù)據(jù)庫的方式分為兩類,一類是直接連接,另一類是通過ODBC連接。直接連接的方式主要是通過COBOL、PL/SQL、Transact-SQL等方式連接數(shù)據(jù)庫。這種方式的優(yōu)點是運行性能高,可以使用DBMS提供的一些特殊功能。缺點是通用性差。ODBC是為windows應用程序訪問數(shù)據(jù)庫提供的一組接口。ODBC的優(yōu)點是靈活性,通過改變驅(qū)動和連接方式可以使用不同的數(shù)據(jù)庫。ODBC方式的缺點是性能差。使用ODBC連接方式實現(xiàn)ETL的話,在ETL程序和至少要有兩層,分另(!是ODBCManager層和ODBCDriver層。另外,使用ODBC方式不能使用DBMS提供的一些特殊的功能。Describethreechangedatacapture(CDC)practicesandtheprosandconsofeach.簡述出三種變化數(shù)據(jù)捕獲技術(shù)及其優(yōu)缺點。答:變化數(shù)據(jù)捕獲(CDC)技術(shù)是ETL工作中的重點和難點,通常需要在增量抽取時完成。實現(xiàn)變化數(shù)據(jù)捕獲時最理想的是找到源系統(tǒng)的DBAO如果不能找到,就需要ETL項目組自己進行檢測數(shù)據(jù)的變化。下面是一些常用的技術(shù)。.采用審計列審計列指表中如“添加日期"、"修改日期〃、“修改人”等信息的字段。應用程序在對該表的數(shù)據(jù)進行操作時,同時更新這些字段,或者建立觸發(fā)器來更新這些字段。采用這種方式進行變化數(shù)據(jù)捕獲的優(yōu)點是方便,容易實現(xiàn)。缺點是如果操作型系統(tǒng)沒有相應的審計字段,需要改變已有的操作型系統(tǒng)的數(shù)據(jù)結(jié)構(gòu),以保證獲取過程涉及的每張表都有審計字段。.數(shù)據(jù)庫日志DBMS日志獲取是一種通過DBMS提供的日志系統(tǒng)來獲得變化的數(shù)據(jù)。它的優(yōu)點是對數(shù)據(jù)庫或訪問數(shù)據(jù)庫的操作系統(tǒng)的影響最小。缺點是要求DBMS支持,并且對日志記錄的格式非常了解。全表掃描或者全表導出文件后進行掃描對比也可以進行變化數(shù)據(jù)捕獲,尤其是捕獲刪除的數(shù)據(jù)時。這種方法的優(yōu)點是,思路清晰,適應面廣,缺點是效率比較差。DataQuality11.Whatarethefourbroadcategoriesofdataqualitychecks?Provideanimplementationtechniqueforeach.數(shù)據(jù)質(zhì)量檢查的四大類是什么?為每類提供一種實現(xiàn)技術(shù)。答:數(shù)據(jù)質(zhì)量檢查是ETL工作中非常重要的一步,主要關(guān)注一下四個方面。.正確性檢查(Corret)檢查數(shù)據(jù)值及其描述是否真實的反映了客觀事務。例如地址的描述是否完全。.明確性檢查(Unambiguous)檢查數(shù)據(jù)值及其描述是否只有一個意思或者只有一個解釋。例如地名相同的兩個縣需要加區(qū)分方法。.一致性檢查(Consistent)檢查數(shù)據(jù)值及其描述是否統(tǒng)一的采用固定的約定符號來表示。例如幣別中人民幣用CNY'。.完全性檢查(Complete)完全性有兩個需要檢查的地方,一個是檢查字段的數(shù)據(jù)值及其描述是否完全。例如檢查是否有空值。另一個是檢查記錄的合計值是否完全,有沒有遺忘某些條件。AtwhichstageoftheETLshoulddatabeprofiled?簡述應該在ETL的哪個步驟來實現(xiàn)概況分析?答:數(shù)據(jù)概況分析是對源數(shù)據(jù)內(nèi)容的概況進行分析,應該在項目的開始后盡早完成,它會對設計和實現(xiàn)有很大的影響。在完成需求收集后就應該立即開始數(shù)據(jù)概況分析。數(shù)據(jù)概況分析不光是對源系統(tǒng)的數(shù)據(jù)概況的定量描述,而且為ETL系統(tǒng)中需要建立的錯誤事件事實君ErrorEventTable而審計維度君AuditDimension)打下基礎,為其提供數(shù)據(jù)。WhataretheessentialdeliverablesofthedataqualityportionofETL?ETL項目中的數(shù)據(jù)質(zhì)量部分核心的交付物有那些?答:ETL項目中數(shù)據(jù)質(zhì)量部分的核心的交付物主要有下面三個:.數(shù)據(jù)概況分析結(jié)果數(shù)據(jù)概況分析結(jié)果是對源系統(tǒng)的數(shù)據(jù)狀況的分析產(chǎn)物,包括如源系統(tǒng)中有多少個表,每個表有多少字段,其中多少為空,表間的外鍵關(guān)系是否存在等反映源系統(tǒng)數(shù)據(jù)質(zhì)量的內(nèi)容。這些內(nèi)容用來決定數(shù)據(jù)遷移的設計和實現(xiàn),并提供給錯誤事件事實表和審計維度表需要的相關(guān)數(shù)據(jù)。.錯誤事件事實表錯誤事件事實表及相關(guān)的一系列維度表是數(shù)據(jù)質(zhì)量檢查部分的一個主要交付物。粒度是每一次數(shù)據(jù)質(zhì)量檢查中的錯誤信息。相關(guān)維度包括日期維度表、遷移信息維度表、錯誤事件信息維度表,其中錯誤事件信息維度表中檢查的類型、源系統(tǒng)的信息、涉及的表信息、檢查使用的SQL等內(nèi)容。錯誤事件事實表不提供給前臺用戶。.審計維度表審計維度表是給最終用戶提供數(shù)據(jù)質(zhì)量說明的一個維度表。它描述了用戶使用的事實表的數(shù)據(jù)來源,數(shù)據(jù)質(zhì)量情況等內(nèi)容。Howcandataqualitybequantifiedinthedatawarehouse?如何來量化數(shù)據(jù)倉庫中的數(shù)據(jù)質(zhì)量?答:在數(shù)據(jù)倉庫項目中,通常通過不規(guī)則數(shù)據(jù)的檢測工作(AnomalyDetection)來量化源系統(tǒng)的數(shù)據(jù)質(zhì)量。除非成立專門的數(shù)據(jù)質(zhì)量調(diào)查項目組,否則這個工作應該由ETL項目組完成。通??梢圆捎梅纸MSQL來檢查數(shù)據(jù)是否符合域的定義規(guī)則。對于數(shù)據(jù)量小的表,可以直接使用類似下面的SQL完成。selectstate,count(*)fromorder_detailgroupbystate對于數(shù)據(jù)量大的表,一般通過采樣技術(shù)來減少數(shù)據(jù)量,然后進行不規(guī)則數(shù)據(jù)檢測。類似SQL如下。selecta?fromemployeea,(selectrownumcounter,a.*fromemployeea)Bwherea.empjd=b.empjdandmod(b.counter;trunc((selectcount(*)fromemployee)/1000,0))=0如果可以采用專門的數(shù)據(jù)概況分析工具進行的話,可以減少很大的工作量。BuildingmappingsWhataresurrogatekeys?Explainhowthesurrogatekeypipelineworks.什么是代理鍵?簡述代理鍵替換管道如何工作。答:在維度表的遷移過程中,有一種處理方式是使用無意義的整型值分配給維度記錄并作為維度記錄的主鍵,這些作為主鍵的整型值稱為代理鍵(SurrogateKeyX使用代理鍵有很多好處,如隔離數(shù)據(jù)倉庫與操作環(huán)境,歷史記錄的保存,查詢速度快等。同時,在事實表的遷移過程中,為了保證參照完整性也需要進行代理鍵的替換工作。為了代理鍵替換的效率高一些,我們通常在數(shù)據(jù)準備區(qū)中建立代理鍵查找表(SurrogateMappingTableorLookupTable\代理鍵查找表中保存最新的代理鍵和自然鍵的對應關(guān)系。在對事實表進行代理鍵替換時,為了保證效率高,需要把代理鍵查找表中的數(shù)據(jù)加載到內(nèi)存中,并可以開多線程依次替換同一記錄的中的不同代理鍵,使一條事實記錄在所有的代理鍵都替換完后再寫如磁盤中,這樣的替換過程稱為代理鍵替換管道(SurrogateKeyPipelineXWhydodatesrequirespecialtreatmentduringtheETLprocess?為什么在ETL的過程中需要對日期進行特殊處理?另外ETL工具中kettle的性能一向都是很強的,早在kettle被pentaho收購之前,它在亞馬遜云上的5臺服務器的集群速度就是4000row*5,而且由于kettle配置集群又超級簡單,而且是根據(jù)端口來區(qū)分節(jié)點,所以一臺計算機上都可以配置幾個從服務器,上面給出的代碼中就是這樣的,不會配置的朋友可以看一下,(真的就是看一眼就懂了).另外一^覺得很有意思的ETL工具就是oracle的warehousebuild和dataintegration,由于里面使用的是oracle數(shù)據(jù)庫專有的pl/sql,不太清楚它的伸縮能力怎么樣(oracle的hints里面是可以控制并行度的,不知道pl/sql會不會也有控制并行度的選項)再加上kettle的分區(qū)特性和正在做的"可配置并行度",kettle的伸縮能力是很強的.所以性能問題一向都不是kettle的弱項.最后要說的就是還是最關(guān)心kettle的可管理性,它的"transform和job”的版本控制和"Repository"的全庫導入導出不知道什么時候可以做好.答:在數(shù)據(jù)倉庫的項目中,分析是主導需求,而基于日期和時間的分析更是占了很大的比重。而在操作型源系統(tǒng)中,日期通常都是SQL的DATETIME型的。如果在分析時,使用SQL對這種類型的字段臨時處理會出現(xiàn)一些問題,如效率很差,不同的用戶會采用不同的格式化方法導致報表不統(tǒng)一。所以,在數(shù)據(jù)倉庫的建模時都會建立日期維度表和時間維度表,將用到的和日期相關(guān)的描述都冗余到該表中。但是,并不是所有的日期都被轉(zhuǎn)化為日期維度表的外鍵。日期維度表中的記錄是有限的,有些日期如生日等可能會比日期維度表中記錄的最小日期還要早,這類字段可以直接在數(shù)據(jù)倉庫中保存SQL的DATETIME型。而像購買日期等與分析的業(yè)務緊密相關(guān)的通常都需要轉(zhuǎn)化為日期維度表的外鍵,可以用日期維度表中統(tǒng)一的描述信息進行分析。Explainthethreebasicdeliverystepsforconformeddimensions.簡述對一致性維度的三種基本的交付步驟。答:數(shù)據(jù)整合的關(guān)鍵就是生成一致性維度,再通過一致性維度將來自不同數(shù)據(jù)源的事實數(shù)據(jù)合并到一起,供分析使用。通常來說,生成一致性維度有如下三個步驟:.標準化(Standardizing)標準化的目的是使不同數(shù)據(jù)源的數(shù)據(jù)編碼方式,數(shù)據(jù)格式等相同,為下一步數(shù)據(jù)匹配打下基礎。.匹配(MatchingandDeduplication)數(shù)據(jù)匹配的工作有兩種,一種是將不同數(shù)據(jù)源的標識同一事物的不同屬性匹配到一起,是數(shù)據(jù)更完善;另一種是將不同數(shù)據(jù)源的相同數(shù)據(jù)標識成重復,為下一步的篩選打下基礎。.篩選(Surviving)數(shù)據(jù)篩選的主要目的是選定一致性維度作為主數(shù)據(jù)(MasterData),也就是最終交付的一致性維度數(shù)據(jù)。NamethethreefundamentalfactgrainsanddescribeanETLapproachforeach.簡述三種基本事實表,并說明ETL的過程中如何處理它們。答:事實表從粒度的角色來劃分可以分為三類,分別是交易粒度事實表(TransactionGrain\周期快照粒度事實表(PeriodicSnapshot)和累計快照粒度事實表(AccumulatingSnapshotX在事實表的設計時,一定要注意一個事實表只能有一個粒度,不能將不同粒度的事實建立在同一張事實表中。交易粒度事實表的來源伴隨交易事件成生的數(shù)據(jù),例如銷售單。在ETL過程中,以原子粒度直接進行遷移。周期快照事實表是用來記錄有規(guī)律的定時間間隔的業(yè)務累計數(shù)據(jù),例如庫存日快照。在ETL過程中,以固定的時間間隔生成累計數(shù)據(jù)。周期快照事實表是用來記錄有規(guī)律的定時間間隔的業(yè)務累計數(shù)據(jù),例如庫存累積快照事實表用來記錄具有時間跨度的業(yè)務處理過程的整個過程的信息。在ETL過程中,隨著業(yè)務處理過程的步驟逐步完善該表中的記錄。Howarebridgetablesdeliveredtoclassifygroupsofdimensionrecordsassociatedtoasinglefact?簡述橋接表是如何將維度表和事實表進行關(guān)聯(lián)的?答:橋接表(BridgeTable)是維度建模中的一類比較特殊的表。在數(shù)據(jù)倉庫的建模時,會遇到具有層次結(jié)構(gòu)的維度表,對于這樣的表有一種建模方式是建立父子表,即每條記錄上包括一個指向其父記錄的字段。這種父子表的建立在層級深度可變時尤其有用,是一個緊湊而有效的建模方式。但是這種建模方式也有缺點,就是用標準SQL很難對遞歸結(jié)構(gòu)進行操作。與這種遞歸結(jié)構(gòu)的父子表不同,橋接表采用不同的建模方式也可以表示這種層級結(jié)構(gòu)。橋接表是建立在維度表和事實表中間的一個具有較多冗余信息的表,其中的記錄包含層級結(jié)構(gòu)中節(jié)點到其下面每個節(jié)點的路徑。表結(jié)構(gòu)如下所示:父關(guān)鍵字子關(guān)鍵字父層數(shù)層名底端標識頂端標識在橋接表中,節(jié)點與其下面的任意一個節(jié)點都建立一個關(guān)聯(lián)記錄保存在表中,即父子關(guān)系不再局限在相鄰層,如第一層與第三層同樣有父子關(guān)系,通過父層數(shù)可以區(qū)分相隔了幾層。這樣,可以通過父層數(shù)和父子關(guān)系來進行層級結(jié)構(gòu)的查詢。當然,橋接表也不是一個完備的解決方案,它只能是在某些情況下是查詢變得容易。Howdoeslatearrivingdataaffectdimensionsandfacts?Sharetechniquesforhandlingeach.遲到的數(shù)據(jù)對事實表和維度表有什么影響?怎樣來處理這個問題?答:遲到的數(shù)據(jù)分為兩種,一種是遲到的事實表數(shù)據(jù),另一種是遲到的維度表數(shù)據(jù)。對于遲到的事實記錄,我們可以插入到相應的事實表中。在插入的同時,還需要做一些處理。首先,對于具有SCDTYPE2型維度的事實記錄需要在插入前判斷該事實記錄的發(fā)生日期到目前為止,維度記錄是否發(fā)生過變化,如果有變化,該事實記錄需要對應到事實發(fā)生時的維度記錄上。其次,在事實記錄插入完成后,與該事實表相關(guān)的聚集事實表和合并事實表需要做相應的處理。對于遲到的維度記錄,我們需要做的處理要復雜一些。首先,如果遲到的維度記錄是第一次進入數(shù)據(jù)倉庫中,那么需要在維度表中生成一條維度記錄,并將與該維度記錄對應的事實記錄的外鍵進行更新。其次,如果遲到的維度記錄是對原維度進行的修改,那么我們在維度表中生成一條新記錄的同時,還需要找到維度本次變化到下次變化間的事實行,并將其維度外鍵更新為新加維度的代理關(guān)鍵字。MetadataDescribethedifferenttypesofETLmetadataandprovideexamplesofeach.舉例說明各種ETL過程中的元數(shù)據(jù)。答:元數(shù)據(jù)是ETL項目組面對的一個非常重要的主題,對于整個數(shù)據(jù)倉庫項目也是非常重要的一部分。對于元數(shù)據(jù)的分類和使用沒有很確定的定義。通常來說,我們可以把元數(shù)據(jù)分為三類,分別為業(yè)務元數(shù)據(jù)(BusinessMetadata),技術(shù)元數(shù)據(jù)(TechnicalMetadata)和過程處理元數(shù)據(jù)(ProcessExecutionMetadata'業(yè)務元數(shù)據(jù),是從業(yè)務的角度對數(shù)據(jù)的描述。通常是用來給報表工具和前端用戶對數(shù)據(jù)進行分析和使用提供幫助。技術(shù)元數(shù)據(jù),是從技術(shù)的角度對數(shù)據(jù)的描述。通常包括數(shù)據(jù)的一些屬性,如數(shù)據(jù)類型、長度、或者數(shù)據(jù)概況分析后一些結(jié)果。過程處理元數(shù)據(jù),是ETL處理過程中的一些統(tǒng)計數(shù)據(jù),通常包括有多少條記錄被加載,多少條記錄被拒絕接受等數(shù)據(jù)Shareacceptablemechanismsforcapturingoperationalmetadata.簡述獲取操作型元數(shù)據(jù)的方法。答:操作型元數(shù)據(jù)(OperationalMetadata),也就是過程處理元數(shù)據(jù),記錄的是ETL過程中數(shù)據(jù)遷移情況,如上次遷移日期,加載的記錄數(shù)等信息。這部分元數(shù)據(jù)在ETL加載失敗時會非常重要。一般來說,對于使用ETL工具的數(shù)據(jù)加載,像遷移調(diào)度時間、遷移調(diào)度順序,失敗處理等內(nèi)容都可以在由在遷移工具中定義生成。像上次遷移日期等數(shù)據(jù)可以建表保存。如果是手工編寫ETL程序的話,操作型元數(shù)據(jù)的處理會麻煩一些,需要自己來獲取和存儲。獲取的方式,不同的編程方式會不盡相同。Offertechniquesforsharingbusinessandtechnicalmetadata.Optimization/Operations簡述共享業(yè)務元數(shù)據(jù)和技術(shù)元數(shù)據(jù)的方法。答為了能共享各種元數(shù)據(jù),在數(shù)據(jù)倉庫的構(gòu)建過程中必須要有一些元數(shù)據(jù)標準,并在實際開發(fā)中遵守這些標準。這些標準包括元數(shù)據(jù)命名規(guī)則、存儲規(guī)則及共享規(guī)則等內(nèi)容。有關(guān)元數(shù)據(jù)標準的內(nèi)容可以參看公共倉庫元模型(CommonWarehouseMetamodel,CWM)的相關(guān)資料。在最基本的層面上,企業(yè)應該在下面三個方面制定好標準。.命名規(guī)則命名規(guī)則應該在ETL組開始編碼前制定好,范圍包括表、歹I」、約束、索引等等數(shù)據(jù)庫對象以及其他一些編碼規(guī)則。如果企業(yè)有自己的命名規(guī)則,ETL組應該遵守企業(yè)的命名規(guī)則。當企業(yè)的命名規(guī)則不能完全滿足需求時,ETL組可以制定補充規(guī)則或者新的規(guī)則。對企業(yè)命名規(guī)則的改變需要有詳細的文檔記錄,并提交企業(yè)相關(guān)部門審核。.架構(gòu)在ETL組開始工作前,架構(gòu)應該先被設計好。例如ETL引擎是和數(shù)據(jù)倉庫放在同一臺服務器上還是單獨設立服務器;數(shù)據(jù)準備區(qū)是建立成臨時的還是持久的;數(shù)據(jù)倉庫是基于維度建模的還是3NF建模的。并且這些內(nèi)容應該有詳細的文檔記錄。.基礎結(jié)構(gòu)系統(tǒng)的基礎結(jié)構(gòu)也應該先確定好。例如解決方案是基于Windows的還是基于UNIX的。這些企業(yè)基礎結(jié)構(gòu)元數(shù)據(jù)應該在ETL組開始工作前制定好。這些內(nèi)容也應該有詳細的文檔記錄。在ETL的開發(fā)中,制定好元數(shù)據(jù)標準并能很好的遵守,那么建立好的數(shù)據(jù)倉庫的元數(shù)據(jù)就可以很好的完成共享功能。Statetheprimarytypesoftablesfoundinadatawarehouseandtheorderwhichtheymustbeloadedtoenforcereferentialintegrity.簡述數(shù)據(jù)倉庫中的表的基本類型,以及為了保證引用完整性該以什么樣的順序?qū)λ鼈冞M行加載。答:數(shù)據(jù)倉庫中的表的基本類型有維度表、事實表、子維度表、橋接表等幾類。其中子維度表即雪花模型由支架維度技術(shù)處理,橋接表用來處理多值維度或?qū)蛹壗Y(jié)構(gòu)。數(shù)據(jù)倉庫中需要加載的各類表之間有相互依賴的關(guān)系,所以加載時需要以一定的順序進行加載。下面是一些加載的基本原則:子維度表加載成功后,再加載維度表。開源ETL工具kettle系列之常見問題摘要:本文主要介紹使用kettle設計一些ETL任務時一些常見問題,這些問題大部分都不在官方FAQ上,你可以在kettle的論壇上找到一些問題的答案1.Join我得到A數(shù)據(jù)流(不管是基于文件或數(shù)據(jù)庫),A包含fieldl,field2,field3字段,然后我還有一個B數(shù)據(jù)流,B包含field4,fields,field6,我現(xiàn)在想把它們‘加’起來,應該怎么樣做.這是新手最容易犯錯的一個地方,A數(shù)據(jù)流跟B數(shù)據(jù)流能夠Join,肯定是它們包含joinkeyjoinkey可以是一個字段也可以是多個字段。如果兩個數(shù)據(jù)流沒有joinkey,那么它們就是在做笛卡爾積,一般很少會這樣。比如你現(xiàn)在需要列出一個員工的姓名和他所在部門的姓名,如果這是在同一個數(shù)據(jù)庫,大家都知道維度表加載成功后,再加載橋接表。子維度表、維度表和橋接表都加載成功后,再加載事實表。這個加載順序可以通過主外鍵的關(guān)系來確定。(注意,此回答為總線架構(gòu)的數(shù)據(jù)倉庫的表的加載順序。)WhatarethecharacteristicsofthefourlevelsoftheETLsupportmodel?簡述ETL技術(shù)支持工作的四個級別的特點。答:數(shù)據(jù)倉庫上線后,ETL組需要為保證ETL工作的正常運行提供技術(shù)支持。通常這種技術(shù)支持工作分為四個級別。1.第一級別的技術(shù)支持通常是電話支持人員,屬于技術(shù)支持服務窗口(HelpDesk)類型。如果數(shù)據(jù)遷移出現(xiàn)錯誤或者用戶發(fā)現(xiàn)數(shù)據(jù)有問題,問題通過電話反映到第一級別的技術(shù)支持處。第一級別支持人員通過ETL項目組提供的一些問題的解決辦法盡可能的解決發(fā)現(xiàn)的問題,阻止問題升級。2.第二級別的技術(shù)支持通常是系統(tǒng)管理員和DBA。如果第一級別不能解決問題,問題反映到第二級別。第二級別的人員通常技術(shù)上比較強,硬件基礎結(jié)構(gòu)和軟件架構(gòu)上的問題都可以解決。3.第三級別的技術(shù)支持通常是ETL項目負責人。如果第二級別不能解決問題,問題反映到第三級別。ETL項目負責人應該具備足夠的知識,能夠解決生產(chǎn)環(huán)境中的絕大部分問題。ETL項目負責人在必要時可以和開發(fā)人員或者外部產(chǎn)品提供商對某些問題進行交流,以便找出解決問題的辦法。4.第四級別的技術(shù)支持通常是ETL的實際開發(fā)人員。如果第三級別不能解決問題,問題反映到第四級別。ETL的實際開發(fā)人員可以對代碼進行跟蹤分析并找到問題的解決辦法。如果問題出現(xiàn)在產(chǎn)品供應商的應用中,還需要供應商提供技術(shù)支持。在小些的數(shù)據(jù)倉庫環(huán)境中,也是通常的情況下,第三級別和第!1!級別可以合并在一起。合并后對第二級別的要求會高一些。不建議每次出現(xiàn)問題都找ETL的開發(fā)人員。第一級別的技術(shù)支持人員不應該僅僅提供電話支持服務,在將問題反映給下一個級別前,要盡自己的能力去解決問題。在小些的數(shù)據(jù)倉庫環(huán)境中,也是通常的情況下,第三級別和第!1!級別可以合并WhatstepsdoyoutaketodeterminethebottleneckofaslowrunningETLprocess?如果ETL進程運行較慢,需要分哪幾步去找到ETL系統(tǒng)的瓶頸問題。答:ETL系統(tǒng)遇到性能問題,運行很慢是一件較常見的事情,這時要做的是逐步找到系統(tǒng)的瓶頸在哪里。首先要確定是由CPU、內(nèi)存、I/O和網(wǎng)絡等產(chǎn)生的瓶頸,還是由ETL處理過程產(chǎn)生的瓶頸。如果環(huán)境沒有瓶頸,那么需要分析ETL的代碼。這時,我們可以采用排除的方法,需要隔離不同的操作,并分別對它們進行測試。如果是采用純手工編碼方式的ETL處理,隔離不同的操作要麻煩一些,這時需要根據(jù)編碼的實際情況來處理。如果是采用ETL工具的話,目前的ETL工具應該都有隔離不同處理的功能,隔離起來相對容易一些。分析最好從抽取操作開始,然后依次分析各種計算、查找表、聚集、過濾等轉(zhuǎn)換環(huán)節(jié)的處理操作,最后分析加載操作。實際的處理中,可以按照下面的七個步驟來查找瓶頸。.隔離并執(zhí)行抽取查詢語句。先將抽取部分隔離出來,去掉轉(zhuǎn)換和交付,可以將數(shù)據(jù)直接抽取到文件中。如果這一步效率很差,基本確定是抽取SQL的問題。從經(jīng)驗來看,未經(jīng)調(diào)優(yōu)的SQL是一個最常見的導致ETL效率差的原因。如果這步?jīng)]有問題進入第二步。.去掉過濾條件。這一條是針對全抽取,然后在ETL處理中進行過濾的處理方式而言。在ETL處理中做過濾處理有時會產(chǎn)生瓶頸??梢韵葘⑦^濾去掉,如果確定為這個原因,可以考慮在抽取時進行數(shù)據(jù)過濾。.排除查找表的問題。參照數(shù)據(jù)在ETL處理過程中通常會加載到內(nèi)存中,目的是做代碼和名稱的查找替換,也稱查找表。有時查找表的數(shù)據(jù)量過大也會產(chǎn)生瓶頸??梢灾饌€隔離查找表,來確定是否是這里出現(xiàn)問題。注意要將查找表的數(shù)據(jù)量降到最低,通常一個自然鍵一個代理鍵就可以,這樣可以減少不必要的數(shù)據(jù)1/00.分析排序和聚集操作。排序和聚集操作都是非常費資源的操作。對這部分隔離,來判斷是否因為它們引起性能問題。如果確定是因為這個,需要考慮是否可以將排序和聚集處理移出數(shù)據(jù)庫和ETL工具,移到操作系統(tǒng)中來處理。.隔離并分析每一個計算和轉(zhuǎn)換處理。有時轉(zhuǎn)換過程中的處理操作也會引起ETL工作的性能。逐步隔離移除它們來判斷哪里出了問題。要注意觀察像默認值、數(shù)據(jù)類型轉(zhuǎn)換等操作。.隔離更新策略。更新操作在數(shù)據(jù)量非常大時是性能非常差的。隔離這部分,看看是否這里出了問題。如果確定是因為大批量更新出了性能問題。應該考慮將insert、update和delete分開處理。.檢測加載數(shù)據(jù)的數(shù)據(jù)庫I/O。如果前面各部分都沒有問題,最后需要檢測是目標數(shù)據(jù)庫的性能問題??梢哉覀€文件代替數(shù)據(jù)庫,如果性能提高很多,需要仔細檢測目標數(shù)據(jù)庫的加載過程中的操作。例如是否關(guān)閉了所有的約束,關(guān)閉了所有的索引,是否使用了批量加載工具。如果性能還沒有提高,可以考慮使用并行加載策略。27.DescribehowtoestimatetheloadtimeofalargeETLjob.RealTimeETL簡述如何評估大型ETL數(shù)據(jù)加載時間。答:評估一個大型的ETL的數(shù)據(jù)加載時間是一件很復雜的事情。數(shù)據(jù)加載分為兩類,一類是初次加載,另一類是增量加載。在數(shù)據(jù)倉庫正式投入使用時,需要進行一次初次加載,而這次初次加載需要的時間一般較難預料。在數(shù)據(jù)倉庫的日常使用和維護中,每天需要對數(shù)據(jù)倉庫進行增量加載。增量加載的數(shù)據(jù)量要比初次加載小很多。下面以初次加載為例來談談如何評估大型ETL的數(shù)據(jù)加載時間。對初次加載的加載時間進行預估,需要將整個ETL過程分成抽取、轉(zhuǎn)換和加載三部分,分別對這三部分進行評估。.對抽取時間的評估。抽取通常占用的ETL的大部分時間,而且對這部分需要時間的評估也是非常困難的。為了對這部分時間進行評估,我們可以將查詢時間分成兩部分,一部分是查詢響應時間,另一部分是數(shù)據(jù)返回時間。查詢響應時間指從查詢開始執(zhí)行到結(jié)果開始返回這段時間。數(shù)據(jù)返回時間指第一條記錄返回到最后一條記錄返回的時間。另外,初次加載的數(shù)據(jù)量太大,我們可以考慮選擇其中的一部分來評估整體的時間,實際處理中,可以選擇事實表的一個分區(qū)。一般來說各個分區(qū)的數(shù)據(jù)量差不多,評估出一個分區(qū)的時間,乘上分區(qū)數(shù)可以作為整體的評估時間。.對數(shù)據(jù)轉(zhuǎn)換時間的評估數(shù)據(jù)轉(zhuǎn)換工作通常在內(nèi)存中完成,一般來說都有著非常快的速度,占總體時間的比重比較小。如果要評估這部分需要的時間的話,最簡單的評估方法是先評估出抽取時間和加載時間然后運行整個過程用整體時間減去抽取時間和加載時間。.對加載時間的評估很多原因都可能影響加載時間,其中最重要的兩個分別是索引和日志。對加載時間的評估,也可以像評估抽取時間時一樣,選擇加載數(shù)據(jù)的一部分,如1/200進行加載,計算出時間后乘以200來作為整體加載時間。總之,大型ETL數(shù)據(jù)的加載時間的評估是很困難的,我們采用的方法主要是類比評估,即選擇一部分數(shù)據(jù)減少整體時間進行評估。在進行評估時要注意到測試環(huán)境和生產(chǎn)環(huán)境的配置等的差別會引起評估結(jié)果的偏差。雖然這種對時間的評估一定會有誤差,但是可以做為整體加載時間的一個參考。28.Describethearchitectureoptionsforimplementingreal-timeETL簡述在架構(gòu)實時ETL時的可以選擇的架構(gòu)部件。答:在建立數(shù)據(jù)倉庫時,ETL通常都采用批處理的方式,一般來說是每天的夜間進行跑批。隨著數(shù)據(jù)倉庫技術(shù)的逐步成熟,企業(yè)對數(shù)據(jù)倉庫的時間延遲有了更高的要求,也就出現(xiàn)了目前常說的實時ETL(Real-TimeETLX實時ETL是數(shù)據(jù)倉庫領域里比較新的一部分內(nèi)容。在構(gòu)建實時ETL架構(gòu)的數(shù)據(jù)倉庫時,有幾種技術(shù)可供選擇。.微批處理(microbatchETL,MB-ETL)微批處理的方式和我們通常的ETL處理方式很相似但是處理的時間間隔要短,例如間隔一個小時處理一次。.企業(yè)應用集成(EnterpriseApplicationIntegration,EAI)EAI也稱為功能整合,通常由中間件來完成數(shù)據(jù)的交互。而通常的ETL稱為數(shù)據(jù)整合。對實時性要求非常高的系統(tǒng),可以考慮使用EAI作為ETL的一個工具,可以提供快捷的數(shù)據(jù)交互。不過在數(shù)據(jù)量大時采用EAI工具效率比較差,而且實現(xiàn)起來相對復雜。.CTF(Capture,TransformandFlow)CTF是一類比較新的數(shù)據(jù)整合工具。它采用的是直接的數(shù)據(jù)庫對數(shù)據(jù)庫的連接方式,可以提供秒級的數(shù)據(jù)。CTF的缺點是只能進行輕量級的數(shù)據(jù)整合。通常的處理方式是建立數(shù)據(jù)準備區(qū),采用CTF工具在源數(shù)據(jù)庫和數(shù)據(jù)準備區(qū)的數(shù)據(jù)庫之間相連接。數(shù)據(jù)進入數(shù)據(jù)準備區(qū)后再經(jīng)過其他處理后遷移入數(shù)據(jù)倉庫。.Eli(EnterpriseInformationIntegration)Eli是另一類比較新的數(shù)據(jù)整合軟件,可以給企業(yè)提供實時報表。EII的處理方式和CTF很相似,但是它不將數(shù)據(jù)遷移入數(shù)據(jù)準備區(qū)或者數(shù)據(jù)倉庫,而是在抽取轉(zhuǎn)換后直接加載到報表中。在實際建立實時ETL架構(gòu)的數(shù)據(jù)倉庫時,可以在MB-ETL,EAI,CTF,EH及通常的ETL中作出選擇或者進行組合。29.Explainthedifferentreal-timeapproachesandhowtheycanbeappliedindifferentbusinessscenarios.簡述幾種不同的實時ETL實現(xiàn)方法以及它們的適用范圍。答:實時數(shù)據(jù)倉庫在目前來說還不是很成熟,成功案例也比較少,下面列舉了一些實時數(shù)據(jù)倉庫架構(gòu)的實現(xiàn)方法。.EliONLY使用EII技術(shù)來代替實時的數(shù)據(jù)倉庫,數(shù)據(jù)延遲可以保證在1分鐘左右,支持數(shù)據(jù)整合的復雜程度較低。無法保存歷史數(shù)據(jù)。.EII+StaticDW會在一個sql里面加上where限定條件,但是如果員工表和部門表在兩個不同的數(shù)據(jù)流里面,尤其是數(shù)據(jù)源的來源是多個數(shù)據(jù)庫的情況,我們一般是要使用DatabaseJoin操作,然后用兩個databasetableinput來表示輸入流,一個輸入是部門表的姓名,另一個是員工表的姓名,然后我們認為這兩個表就可以"Join"了,我們需要的輸出的確是這兩個字段,但是這兩個字段的輸出并不代表只需要這兩個字段的輸入,它們之間肯定是需要一個約束關(guān)系存在的。另外,無論是在做Join,Merge,Update,Delete這些常規(guī)操作的時候,都是先需要做一個compare操作的,這個compare操作都是針對comparekey的,無論兩個表結(jié)構(gòu)是不是一樣的,比如employee表和department表,它們比較的依據(jù)就是employee的外鍵departmenjid,沒有這個comparekey這兩個表是不可能連接的起來的..對于兩個表可能還有人知道是直接sql來做連接,如果是多個輸入數(shù)據(jù)源,然后是三個表,有人就開始迷茫了,A表一個字段B表一個字段,C表一個字段然后就連Join操作都沒有直接databasetableoutput,然后開始報錯,報完錯就到處找高手問,他們的數(shù)據(jù)庫原理老師已經(jīng)在吐血了。如果是三個表連接,一個sql不能搞定,就需要先兩個表兩個表的連接,通過兩次comparekey連接之后得到你的輸出,記住,你的輸出并不能代表你的輸入.下面總結(jié)一下:.單數(shù)據(jù)源輸入,直接用sql做連接.多數(shù)據(jù)源輸入,(可能是文本或是兩個以上源數(shù)據(jù)庫),用databasejoin操作..三個表以上的多字段輸出.使用EH技術(shù)聯(lián)合非實時的數(shù)據(jù)倉庫,數(shù)據(jù)延遲可以保證在1分鐘左右,1天內(nèi)的數(shù)據(jù)整合的復雜程度較低,1天前的數(shù)據(jù)整合的復雜程度可以較高??梢员4鏆v史數(shù)據(jù)。.ETL+StaticDW普通的ETL處理,數(shù)據(jù)延遲在1天。支持復雜程度較高的數(shù)據(jù)整合。保存歷史數(shù)據(jù)。.CTF+Real-TimePartition+StaticDW使用CTF技術(shù)建立實時數(shù)據(jù)倉庫,數(shù)據(jù)延遲可保證在15分鐘左右。數(shù)據(jù)整合的復雜程度較低。保存歷史數(shù)據(jù)。.CTF+MB-ETL+Real-TimePartition+StaticDW使用CTF技術(shù)和MB-ETL聯(lián)合處理數(shù)據(jù)遷移,數(shù)據(jù)延遲可保證在1小時左右,支持數(shù)據(jù)整合的復雜程度較高,保存歷史數(shù)據(jù)。.MB-ETL+Real-TimePartition+StaticDW直接使用MB-ETL建立實時數(shù)據(jù)倉庫,數(shù)據(jù)延遲可保證在1小時左右,支持數(shù)據(jù)整合的復雜程度較高,保存歷史數(shù)據(jù)。.EAI+Real-TimePartition+StaticDW使用EAI技術(shù)建立實時數(shù)據(jù)倉庫,數(shù)據(jù)延遲可保證在1分鐘左右,支持數(shù)據(jù)整合的復雜程度較高。保存歷史數(shù)據(jù)。上面列出了一些實時數(shù)據(jù)倉庫架構(gòu)的選擇,寫的不是很詳細,只是提出個思路,供大家自己去找資料學習。30.Outlinesomechallengesfacedbyreal-timeETLanddescribehowtoovercomethem.簡述實時ETL的一些難點及其解決辦法。答:實時ETL的引入給數(shù)據(jù)倉庫的建設帶來了很多新的問題和挑戰(zhàn),下面列舉了一些問題,其中有些問題有具體的解決辦法,有些只能在實際情況下去斟酌。.連續(xù)的ETL處理對系統(tǒng)可靠性提出更高的要求。.離散快照數(shù)據(jù)的間隔時間變短。.緩慢變化維變成快速變化維。.如何確定數(shù)據(jù)倉庫中數(shù)據(jù)的刷新頻率。.目的是只出報表還是要實現(xiàn)數(shù)據(jù)整合。.做數(shù)據(jù)整合還是應用整合。.采用點對點的方式還是集中的方式。.前端展現(xiàn)工具的數(shù)據(jù)刷新方式如何確定。ETL測試方法論(ETL測試分層與持續(xù)集成)根據(jù)ETL各個階段的不同特點,可以將ETL測試分為:物理數(shù)據(jù)測試和邏輯數(shù)據(jù)測試。物理數(shù)據(jù)測試:是指純粹從技術(shù)上保證數(shù)據(jù)的有效性,與業(yè)務無關(guān)。邏輯數(shù)據(jù)測試:是從業(yè)務邏輯上,對原始指標以及最終產(chǎn)出的業(yè)務指標之間的邏輯平衡性監(jiān)控。通過這些監(jiān)控,能讓底層etl技術(shù)人員第一時間的發(fā)現(xiàn)數(shù)據(jù)問題并且解決問題,同時也能根據(jù)這些監(jiān)控提前知道可能產(chǎn)生的結(jié)果,為后續(xù)產(chǎn)生的業(yè)務分析報告作出進一步的修正,從而保證數(shù)據(jù)倉庫的數(shù)據(jù)的是有效的是能真正反應事實的。(引用adolph)在ETL測試過程中,根據(jù)實際情況可以將ETL的這些環(huán)節(jié)拆分或組合成多個測試面,根據(jù)不同的測試面進行不同重點的測試。前可以將試面,根據(jù)不同的測試面進行不同重點的測試。前可以將ETL環(huán)節(jié)拆分成以下4個測試面:源數(shù)據(jù)odl->adkidloadl■源數(shù)據(jù)〉adl測試面,其中源數(shù)據(jù)〉bdl側(cè)重物理數(shù)據(jù)測試,bdl->adl側(cè)重邏輯數(shù)據(jù)測試。1.各個測試面的關(guān)注點如下:1.第一面是源數(shù)據(jù)到。山的測試。主要關(guān)注以下幾個方面(側(cè)重物理數(shù)據(jù)測試):對ETL抽取方案的測試。首先是抽取方案穩(wěn)定性,如果源體系表結(jié)構(gòu)有改變,需要保證ETL抽取方案不變或者微變。其次數(shù)據(jù)傳送接口方案合理性。源系統(tǒng)以何種形式把數(shù)據(jù)提供給目標系統(tǒng),源系統(tǒng)推送或者目標系統(tǒng)主動抽取。數(shù)據(jù)日期,數(shù)據(jù)大小,記錄數(shù),增量or全量。對于抽取策略的測試。檢測抽取策略的合理性。前常用的抽取策略有全量抽取,增量抽取。對于增量檢測抽取策略的合理性。前常用的抽取策略有全量抽取,增量抽取。對于增量抽取,捕捉變化的數(shù)據(jù)有如下幾種:1)采用快照方式。需要業(yè)務系統(tǒng)建立insertfupdatefdelete觸發(fā)器。2)時間戳方式,在業(yè)務系統(tǒng)表建一個時間戳字段,一旦數(shù)據(jù)發(fā)生變化,則修改此字段。3)全表刪除插入方式,每次ETL操作先將目標表數(shù)據(jù)刪除,然后抽取。4)hash比對,是全表比對的一個擴展,通過計算主要業(yè)務字段的MD5校驗碼存入hash維表,通過與hash維表的比對進行抽取。5)日志表方式,跟進業(yè)務系統(tǒng)的日志表進行數(shù)據(jù)抽取。6)oracle變化數(shù)據(jù)捕捉,通過分析數(shù)據(jù)庫自身日志判斷變化的數(shù)據(jù)。對轉(zhuǎn)換規(guī)則的測試。首先是數(shù)據(jù)格式的合法性。對于數(shù)據(jù)源中時間.數(shù)值,字符等數(shù)據(jù)的處理,是否符合數(shù)據(jù)倉庫規(guī)則,是否進行統(tǒng)一的轉(zhuǎn)換。其次是值域的有效性。是否有超出維表或者業(yè)務值域的范圍。第三是空值的處理。是否捕獲字段空值,或者需要對空值進行替換為其他含義值的處理。第四是主鍵的有效性。主鍵是否唯一。第五是亂碼的檢查。特殊符號或者亂碼符號的護理規(guī)則。第六是臟數(shù)據(jù)的處理。比如不符合業(yè)務邏輯的數(shù)據(jù),數(shù)據(jù)孤島。加載策略的測試。首先是加載策略的合理性。前常用的加載策略有如下幾種:1)trunctaeandinsert.直接清空目標表,然后把新的數(shù)據(jù)加載進去。2)append.先根據(jù)規(guī)則清首先是加載策略的合理性。除當天的記錄,然后把當天的新數(shù)據(jù)追加進去。3)updateandinsert.用新數(shù)據(jù)與目標表中的歷史數(shù)據(jù)進行比較,有變化的則更新,新記錄則直接插入到目標表中。4)keephistorychange.保持歷史的變化,通常是拉鏈記歷史的方式實現(xiàn)。2.第二面是odl到adl的測試。主要關(guān)注以下幾個方面(物理數(shù)據(jù)測試+邏輯數(shù)據(jù)測試):對轉(zhuǎn)換規(guī)則的測試。2.首先是數(shù)據(jù)格式的合法性。對于數(shù)據(jù)源中時間,數(shù)值,字符等數(shù)據(jù)的處理,是否符合數(shù)據(jù)倉庫規(guī)則,是否進行統(tǒng)一的轉(zhuǎn)換。其次是值域的有效性。是否有超出維表或者業(yè)務值域的范圍。第三是空值的處理。是否捕獲字段空值,或者需要對空值進行替換為其他含義值的處理。第四是主鍵的有效性。主鍵是否唯一。第五是亂碼的檢直。特殊符號或者亂碼符號的護理規(guī)則。第六是臟數(shù)據(jù)的處理。比如不符合業(yè)務邏輯的數(shù)據(jù),數(shù)據(jù)孤島。對delta測試。Delta記錄的是變化的數(shù)據(jù),通過今天與昨天數(shù)據(jù)的比對找出變化的記錄。對拉鏈歷史測試。主要是檢查是否存在斷鏈的記錄,生命周期是否交叉。對數(shù)據(jù)趨勢測試。首先是數(shù)據(jù)趨勢要趨于平穩(wěn)-即波動是否有規(guī)律,且波動范圍在設定的閥值之

間。關(guān)于閥值的設定不同的業(yè)務指標有不同的標準。對業(yè)務邏輯測試。根據(jù)業(yè)務規(guī)則驗證業(yè)務正常流。指標口徑的一致性,如對于有效cookie的定義是否統(tǒng)一口徑。如從行業(yè)維度考察各個行業(yè)的上架產(chǎn)品數(shù),需要注意區(qū)分行業(yè)以及上架產(chǎn)品的概念。各行業(yè)的LPV,根據(jù)平臺的情況,各個行業(yè)的LPV大致的區(qū)間范圍。各行業(yè)的DPV,根據(jù)平臺的情況,各個行業(yè)的DPV大致的區(qū)間范圍。理論上LPV>DPVO根據(jù)業(yè)務規(guī)則驗證業(yè)務異常流。如上架產(chǎn)品數(shù)對于producjd的異常處理,考慮行業(yè)不存在的情況等等。程序編譯是否通過,是否支持重復調(diào)度以及滾。根據(jù)業(yè)務是否需要記歷史。程序編譯是否通過,是否支持重復調(diào)度以及滾。根據(jù)業(yè)務是否需要記歷史。驗證記錄平衡,從瀏覽明細表統(tǒng)計出的行業(yè)LPV,DPV根據(jù)業(yè)務是否平衡。唯一性,目標表中行業(yè)維度是否唯一,是否存在重復性記錄等等。3.第三面是idl到adl的測試。主要關(guān)注以下幾個方面(物理數(shù)據(jù)測試+邏輯數(shù)據(jù)測試):3.對業(yè)務邏輯測試。根據(jù)業(yè)務規(guī)則驗證業(yè)務正常流。指標口徑的一致性,如對于有效cookie的定義是否統(tǒng)一口徑。如從行業(yè)維度考察各個行業(yè)的上架產(chǎn)品數(shù),需要注意區(qū)分行業(yè)以及上架產(chǎn)品的概念。各行業(yè)的LPV,根據(jù)平臺的情況,各個行業(yè)的LPV大致的區(qū)間范圍。各行業(yè)的DPV,根據(jù)平臺的情況,各個行業(yè)的DPV大致的區(qū)間范圍。理論上LPV>DPVO根據(jù)業(yè)務規(guī)

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論