色哟哟视频在线观看-色哟哟视频在线-色哟哟欧美15最新在线-色哟哟免费在线观看-国产l精品国产亚洲区在线观看-国产l精品国产亚洲区久久

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

如何實現DB數據準確、高效地進入數倉

電子工程師 ? 來源:lq ? 2018-12-12 13:50 ? 次閱讀

背景

在數據倉庫建模中,未經任何加工處理的原始業務層數據,我們稱之為ODS(Operational Data Store)數據。在互聯網企業中,常見的ODS數據有業務日志數據(Log)和業務DB數據(DB)兩類。對于業務DB數據來說,從MySQL等關系型數據庫的業務數據進行采集,然后導入到Hive中,是進行數據倉庫生產的重要環節。

如何準確、高效地把MySQL數據同步到Hive中?一般常用的解決方案是批量取數并Load:直連MySQL去Select表中的數據,然后存到本地文件作為中間存儲,最后把文件Load到Hive表中。這種方案的優點是實現簡單,但是隨著業務的發展,缺點也逐漸暴露出來:

性能瓶頸:隨著業務規模的增長,Select From MySQL -> Save to Localfile -> Load to Hive這種數據流花費的時間越來越長,無法滿足下游數倉生產的時間要求。

直接從MySQL中Select大量數據,對MySQL的影響非常大,容易造成慢查詢,影響業務線上的正常服務。

由于Hive本身的語法不支持更新、刪除等SQL原語,對于MySQL中發生Update/Delete的數據無法很好地進行支持。

為了徹底解決這些問題,我們逐步轉向CDC(Change Data Capture)+ Merge的技術方案,即實時Binlog采集 + 離線處理Binlog還原業務數據這樣一套解決方案。Binlog是MySQL的二進制日志,記錄了MySQL中發生的所有數據變更,MySQL集群自身的主從同步就是基于Binlog做的。

本文主要從Binlog實時采集和離線處理Binlog還原業務數據兩個方面,來介紹如何實現DB數據準確、高效地進入數倉。

整體架構

整體的架構如上圖所示。在Binlog實時采集方面,我們采用了阿里巴巴的開源項目Canal,負責從MySQL實時拉取Binlog并完成適當解析。Binlog采集后會暫存到Kafka上供下游消費。整體實時采集部分如圖中紅色箭頭所示。

離線處理Binlog的部分,如圖中黑色箭頭所示,通過下面的步驟在Hive上還原一張MySQL表:

采用Linkedin的開源項目Camus,負責每小時把Kafka上的Binlog數據拉取到Hive上。

對每張ODS表,首先需要一次性制作快照(Snapshot),把MySQL里的存量數據讀取到Hive上,這一過程底層采用直連MySQL去Select數據的方式。

對每張ODS表,每天基于存量數據和當天增量產生的Binlog做Merge,從而還原出業務數據。

我們回過頭來看看,背景中介紹的批量取數并Load方案遇到的各種問題,為什么用這種方案能解決上面的問題呢?

首先,Binlog是流式產生的,通過對Binlog的實時采集,把部分數據處理需求由每天一次的批處理分攤到實時流上。無論從性能上還是對MySQL的訪問壓力上,都會有明顯地改善。

第二,Binlog本身記錄了數據變更的類型(Insert/Update/Delete),通過一些語義方面的處理,完全能夠做到精準的數據還原。

Binlog實時采集

對Binlog的實時采集包含兩個主要模塊:一是CanalManager,主要負責采集任務的分配、監控報警、元數據管理以及和外部依賴系統的對接;二是真正執行采集任務的Canal和CanalClient。

當用戶提交某個DB的Binlog采集請求時,CanalManager首先會調用DBA平臺的相關接口,獲取這一DB所在MySQL實例的相關信息,目的是從中選出最適合Binlog采集的機器。然后把采集實例(Canal Instance)分發到合適的Canal服務器上,即CanalServer上。在選擇具體的CanalServer時,CanalManager會考慮負載均衡、跨機房傳輸等因素,優先選擇負載較低且同地域傳輸的機器。

