開始之前，先聊下企業(yè)數(shù)據(jù)的整體架構(gòu)吧屡立。一般來說，業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫有較大的生產(chǎn)壓力搀军，大多數(shù)的做法是在企業(yè)生產(chǎn)庫后會追加1到2個(gè)只讀庫膨俐，負(fù)責(zé)實(shí)時(shí)同步主庫數(shù)據(jù)。業(yè)務(wù)系統(tǒng)寫入到只讀庫罩句，查詢數(shù)據(jù)從從庫焚刺。同時(shí)為了減輕成本壓力，從庫不提供binlog日志能力门烂。
阿里巴巴的Dataworks作為一站式數(shù)據(jù)開發(fā)和數(shù)據(jù)治理的PASS平臺乳愉，提供多樣的數(shù)據(jù)集成能力，甚至提供了數(shù)據(jù)集成的解決方案屯远。為完成數(shù)倉的ODS層的建設(shè)蔓姚，存在離線全量ETL、離線增量+離線全量的ETL慨丐、實(shí)時(shí)增量+離線全量ETL坡脐、實(shí)時(shí)增量ETL4種方式。這里我們從技術(shù)上進(jìn)行簡單拆解房揭，最終選擇一個(gè)較為合適的方案挨措，為簡化起見我們的源端是RDS，即mysql數(shù)據(jù)庫崩溪。
離線全量ETL：即使用Dataworks離線集成方式浅役，配置源端mysql通過每日將全量數(shù)據(jù)抽取，并重寫到ODS表伶唯，這種方式也叫"直連"方式觉既。通過直連源端(一般都會選擇從庫-.-，沒有從庫的話請運(yùn)維同事構(gòu)建吧乳幸，主庫拉掛了就可以祭天了)的方式瞪讼，對于一般小表來說(即整體看該表整體數(shù)據(jù)量比較固定，日增量較少粹断，如組織架構(gòu)表)這種方式是可行的符欠，且操作簡單。遺憾的是：每日固定時(shí)間拉取的表數(shù)據(jù)瓶埋，嚴(yán)格來說并不是某一個(gè)時(shí)間點(diǎn)的實(shí)際真是快照希柿。如定時(shí)每天00:00:00同步數(shù)據(jù)诊沪，但實(shí)際任務(wù)調(diào)度時(shí)會因調(diào)度資源爭奪等原因造成數(shù)據(jù)同步延遲(0點(diǎn)存在大量數(shù)據(jù)同步任務(wù))，實(shí)際落地到ODS的數(shù)據(jù)并非是00:00:00的快照曾撤。同時(shí)由于ODS數(shù)據(jù)同步的延遲端姚，導(dǎo)致下游任務(wù)會停滯一段時(shí)間，數(shù)據(jù)的計(jì)算結(jié)果也會延遲一定時(shí)間挤悉，使用該方式之前需要從業(yè)務(wù)角度綜合分析渐裸。對于大表來說，該方式有點(diǎn)慢性自殺的感覺装悲，數(shù)據(jù)同步慢昏鹃，下游計(jì)算延遲，拉掛了只讀庫會不會祭天我不知道诀诊，我只知道工作還得做洞渤，數(shù)據(jù)計(jì)算還得補(bǔ)回來，怎么解決呢畏梆？可以試試使用“離線增量+全量的ETL”的方式您宪。
離線增量+離線全量的ETL:在特定情況下，如解析FTP文件日志奠涌、TableStore增量日志時(shí)該方案是最佳方案宪巨，也可以處理關(guān)系型數(shù)據(jù)庫RDS的場景，如對大表(如訂單表溜畅，每天增量100w+)可以考慮首次進(jìn)行數(shù)據(jù)的全量同步到MaxCompute里的全量表table_full捏卓，后續(xù)接入每日增量的數(shù)據(jù)同步到MaxCompute的增量表table_inc,在MaxCompute里完成數(shù)據(jù)合并并重寫到table_full的最新分區(qū)里。具體實(shí)踐：源端Mysql定義modify_time慈格，數(shù)據(jù)每次修改會插入時(shí)都會更新該字段怠晴。定時(shí)抽取源端數(shù)據(jù)時(shí)增加過濾條件modify_time>start_time? and modify_time<end_time將ETL的數(shù)據(jù)寫入ODS增量表的分區(qū)里，再與ODS全量表最新分區(qū)數(shù)據(jù)進(jìn)行合并浴捆，并重新寫入到一個(gè)新的分區(qū)數(shù)據(jù)里蒜田。遺憾的是：該方式對于源庫來說相當(dāng)于每次掃描一次全表（可以使用索引優(yōu)化）對源庫也存在一定的性能壓力。源端進(jìn)行了歷史數(shù)據(jù)的物理刪除的話选泻，數(shù)據(jù)合并時(shí)無法感知冲粤，因此需要先與業(yè)務(wù)應(yīng)用系統(tǒng)確定數(shù)據(jù)是否存在物理刪除場景。怎么解決呢页眯？可以試試使用"實(shí)時(shí)增量+離線全量ETL"的方式梯捕。
實(shí)時(shí)增量+離線全量ETL:工作原理與上述相同。唯一不同的是通過Mysql-binlog日志的方式實(shí)時(shí)寫入窝撵，通過解析binlog日志里的日志時(shí)間戳傀顾，將該時(shí)間戳轉(zhuǎn)為maxcompute增量表的分區(qū)字段，并根據(jù)日志的變更類型(新增碌奉、修改短曾、刪除)寒砖、日志順序(record_id)與全量表進(jìn)行數(shù)據(jù)合并。該方案的解決了離線全量ETL中數(shù)據(jù)快照不精確的問題错英，并可以感知到源端數(shù)據(jù)庫物理刪除數(shù)據(jù)的場景入撒，可以說是相當(dāng)完美的方案了隆豹，這也是我實(shí)踐的方案椭岩，后續(xù)整體會圍繞該方案細(xì)說。然而該方案對數(shù)據(jù)開發(fā)人員的技術(shù)要求較高璃赡。?如何采集binlog日志判哥，如何進(jìn)行數(shù)據(jù)合并，阿里Dataworks已有了解決方案碉考，下一章我將會細(xì)說這塊"數(shù)據(jù)集成之實(shí)時(shí)增量+離線全量ETL詳解"塌计。
實(shí)時(shí)增量ETL：嚴(yán)格上來說，該方案是上個(gè)方案的子集侯谁，單拎出來主要基于業(yè)務(wù)考慮锌仅。數(shù)據(jù)計(jì)算場景需要獲取源端完整數(shù)據(jù)的場景請使用上個(gè)方案。部分場景可能只需要關(guān)心當(dāng)前增量的數(shù)據(jù)墙贱，不關(guān)心歷史數(shù)據(jù)的只需要進(jìn)行實(shí)時(shí)增量ETL热芹。數(shù)據(jù)源也會多樣化如mysql-binlog、rockmq等等惨撇。數(shù)據(jù)的老化策略也會不同伊脓。這塊后期文章里會詳細(xì)說明。
喜歡的朋友請幫忙點(diǎn)贊魁衙，謝謝大家报腔！
