DM針對大數(shù)據(jù)量環(huán)境下分析型應(yīng)用的支持方案v2.0

–單服務(wù)器節(jié)點(diǎn)–操作庫和分析庫合并千兆交換機(jī)應(yīng)用服務(wù)器千兆交換機(jī)P550數(shù)據(jù)匯總數(shù)據(jù)清洗與入文本數(shù)據(jù)源Cpu數(shù)據(jù)匯總數(shù)據(jù)清洗與入文本數(shù)據(jù)源數(shù)據(jù)庫服務(wù)器文本數(shù)據(jù)源Mem數(shù)據(jù)庫服務(wù)器文本數(shù)據(jù)源4GB4GB光線通道Excel數(shù)據(jù)源文本數(shù)據(jù)源CpuExcel數(shù)據(jù)源文本數(shù)據(jù)源Mem32GBRAID5典型業(yè)務(wù)流程DTCC2011案例需求DTCC2011–第一個(gè)過濾步驟–大量的多表連接查詢?物理存儲(chǔ)設(shè)計(jì)有待優(yōu)化?不能充分利用多機(jī)資源提升性能于2009年開始新一代產(chǎn)品DM7的研制持續(xù)的技術(shù)積累持續(xù)的技術(shù)積累5.6引入物理操作符,虛擬機(jī)6.0引入高級特性和oracle兼容特性3 2實(shí)驗(yàn)室原型技術(shù)積累階段實(shí)現(xiàn)各類標(biāo)準(zhǔn)穩(wěn)定性及功能與開源系實(shí)驗(yàn)室原型技術(shù)積累階段實(shí)現(xiàn)各類標(biāo)準(zhǔn)穩(wěn)定性及功能與開源系統(tǒng)有差距1 5對DM4-DM6的技術(shù)總結(jié)持對于性能的理解DTCC2011數(shù)據(jù)控制權(quán)傳遞-批量技術(shù)DTCC2011-在數(shù)據(jù)泵一次傳送一批數(shù)據(jù)-減少控制轉(zhuǎn)移的CPU損耗；-有利于批量的表達(dá)式計(jì)算11111…12…N12…12…N12…N…………–將系統(tǒng)的初始數(shù)據(jù)入庫–原有BCP接口達(dá)到5000條/s，仍無法滿足要求?效率提升8倍息-Selectsum(2*c1),sum(3*(2*c1))fromt-v1=2*c1；-Selectsum(v1),sum(3*v1)fromt-一個(gè)復(fù)雜查詢在一條sql語句中使用多次的情況-將復(fù)雜查詢提取，并將結(jié)果緩存，多次使用{933查詢優(yōu)化：關(guān)系變換DTCC2011?考慮三個(gè)因素?A.確定的連接次序?B.確定的卡特蘭2叉樹形狀?C.是否下放過濾條件?采用臨時(shí)結(jié)果減少重復(fù)計(jì)算?代價(jià)模型基本覆蓋所有情況?對連接表的個(gè)數(shù)非常多的情況,特殊處理查詢優(yōu)化：統(tǒng)計(jì)信息DTCC20114050400039503900405040003950390038503800500500450400350300250200500400200238432300w_id=0w_id=1w_id=2w_id=3w_id=4w_id=5w_id=63950396040023888399040323980(0,1000](1000,1500](1500,1800](0,1000](1000,1500](1500,1800](1800,2000](2000,2100](2100,3000](3000,5000]?列存儲(chǔ):?支持垂直分區(qū)和水平分區(qū)?支持并行插入的物理數(shù)據(jù)存儲(chǔ)?并行備份和恢復(fù)?分區(qū)技術(shù)及相應(yīng)的并行查詢操作符號-某表T，31個(gè)字段，48億條記錄-隨機(jī)基于某字段篩選：SELECT*FROMTWHERE-查詢符合條件的結(jié)果集達(dá)到千萬條記錄-SQL語句非常簡單，沒有更優(yōu)的等效語句-結(jié)果集篩選條件不確定，無法使用索引-服務(wù)器內(nèi)存為32G，在掃描的過程中必然出現(xiàn)頁面淘汰-由于基礎(chǔ)數(shù)據(jù)量大，因此即使命中率不高（0.2%典型場景一：大結(jié)果集DTCC2011典型場景一：大結(jié)果集DTCC2011?返回結(jié)果集策略改進(jìn)-優(yōu)化前-優(yōu)化后-效果典型場景一：大結(jié)果集DTCC2011-數(shù)據(jù)頁（page）是數(shù)據(jù)讀寫的單位-優(yōu)化前的全表掃描：按頁讀取，每次IO只掃描-優(yōu)化后：一次掃描多個(gè)頁，減少IO數(shù)量-測試：經(jīng)過優(yōu)化后，磁盤的吞吐量提升1倍典型場景二：大表連接DTCC2011-表T1，31個(gè)字段，5000W條記錄，數(shù)據(jù)類型包括int、varchar、datetime、Dec；表T2,15個(gè)字段，500W條記錄，數(shù)據(jù)類型包括varchar、datetime、Dec；-SELECTT1.NAME,T2.TITLEFROMPERSON.PERSONT1,RESOURCES.EMPLOYEET2WHERET1.PERSONID=T2.PERSONIDANDT1.SEX='M';-連接查詢字段由最終用戶臨時(shí)指定，表上未建索引-結(jié)果集不大，但查詢表數(shù)據(jù)量大，連接查詢響應(yīng)時(shí)間陡增典型場景二：大表連接DTCC2011…………………典型場景二：大表連接DTCC2011?優(yōu)化方向：列存儲(chǔ)…?優(yōu)化方向：存儲(chǔ)壓縮-適用于列存儲(chǔ)模式的壓縮算法從17小時(shí)降至10分鐘以內(nèi)-表T,15個(gè)字段，500W條記錄，數(shù)據(jù)類型包括int、varchar、datetime、Dec-根據(jù)T進(jìn)行查詢建表：CREATETABLETTasSELECT*FROM-大表進(jìn)行查詢建表時(shí)，需經(jīng)過以下五個(gè)步驟集集-這個(gè)過程中可優(yōu)化的操作有：查詢與結(jié)果集的生成和大量數(shù)據(jù)的插入操作-避免結(jié)果集處理與數(shù)據(jù)插入-直接復(fù)制根節(jié)點(diǎn)和葉子是在-優(yōu)化前耗時(shí)約35S-優(yōu)化后耗時(shí)約4S，性能提升-針對500萬條記錄的表進(jìn)行如下查詢-SELECTIDnum,sub(6,8,IDnum)as生日,(now()-sub(6,8,IDnum))as年齡from…-一個(gè)表達(dá)式出現(xiàn)多次，只計(jì)算一次-本例中性能提升70%。其他場景性能提升程度取決于計(jì)算表達(dá)式的復(fù)雜度與數(shù)據(jù)量-同結(jié)構(gòu)的表T1~T10，每張表500萬條記錄，需要將10-應(yīng)用的并行化并沒有帶來較大的提升-分析-Ttmp成為瓶頸：原有的邏輯Rowid成為資源瓶頸-邏輯Rowid：不代表物理存儲(chǔ)位置，更新、插入、重組-原有產(chǎn)品針對OLTP業(yè)務(wù)場景，OLTP事務(wù)以分散、短-物理RowID：代表記錄的物理存儲(chǔ)位置-多個(gè)工作線程進(jìn)行插入操作，無需進(jìn)入臨界資源獲取rowid，每個(gè)工作線程自行生成RowID-實(shí)現(xiàn)真正意義上的并發(fā)插入應(yīng)用優(yōu)化DTCC2011-應(yīng)用架構(gòu)設(shè)計(jì)應(yīng)站在系統(tǒng)全局考慮性能問題-應(yīng)用與數(shù)據(jù)庫應(yīng)該取長補(bǔ)短-基于分區(qū)表進(jìn)行數(shù)據(jù)劃分-復(fù)雜事務(wù)分解為多個(gè)可并行的簡單事務(wù)應(yīng)用優(yōu)化-大表的全表掃描DTCC2011–優(yōu)化前：數(shù)據(jù)庫服務(wù)器CPU滿載而應(yīng)用服務(wù)器沒有–在最壞情況下，將需要掃描整個(gè)表–系統(tǒng)設(shè)計(jì)需要站在全局角度，充分考慮應(yīng)用、中間件、數(shù)據(jù)庫之間的負(fù)載分配–充分利用已有的硬件應(yīng)用優(yōu)化-大表的全表掃描DTCC2011?應(yīng)用依據(jù)分表更改查詢模塊，從單線程改為?在應(yīng)用服務(wù)器將各分表的查詢結(jié)果合并?按最壞情況測試，查詢時(shí)間由原來的不可預(yù)應(yīng)用優(yōu)化-數(shù)據(jù)清洗與入庫DTCC2011–基于JDBC驅(qū)動(dòng)的數(shù)據(jù)遷移工具進(jìn)行清洗和入庫–批量綁定–遷移工具的資源消耗隨著遷移時(shí)間的持續(xù)增加，導(dǎo)致遷移速度在運(yùn)行3天后急劇下降–初始數(shù)據(jù)（1T）入庫時(shí)間達(dá)到1個(gè)月，相當(dāng)于400條/s應(yīng)用優(yōu)化-數(shù)據(jù)清洗與入庫DTCC2011–超過100億條記錄，即使每5000條提交一次，也有2百萬次的解析-計(jì)劃-代價(jià)-執(zhí)行流程–大量的數(shù)據(jù)庫redo與undo日志操作–利用批量+BCP–利用并行化充分發(fā)揮多CPU處理能力，增加IO–JDBC方式轉(zhuǎn)變?yōu)镴NI+ODBC–實(shí)現(xiàn)動(dòng)態(tài)編譯型的ETL腳本引擎海量數(shù)據(jù)備份的難題DTCC2011–整庫備份操作耗時(shí)太長–需要靈活的針對整庫、文件組、表、分區(qū)的多種粒度備份手段–備份文件太大，消耗存儲(chǔ)空間嚴(yán)重–傳輸大尺寸備份文件，網(wǎng)絡(luò)傳輸成為瓶頸本案例中的備份需求DTCC2011根據(jù)數(shù)據(jù)量、變化頻度等確定不同的備份策略?