CanalServer收到采集請求后,會在ZooKeeper上對收集信息進行注冊。注冊的內容包括:

以Instance名稱命名的永久節點。

在該永久節點下注冊以自身ip:port命名的臨時節點。

這樣做的目的有兩個:

高可用:CanalManager對Instance進行分發時,會選擇兩臺CanalServer,一臺是Running節點,另一臺作為Standby節點。Standby節點會對該Instance進行監聽,當Running節點出現故障后,臨時節點消失,然后Standby節點進行搶占。這樣就達到了容災的目的。

與CanalClient交互:CanalClient檢測到自己負責的Instance所在的Running CanalServer后,便會進行連接,從而接收到CanalServer發來的Binlog數據。

對Binlog的訂閱以MySQL的DB為粒度,一個DB的Binlog對應了一個Kafka Topic。底層實現時,一個MySQL實例下所有訂閱的DB,都由同一個Canal Instance進行處理。這是因為Binlog的產生是以MySQL實例為粒度的。CanalServer會拋棄掉未訂閱的Binlog數據,然后CanalClient將接收到的Binlog按DB粒度分發到Kafka上。

離線還原MySQL數據

完成Binlog采集后,下一步就是利用Binlog來還原業務數據。首先要解決的第一個問題是把Binlog從Kafka同步到Hive上。

Kafka2Hive

整個Kafka2Hive任務的管理,在美團數據平臺的ETL框架下進行,包括任務原語的表達和調度機制等,都同其他ETL類似。而底層采用LinkedIn的開源項目Camus,并進行了有針對性的二次開發,來完成真正的Kafka2Hive數據傳輸工作。

對Camus的二次開發

Kafka上存儲的Binlog未帶Schema,而Hive表必須有Schema,并且其分區、字段等的設計,都要便于下游的高效消費。對Camus做的第一個改造,便是將Kafka上的Binlog解析成符合目標Schema的格式。

對Camus做的第二個改造,由美團的ETL框架所決定。在我們的任務調度系統中,目前只對同調度隊列的任務做上下游依賴關系的解析,跨調度隊列是不能建立依賴關系的。而在MySQL2Hive的整個流程中,Kafka2Hive的任務需要每小時執行一次(小時隊列),Merge任務每天執行一次(天隊列)。而Merge任務的啟動必須要嚴格依賴小時Kafka2Hive任務的完成。

為了解決這一問題,我們引入了Checkdone任務。Checkdone任務是天任務,主要負責檢測前一天的Kafka2Hive是否成功完成。如果成功完成了,則Checkdone任務執行成功,這樣下游的Merge任務就可以正確啟動了。

Checkdone的檢測邏輯

Checkdone是怎樣檢測的呢?每個Kafka2Hive任務成功完成數據傳輸后,由Camus負責在相應的HDFS目錄下記錄該任務的啟動時間。Checkdone會掃描前一天的所有時間戳,如果最大的時間戳已經超過了0點,就說明前一天的Kafka2Hive任務都成功完成了,這樣Checkdone就完成了檢測。

此外,由于Camus本身只是完成了讀Kafka然后寫HDFS文件的過程,還必須完成對Hive分區的加載才能使下游查詢到。因此,整個Kafka2Hive任務的最后一步是加載Hive分區。這樣,整個任務才算成功執行。

每個Kafka2Hive任務負責讀取一個特定的Topic,把Binlog數據寫入original_binlog庫下的一張表中,即前面圖中的original_binlog.db,其中存儲的是對應到一個MySQL DB的全部Binlog。

上圖說明了一個Kafka2Hive完成后,文件在HDFS上的目錄結構。假如一個MySQL DB叫做user,對應的Binlog存儲在original_binlog.user表中。ready目錄中,按天存儲了當天所有成功執行的Kafka2Hive任務的啟動時間,供Checkdone使用。每張表的Binlog,被組織到一個分區中,例如userinfo表的Binlog,存儲在table_name=userinfo這一分區中。每個table_name一級分區下,按dt組織二級分區。圖中的xxx.lzo和xxx.lzo.index文件,存儲的是經過lzo壓縮的Binlog數據。

