阿里大数据之路问道（一）
數(shù)據(jù)同步
數(shù)據(jù)同步技術(shù)更通用的含義是不同系統(tǒng)間的數(shù)據(jù)流轉(zhuǎn)，有多種不同的應(yīng)用場景。主數(shù)據(jù)庫與備份數(shù)據(jù)庫之間的備份，主系統(tǒng)與子系統(tǒng)之間的數(shù)據(jù)更新，同類型不同集群數(shù)據(jù)庫之間的數(shù)據(jù)同步。還有不同地域、不同數(shù)據(jù)庫類型之間的數(shù)據(jù)傳輸交換，比如分布式業(yè)務(wù)系統(tǒng)域數(shù)據(jù)倉庫系統(tǒng)之間的數(shù)據(jù)同步。數(shù)據(jù)同步的基礎(chǔ)
數(shù)據(jù)類型多種多樣，結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)。同步方式可以分為三種：直連同步、數(shù)據(jù)文件同步和數(shù)據(jù)庫日志解析同步-
直連同步
-
ODBC\JDBC
-
-
數(shù)據(jù)文件同步
-
基于FTP
-
-
數(shù)據(jù)庫日志解析同步
-
讀取歸檔日志文件收集變化的數(shù)據(jù)信息
-
阿里數(shù)據(jù)倉庫的同步方式
-
批量數(shù)據(jù)同步
-
DataX
-
每天處理2PB左右的批量轉(zhuǎn)換為對應(yīng)的數(shù)據(jù)格式寫入
-
Framework+Plugin
-
Job
-
Splitter
-
Sub-Job
-
Reader
-
Channel
-
Writer
-
-
-
-
實(shí)時(shí)數(shù)據(jù)同步
-
服務(wù)器集群由成千上萬臺(tái)機(jī)器，所產(chǎn)生的日志需要盡快的以數(shù)據(jù)流的方式不間斷地同步到數(shù)據(jù)倉庫。
-
對業(yè)務(wù)系統(tǒng)產(chǎn)生的實(shí)時(shí)數(shù)據(jù)處理，如雙十一實(shí)時(shí)大屏
-
TT(TimeTunnel)
-
實(shí)時(shí)數(shù)據(jù)傳輸平臺(tái)
-
高性能、實(shí)時(shí)性、順序性、高可靠性、高可用性、可擴(kuò)展性
-
一種基于生產(chǎn)者、消費(fèi)者、Topic消息標(biāo)識(shí)的消息中間件，將消息持久化到Hbase的高可用、分布式數(shù)據(jù)交互系統(tǒng)
-
生產(chǎn)者
-
消息數(shù)據(jù)的生產(chǎn)端
-
-
消費(fèi)者
-
消息數(shù)據(jù)的接收端
-
-
Topic
-
消息類型的標(biāo)識(shí)
-
-
Broker
-
負(fù)責(zé)處理客戶端收發(fā)消息數(shù)據(jù)的請求，然后往HBase取發(fā)數(shù)據(jù)
-
-
主動(dòng)、被動(dòng)等多種數(shù)據(jù)訂閱機(jī)制，訂閱端自動(dòng)負(fù)載均衡，消費(fèi)者自己把我消費(fèi)策略。對于讀寫比例很高的Topic，能夠做到讀寫分離，使消費(fèi)不影響發(fā)送。每天實(shí)時(shí)同步幾百TB
-
-
-
數(shù)據(jù)同步遇到的問題與解決方案
-
分庫分表的處理
-
TDDL
-
-
高效同步和批量同步
-
問題
-
業(yè)務(wù)的發(fā)展和變化，會(huì)新增大批量的數(shù)據(jù)同步，使用傳統(tǒng)方式每天去完成成百上千的數(shù)據(jù)同步工作
-
數(shù)據(jù)源種類豐富，不同類型需要開發(fā)人員了解其特殊配置
-
部分真正的數(shù)據(jù)需求方
-
-
解決方案
-
OneClick產(chǎn)品
-
對不同數(shù)據(jù)源的數(shù)據(jù)同步配置透明化
-
簡化數(shù)據(jù)同步的操作步驟
-
降低數(shù)據(jù)同步的技能門檻
-
-
-
實(shí)現(xiàn)
-
數(shù)據(jù)的一鍵化和批量化
-
一鍵完成DDL和DML的生成、數(shù)據(jù)的冒煙測試以及生產(chǎn)環(huán)境中測試等
-
-
-
增量和全量同步的合并
-
數(shù)據(jù)量過大
-
傳統(tǒng)合并技術(shù)
-
update+insert
-
-
現(xiàn)在比較推薦的方式
-
full outer join + 數(shù)據(jù)全量覆蓋重新加載
-
當(dāng)天的增量與前一天的全量數(shù)據(jù)做全外連接
-
-
-
-
-
同步性能的處理
-
問題
-
設(shè)置的線程數(shù)達(dá)不到要求
-
不懂如何設(shè)置線程數(shù)
-
不同的數(shù)據(jù)同步任務(wù)重要成都不一樣
-
-
負(fù)載均衡的解決方案
-
用戶創(chuàng)建數(shù)據(jù)同步任務(wù)
-
系統(tǒng)提前獲知及設(shè)定的數(shù)據(jù)，估算該任務(wù)需要同步的數(shù)據(jù)量、平均同步速度
-
根據(jù)需要同步的總線程數(shù)將待同步的數(shù)據(jù)拆分成相同數(shù)量的數(shù)據(jù)塊，一個(gè)現(xiàn)成處理一個(gè)數(shù)據(jù)塊，并將該任務(wù)對應(yīng)的所有現(xiàn)成提交至同步控制器
-
同步控制器判斷需要同步的總線程數(shù)是否大于首輪期望值
-
同步控制器采用多機(jī)多線程的數(shù)據(jù)同步模式，準(zhǔn)備該任務(wù)第一輪現(xiàn)成的跳讀，優(yōu)先發(fā)送優(yōu)先級高的
-
同步控制器準(zhǔn)備一定數(shù)據(jù)量的虛擬線程
-
任務(wù)開始同步
-
任務(wù)同步完成
-
-
-
數(shù)據(jù)漂移的處理
-
modified_time、log_time、proc_time、extract_time時(shí)間不統(tǒng)一
-
處理方法
-
多獲取后一天的數(shù)據(jù)
-
proc_time來限制
-
一個(gè)訂單是當(dāng)天支付的，但是第二天凌晨申請退款關(guān)閉了該訂單，那么下游在統(tǒng)計(jì)支付訂單狀態(tài)會(huì)出現(xiàn)錯(cuò)誤
-
-
通過多個(gè)時(shí)間戳字段限制時(shí)間來獲取相對準(zhǔn)確的數(shù)據(jù)
-
log_time分別冗余前一天最后15分鐘和后一天凌晨開始15分鐘 數(shù)據(jù)，并用modified_time過濾非當(dāng)天數(shù)據(jù)，確保數(shù)據(jù)不會(huì)因?yàn)橄到y(tǒng)問題而遺漏
-
根據(jù)log_time獲取后一天15分鐘的數(shù)據(jù)；針對此數(shù)據(jù)，按照主鍵根據(jù)log_time做升序排列去重
-
全外連接拼接
-
-
-
-
總結(jié)
以上是生活随笔為你收集整理的阿里大数据之路问道（一）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： cesium去除版权信息
- 下一篇： 《棒球殿堂》：棒球联盟LEAGUE·欧力