Merge

Binlog成功入倉后,下一步要做的就是基于Binlog對MySQL數據進行還原。Merge流程做了兩件事,首先把當天生成的Binlog數據存放到Delta表中,然后和已有的存量數據做一個基于主鍵的Merge。Delta表中的數據是當天的最新數據,當一條數據在一天內發生多次變更時,Delta表中只存儲最后一次變更后的數據。

把Delta數據和存量數據進行Merge的過程中,需要有唯一鍵來判定是否是同一條數據。如果同一條數據既出現在存量表中,又出現在Delta表中,說明這一條數據發生了更新,則選取Delta表的數據作為最終結果;否則說明沒有發生任何變動,保留原來存量表中的數據作為最終結果。Merge的結果數據會Insert Overwrite到原表中,即圖中的origindb.table。

Merge流程舉例

下面用一個例子來具體說明Merge的流程。

數據表共id、value兩列,其中id是主鍵。在提取Delta數據時,對同一條數據的多次更新,只選擇最后更新的一條。所以對id=1的數據,Delta表中記錄最后一條更新后的值value=120。Delta數據和存量數據做Merge后,最終結果中,新插入一條數據(id=4),兩條數據發生了更新(id=1和id=2),一條數據未變(id=3)。

默認情況下,我們采用MySQL表的主鍵作為這一判重的唯一鍵,業務也可以根據實際情況配置不同于MySQL的唯一鍵。

上面介紹了基于Binlog的數據采集和ODS數據還原的整體架構。下面主要從兩個方面介紹我們解決的實際業務問題。

實踐一:分庫分表的支持

隨著業務規模的擴大,MySQL的分庫分表情況越來越多,很多業務的分表數目都在幾千個這樣的量級。而一般數據開發同學需要把這些數據聚合到一起進行分析。如果對每個分表都進行手動同步,再在Hive上進行聚合,這個成本很難被我們接受。因此,我們需要在ODS層就完成分表的聚合。

首先,在Binlog實時采集時,我們支持把不同DB的Binlog寫入到同一個Kafka Topic。用戶可以在申請Binlog采集時,同時勾選同一個業務邏輯下的多個物理DB。通過在Binlog采集層的匯集,所有分庫的Binlog會寫入到同一張Hive表中,這樣下游在進行Merge時,依然只需要讀取一張Hive表。

第二,Merge任務的配置支持正則匹配。通過配置符合業務分表命名規則的正則表達式,Merge任務就能了解自己需要聚合哪些MySQL表的Binlog,從而選取相應分區的數據來執行。

這樣通過兩個層面的工作,就完成了分庫分表在ODS層的合并。

這里面有一個技術上的優化,在進行Kafka2Hive時,我們按業務分表規則對表名進行了處理,把物理表名轉換成了邏輯表名。例如userinfo123這張表名會被轉換為userinfo,其Binlog數據存儲在original_binlog.user表的table_name=userinfo分區中。這樣做的目的是防止過多的HDFS小文件和Hive分區造成的底層壓力。

實踐二:刪除事件的支持

Delete操作在MySQL中非常常見,由于Hive不支持Delete,如果想把MySQL中刪除的數據在Hive中刪掉,需要采用“迂回”的方式進行。

對需要處理Delete事件的Merge流程,采用如下兩個步驟:

首先,提取出發生了Delete事件的數據,由于Binlog本身記錄了事件類型,這一步很容易做到。將存量數據(表A)與被刪掉的數據(表B)在主鍵上做左外連接(Left outer join),如果能夠全部join到雙方的數據,說明該條數據被刪掉了。因此,選擇結果中表B對應的記錄為NULL的數據,即是應當被保留的數據。

然后,對上面得到的被保留下來的數據,按照前面描述的流程做常規的Merge。

總結與展望

作為數據倉庫生產的基礎,美團數據平臺提供的基于Binlog的MySQL2Hive服務,基本覆蓋了美團內部的各個業務線,目前已經能夠滿足絕大部分業務的數據同步需求,實現DB數據準確、高效地入倉。在后面的發展中,我們會集中解決CanalManager的單點問題,并構建跨機房容災的架構,從而更加穩定地支撐業務的發展。

本文主要從Binlog流式采集和基于Binlog的ODS數據還原兩方面,介紹了這一服務的架構,并介紹了我們在實踐中遇到的一些典型問題和解決方案。希望能夠給其他開發者一些參考價值,同時也歡迎大家和我們一起交流。

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • 二進制
    +關注

    關注

    2

    文章

    795

    瀏覽量

    41719
  • MySQL
    +關注

    關注

    1

    文章

    826

    瀏覽量

    26665

原文標題:美團 DB 數據同步到數據倉庫的架構與實踐

文章出處:【微信號:DBDevs,微信公眾號:數據分析與開發】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    低成本高通道數據采集系統怎么實現

    “通過高效利用SCXI模塊,讓我們可以只使用一個DAQ板卡就建立起一個極具成本效益的高通道數據采集系統。”
    發表于 08-22 06:30

    請問精確的數據采集如何準確實現

    精確的數據采集如何準確實現
    發表于 05-08 08:46

    英集芯IP5513耳機管理

    ,可靈活配置最大充電電流。內置 IC 溫度和輸入電壓智能調節充電電流功能。 IP5513 可實現 TWS 對耳獨立入倉檢測,檢測到耳機入倉后自動進入耳機充電模式,耳機充滿后自動進入休眠狀態,靜態電流
    發表于 01-12 18:20

    什么是DB和dBm,DB和dBm是什么

    什么是DB和dBm,DB和dBm是什么 dB,dBm 意義其實再簡單不過了,就是把一個很大(后面跟一長串0的)或者很小(前面有一長串0的)的比較簡短地表示
    發表于 03-06 14:36 ?9835次閱讀

    基于AS39513的智能標簽實現對食品、藥品儲存及運輸更高效準確的監控

    ams推出一款NFC傳感器標簽和數據記錄儀集成電路AS39513,可應用于智能標簽中,實現對食品、藥品和醫療保健品儲存和運輸過程中的狀況進行更高效準確的監控。
    的頭像 發表于 12-27 16:48 ?7577次閱讀

    倉庫管理難題多,雷系統幫你解決

    倉庫管理難題多怎么辦?雷系統幫你一一解決。系統如何逐一攻破,且往下看: 難題一:找貨時間長。找貨時間長是最困擾揀貨員的問題,因為耗時長短不僅影響訂單的交付,還與他們的個人工作績效掛鉤,影響月終
    發表于 05-11 15:00 ?518次閱讀

    極智嘉華東三大旗艦簡介

    、B2C物流業務提供配一體化服務,助力品牌揀選效率提升2-3倍,揀選準確率超99.99%,庫存準確率超99.995%。目前RaaS智能已賦能聯恩、完美日記、麗人麗妝、樂友、tape
    的頭像 發表于 03-12 11:39 ?2546次閱讀

    離線和實時數的區別

    1998年,Bill Inmon提出了新的BI架構CIF(Corporation information factory),CIF的核心是將架構劃分為不同的層次以滿足不同場景的需求,比如常見的ODS、DW、DM等,每層根據實際場景采用不同的建設方案,現在CIF已經成為
    的頭像 發表于 03-22 10:27 ?2125次閱讀

    Cubus智能概念

    這個Cubus智能系統,包含外形緊湊,分布在車間的小型智能,方便操作員備料。同時,這些智能以閉環方式,與整個工廠的大型庫存連接,實現
    的頭像 發表于 04-18 11:22 ?1607次閱讀

    數據也能“海納百川”,華為DWS智能云是這樣做到的

    如此之高,更何況是企業,更加需要拓展儲存空間,畢竟企業在不斷的業務發展之中數據也只增不減。華為DWS智能云就能急企業之所急,憂企業之所憂,全面而詳細的解決企業的煩惱。 數字化轉型時代的來臨,各行各業的平臺
    的頭像 發表于 10-18 14:16 ?609次閱讀

    美國巨頭退出中國 國產新一代分布式數據庫開啟達夢新紀元

    武漢2023年3月2日 /美通社/ -- 近日,大數據分析、軟件巨頭美國天睿公司宣布將退出在中國的直接運營,后續將進入中國公司關閉程序。 前些年,天睿公司作為全球大
    的頭像 發表于 03-02 20:57 ?486次閱讀

    智領睿變,共建綠色智金融 -- 華為云3.0發布

    。華為云GaussDB(DWS)作為新一代全場景云數據倉庫,提供批量、實時數以及IoT
    的頭像 發表于 06-08 21:58 ?550次閱讀
    智領睿變,共建綠色<b class='flag-5'>數</b>智金融 -- 華為云<b class='flag-5'>數</b><b class='flag-5'>倉</b>3.0發布

    基于之能工業數據云平臺實現數據監控與智能管理

    在當今這個數字化時代,工業數據云平臺的出現無疑為各行各業帶來全新的工作體驗。它將工業生產中的各種數據進行了整合,實現數據監控與智能管理,為企業帶來了決策升級的動力。對此,
    的頭像 發表于 01-10 16:03 ?315次閱讀

    振弦采集儀:高效準確,助力工程監測

    工程監測工作更加精確和有效。 振弦采集儀:高效準確,助力工程監測 首先,振弦采集儀可以實時采集振弦信號,并將其轉換為數字信號進行處理。這種數字信號處理的方式可以大大降低測量誤差,提高數據準確
    的頭像 發表于 02-21 13:46 ?419次閱讀
    振弦采集儀:<b class='flag-5'>高效</b><b class='flag-5'>準確</b>,助力工程監測

    電科金智未來,國產數據庫大有可為

    幾十年來積累的技術底蘊,加之在眾多行業中的實踐驗證與落地,為金數據庫的持續發展奠定了堅實的基礎。同時,金還以其專業的服務體系、完善的生態構建以及對人才發展的不懈追求,構筑起了一道堅實的競爭壁壘。金
    的頭像 發表于 09-03 13:58 ?289次閱讀
    電科金<b class='flag-5'>倉</b>:<b class='flag-5'>數</b>智未來,國產<b class='flag-5'>數據</b>庫大有可為
    主站蜘蛛池模板: 99视频精品国产在线视频| 午夜免费福利片| 欧美乱码伦视频免费66网| 十九禁啊啪射视频在线观看| 一本大道熟女人妻中文字幕在线| 97资源站超碰在线视频| 国产精人妻无码一区麻豆 | 韩国无遮羞禁动漫在线观看 | 插曲的痛30分钟视频最新章节| 果冻传媒2021一二三在线观看| 热九九99香蕉精品品| 伊人国产在线播放| 国产精品永久免费| 日本乱子伦一区二区三区| 中文字幕福利视频在线一区| 国产色精品VR一区二区| 日日噜噜夜夜躁躁狠狠| 99C视频色欲在线| 久久aa毛片免费播放嗯啊| 午夜久久影院| 丰满少妇被猛烈进出69影院| 浓毛BWBWBWBWBW日本| 伊人第一路线| 九九热精品免费观看| 小sao货ji巴cao死你视频| 动漫美女被吸奶| 日韩精品无码免费专区| 99久久精品免费看国产免费| 久久棋牌评测| 亚洲熟伦熟女专区| 国产自啪偷啪视频在线| 午夜DV内射一区区| 干极品美女| 欧美日韩888在线观看| 99C视频色欲在线| 蜜芽一区二区国产精品| 中文字幕视频在线观看| 快播性爱电影| 97精品国产高清在线看入口| 老板揉搓秘书丰满大乳| 综合久久久久久久综合网|