《拍攝紙牌屋的Netflix為何要遷移數(shù)據(jù)庫入云？》要點：
本文介紹了拍攝紙牌屋的Netflix為何要遷移數(shù)據(jù)庫入云？，希望對您有用。如果有疑問，可以聯(lián)系我們。

對任何公司來說賬務(wù)都是一種關(guān)鍵服務(wù),這一點大部分人都不會否認.在任何遷移項目中,數(shù)據(jù)庫的遷移都是最基本要素,數(shù)據(jù)庫能否成功遷移直接決定了整個項目能否成功.

Netflix CDE(云數(shù)據(jù)庫工程)團隊最近對這一最重要的數(shù)據(jù)庫子系統(tǒng)進行了遷移.本次項目的目標在于將所有這一切都搬入云中,不在數(shù)據(jù)中心內(nèi)運行任何計費應(yīng)用程序或數(shù)據(jù)庫,但所有操作不能影響業(yè)務(wù)的正常運轉(zhuǎn).我們的前路十分艱巨!

前言

毫無疑問,在不中斷業(yè)務(wù)的情況下遷移高度敏感的應(yīng)用程序和重要數(shù)據(jù)庫是一項意義深遠的工作,與此同時我們還將繼續(xù)構(gòu)建新的業(yè)務(wù)功能和服務(wù).

計費系統(tǒng)的一些重要用途和面臨的挑戰(zhàn)包括：

• 計費團隊負責(zé)管理整個公司的重要財務(wù)數(shù)據(jù).我們每天會通過用戶的付費訂閱、禮品卡、信用額度、退款等行為生成大量數(shù)據(jù),這些數(shù)據(jù)將匯總至財務(wù)部門并創(chuàng)建成報表交給公司會計.為確保每天的收入情況可以準確記錄,我們在日常處理流程中實施了嚴格的SLA.處理管線的任何延遲都是無法接受的.

• 計費系統(tǒng)對數(shù)據(jù)丟失持零容忍態(tài)度.

• 大部分情況下,現(xiàn)有數(shù)據(jù)使用了一種關(guān)系型模式的結(jié)構(gòu),因此需要通過事務(wù)確保這類數(shù)據(jù)實現(xiàn)“全有或全無(all-or-nothing)”的行為.換句話說,我們的運維必須符合ACID(原子性、一致性、隔離性、持久性)要求.但某些情況下還必須讓這些數(shù)據(jù)實現(xiàn)跨區(qū)域高可用,同時確保不同區(qū)域間復(fù)制的延遲最小化.

• 計費系統(tǒng)與公司的DVD業(yè)務(wù)相集成,而DVD業(yè)務(wù)與在線流播業(yè)務(wù)使用了截然不同的體系結(jié)構(gòu),這也大幅增加了集成工作的復(fù)雜度.
• 支付團隊還希望向Netflix客戶服務(wù)代理提供數(shù)據(jù)支持,幫助他們回答會員提出的有關(guān)計費操作的問題.因此迫切需要向客戶支持人員提供此類數(shù)據(jù)的概括性視圖.

當我們著手進行該項目時,計費系統(tǒng)是這樣的：

• 數(shù)據(jù)中心內(nèi)部署2個Oracle數(shù)據(jù)庫 – 一個存儲客戶訂閱信息,另一個存儲發(fā)票/支付數(shù)據(jù).

• 多個基于REST的應(yīng)用程序 – 為www.netflix.com和客戶支持應(yīng)用程序的調(diào)用提供服務(wù).這些應(yīng)用程序主要執(zhí)行CRUD(創(chuàng)建、讀取、更新、刪除)操作.

• 3個批處理應(yīng)用程序：

• 服務(wù)續(xù)訂 – 這個每天運行一次的作業(yè)會掃描所有客戶信息以確定當天需要計費的客戶,并通過這些客戶的訂閱計劃、折扣等信息確定需要計費的金額.
• 訂單和支付處理 – 通過一系列批處理作業(yè)為需要續(xù)訂的客戶創(chuàng)建發(fā)票,并負責(zé)在發(fā)票生命周期內(nèi)的不同階段處理有關(guān)發(fā)票的任務(wù).
• 營收報表 – 這個每天運行一次的作業(yè)會檢索計費數(shù)據(jù)并生成Netflix財務(wù)部門需要的報表.

• 一個計費代理應(yīng)用程序(位于云中) – 用于將Netflix在云中的其他應(yīng)用程序的調(diào)用路由至數(shù)據(jù)中心.
• 使用老版本格式的Weblogic隊列負責(zé)不同過程之間的通信.

規(guī)劃

我們制訂了一個三步規(guī)劃：

• 第1步 – 服務(wù)新落地國家的計費系統(tǒng)直接從云中運行,并將所產(chǎn)生的數(shù)據(jù)同步回數(shù)據(jù)中心,供原有批處理應(yīng)用程序繼續(xù)使用.

• 第2步 – 對面向用戶的數(shù)據(jù)進行建模,以實現(xiàn)最終一致性并且不再需要符合ACID特性,將這些數(shù)據(jù)持久保存在Cassandra(Cassandra使得我們能夠在一個區(qū)域執(zhí)行寫操作,并用非常低的延遲讓寫入的數(shù)據(jù)可在所有區(qū)域使用.同時還可以幫助我們實現(xiàn)跨區(qū)域高可用性).
• 第3步 – 最終將SQL數(shù)據(jù)庫遷移至云中.

從每個國家遷移過程的每一步操作中學(xué)習(xí)經(jīng)驗,進行迭代和完善,確保后續(xù)工作能取得更好的成績.

第1步 – 將新落地國家重定向至云中,將數(shù)據(jù)同步回數(shù)據(jù)中心

Netflix很快將在6個新國家落地.我們決定利用這一機會直接通過云環(huán)境運行這些國家的部分計費系統(tǒng).這意味著面向用戶的數(shù)據(jù)和應(yīng)用程序?qū)脑浦羞\行,但依然需要將數(shù)據(jù)同步回數(shù)據(jù)中心,這樣數(shù)據(jù)中心內(nèi)的批處理應(yīng)用程序才能繼續(xù)運行,不至于影響到業(yè)務(wù)運轉(zhuǎn).這些新落地國家客戶的數(shù)據(jù)將保存在云中,但批處理任務(wù)依然在數(shù)據(jù)中心內(nèi)處理.這是我們的第一步.

我們將2個面向用戶的應(yīng)用程序中的所有API移植到使用Spring Boot和Spring Integration開發(fā)的云應(yīng)用程序中.通過使用Spring Boot可以快速著手創(chuàng)建新應(yīng)用程序,這個產(chǎn)品內(nèi)建了開發(fā)工作所需的基礎(chǔ)結(jié)構(gòu)和組件,可以讓我們更專注業(yè)務(wù)邏輯本身.

通過使用Spring Integration,只需一次開發(fā)碼即可重復(fù)使用大部分工作流風(fēng)格的代碼.借助這些產(chǎn)品對Header以及基于Header的路由技術(shù)提供的支持,我們可以在應(yīng)用程序內(nèi)部實現(xiàn)Pub-sub模式,將消息放入一個渠道(Channel),并讓每個用戶通過各自獨立的方式使用.

在將數(shù)據(jù)存儲于Cassandra的情況下,現(xiàn)在可以通過任意AWS區(qū)域處理這6個新國家會員的API調(diào)用.就算某個AWS區(qū)域徹底故障,這些國家的計費操作也不會受到影響,而這也是我們首次真正意義上認識到云計算的威力!

我們在AWS多個區(qū)域的EC2實例上部署了自己的應(yīng)用程序,另外為現(xiàn)有的云代理應(yīng)用程序增加了一個重定向?qū)?以便將新落地國家用戶的計費調(diào)用切換至云中新部署的計費API,并讓原有國家用戶的計費調(diào)用繼續(xù)由數(shù)據(jù)中心內(nèi)原有的計費API處理.

我們從一個AWS區(qū)域建立了到數(shù)據(jù)中心內(nèi)現(xiàn)有Oracle數(shù)據(jù)庫的直接連接,并開發(fā)了一個程序,通過SQS將另外3個區(qū)域中的Cassandra數(shù)據(jù)與這個建立了直接連接的區(qū)域進行同步.我們還使用SQS隊列和Dead Letter Queues(DLQ)在故障的區(qū)域和過程之間移動數(shù)據(jù).

在新國家落地通常意味著會員數(shù)量的激增.我們也明白,為了確保數(shù)據(jù)中心不超載,還必須將現(xiàn)有的續(xù)訂應(yīng)用程序從數(shù)據(jù)中心搬入云中.因此對于通過云服務(wù)運行的6個新落地國家,我們編寫了一個爬蟲程序,可以每天一次遍歷Cassandra中的所有客戶,借此找出所有當天需要收費的會員.

這種“逐行迭代”的方法目前在這些國家很好用,但我們也清楚,在將其他國家,尤其是美國(目前我們的絕大部分會員都在美國)的數(shù)據(jù)遷移到云中之后這種方式將會失效.但我們想先行一步試試水有多深.這也是目前這一階段唯一在云中運行的批處理應(yīng)用程序.

為了能夠在任何一個區(qū)域執(zhí)行寫操作,并將寫操作快速復(fù)制到其他區(qū)域,我們選擇用Cassandra作為數(shù)據(jù)存儲.我們定義了一種數(shù)據(jù)模型,在其中使用customerId作為行,并創(chuàng)建了一系列復(fù)合的Cassandra列借此體現(xiàn)數(shù)據(jù)之間的關(guān)系性.下圖展示了這些項之間的關(guān)系,以及我們是如何在Cassandra中使用單列族(Single column family)進行體現(xiàn)的.用單列族形式設(shè)計這樣的關(guān)系使得我們能為相關(guān)項提供事務(wù)支持.

通過對應(yīng)用程序的邏輯進行設(shè)計,只需要在任何操作開始執(zhí)行時讀取一次,隨后即可在內(nèi)存中更新對象,并在操作結(jié)束后將其以單列族的形式持久存儲.在操作過程中讀取或?qū)懭隒assandra的操作會被看作一種反模式(Anti-pattern).我們使用Astyanax(Netflix自行開發(fā)并已開源的Cassandra客戶端)編寫了自定義的ORM,這樣就可以針對Cassandra讀/寫域?qū)ο?

我們通過這種方式將服務(wù)落地到新的國家,雖然遇到了幾個小問題,但在迅速修復(fù)后整個系統(tǒng)運轉(zhuǎn)很穩(wěn)定.目前來說一切都挺不錯的!

經(jīng)過第1步工作后計費系統(tǒng)的體系結(jié)構(gòu)如下圖所示：

第2步 – 遷移所有應(yīng)用程序,并將原有國家遷移至云中

第1步成功完成后,我們開始考慮在不遷移數(shù)據(jù)庫的情況下將其他應(yīng)用遷至云中.大部分業(yè)務(wù)邏輯位于批處理應(yīng)用程序中,多年來已經(jīng)發(fā)展得極為成熟,但這也意味著必須深入到每個條件的代碼中并花費大量時間重寫.這些應(yīng)用程序無法“照原樣”直接搬到云中運行.

同時我們也借助這次機會盡量移除了所有不再使用的代碼,將不同功能拆分為多個專用的小應(yīng)用程序,并為了更好的擴展性重構(gòu)了現(xiàn)有代碼.這些遺留應(yīng)用程序被我們設(shè)計為會在啟動時讀取磁盤上的配置文件,并使用了其他一些靜態(tài)資源,例如從Weblogic隊列讀取消息,由于實例與生俱來的“短暫”本質(zhì),這些特征在云環(huán)境中都是反模式的.

因此為了讓應(yīng)用程序在云平臺上順利運行,只能重新實現(xiàn)這些模塊.為了通過異步模式將消息穿過隊列移動到不同區(qū)域,我們還更改了一些API,并在這些區(qū)域建立了到數(shù)據(jù)中心的安全連接.

云數(shù)據(jù)庫工程團隊為我們的數(shù)據(jù)需求搭建了多節(jié)點Cassandra集群.我們也清楚,在將所有Netflix會員的計費數(shù)據(jù)遷移到Cassandra之后,以前用來為最早的6個國家的客戶提供續(xù)訂服務(wù)所用的“全行(Row)式”Cassandra迭代器續(xù)訂解決方案將無法很好地伸縮.

因此我們使用Aegisthus設(shè)計了一個系統(tǒng),可從Cassandra SSTable拉取數(shù)據(jù)并將其轉(zhuǎn)換為JSON格式的行,將其暫存在S3 Bucket中.隨后我們寫了一些Pig腳本,借此每天針對大量數(shù)據(jù)集運行Mapreduce作業(yè),找出需要續(xù)訂的客戶清單并向他們收費.

我們還寫了Sqoop作業(yè)以便從Cassandra和Oracle中拉取數(shù)據(jù),并將其以可查詢格式寫入Hive,這樣就可以將這兩套數(shù)據(jù)集匯總至Hive,實現(xiàn)更快速的排錯.

為了讓DVD服務(wù)器能夠連接云環(huán)境,我們?yōu)镈VD設(shè)置了負載平衡端點(包含SSL客戶端證書),DVD服務(wù)器可以通過云代理對所有調(diào)用進行路由,在遷移美國系統(tǒng)之前可以借此將調(diào)用重新發(fā)回數(shù)據(jù)中心.美國系統(tǒng)的數(shù)據(jù)遷移完成后,即可斷開云和數(shù)據(jù)中心之間的通信鏈路.

為了對這一大規(guī)模數(shù)據(jù)遷移的結(jié)果進行驗證,我們編寫了對已遷往云中的數(shù)據(jù),以及數(shù)據(jù)中心內(nèi)部現(xiàn)有數(shù)據(jù)進行比較和驗證的對比工具.反復(fù)運行該對比工具可找出遷移過程中可能存在的Bug,修復(fù)發(fā)現(xiàn)的問題,清理數(shù)據(jù)并再次運行.

隨著運行結(jié)果愈發(fā)整潔,完全沒有出現(xiàn)任何錯誤,這也進一步增強了我們對數(shù)據(jù)遷移工作的信心.對于針對各國數(shù)據(jù)進行的遷移工作我們感到十分激動.最開始我們選擇了一個Netflix會員數(shù)量比較少的國家,并通過下列步驟將數(shù)據(jù)遷入云中：

• 禁用待遷移國家的非GET API(該操作不會影響會員服務(wù),但可能導(dǎo)致計費系統(tǒng)中訂閱更新工作延遲).

• 使用Sqoop作業(yè)將數(shù)據(jù)從Oracle轉(zhuǎn)移至S3和Hive.

• 使用Pig將其轉(zhuǎn)換為Cassandra格式.

• 將該國家所有會員的記錄插入Cassandra.
• 啟用非GET API,通過云平臺為被遷移國家的用戶提供數(shù)據(jù).

在確認一切正常后開始遷移下一個國家.隨后我們開始突擊對所有類似國家一起進行遷移.最后遷移的是美國,因為美國的會員數(shù)量最多,并且還提供有DVD訂閱服務(wù).至此所有面向Netflix會員客戶的數(shù)據(jù)都已通過云環(huán)境提供.對我們來說這是一個巨大的里程碑!

經(jīng)過第2步工作后,我們的體系結(jié)構(gòu)如下圖所示：

第3步 – 再見,數(shù)據(jù)中心!

至此還有最后(并且最重要)的一件事：數(shù)據(jù)中心內(nèi)運行的Oracle數(shù)據(jù)庫.Oracle中存儲的數(shù)據(jù)集具有高度的關(guān)系性,我們覺得這些數(shù)據(jù)并不適合以NoSQL的方式進行建模.

這種數(shù)據(jù)不能像以前處理面向客戶的訂閱數(shù)據(jù)那樣構(gòu)造為單列族的形式,因此我們評估了Oracle和Aurora RDS這兩種選項.但Oracle作為云數(shù)據(jù)庫運行的許可成本,以及Aurora依然是Beta測試版這一現(xiàn)狀使得則兩種方式都不適合我們.

在計費團隊忙于執(zhí)行前兩個步驟時,我們的云數(shù)據(jù)庫工程團隊正在創(chuàng)建用于將計費數(shù)據(jù)遷移至EC2上MySQL實例所需的基礎(chǔ)結(jié)構(gòu).在開始執(zhí)行第三步操作時,在他們的幫助下數(shù)據(jù)庫基礎(chǔ)結(jié)構(gòu)部分已經(jīng)就緒.

因為一些應(yīng)用程序使用了不包含任何ORM的純JDBC,我們還需要將批處理應(yīng)用程序的代碼基轉(zhuǎn)換為兼容MySQL的格式.另外我們處理了大量遺留的Pl-sql代碼,并重寫了應(yīng)用程序中的邏輯,同時盡可能去除了不再使用的代碼.

至此我們的數(shù)據(jù)庫體系結(jié)構(gòu)已經(jīng)由部署在某一AWS區(qū)域內(nèi)EC2實例上的MySQL主數(shù)據(jù)庫組成.我們還搭建了一個從主數(shù)據(jù)庫復(fù)制數(shù)據(jù)的災(zāi)難恢復(fù)數(shù)據(jù)庫,如果主數(shù)據(jù)庫故障,該數(shù)據(jù)庫將成為新的主數(shù)據(jù).另外我們還在在其他AWS區(qū)域設(shè)置了從數(shù)據(jù)庫,這些數(shù)據(jù)庫主要為應(yīng)用程序提供只讀訪問.

至此我們的計費系統(tǒng)已經(jīng)全部搬入云中,現(xiàn)在看起來是下面這個樣子：

數(shù)據(jù)庫的遷移過程

接下來將深入介紹數(shù)據(jù)庫的遷移過程.希望我們的經(jīng)驗?zāi)軒湍沩樌瓿勺约旱倪w移任務(wù).

你是否考慮過為了順利完成復(fù)雜的數(shù)據(jù)庫遷移任務(wù),都需要考慮并解決哪些問題?但你可能也會問,“這有什么復(fù)雜的?”

想想數(shù)據(jù)庫遷移過程中遇到的下列挑戰(zhàn)吧,我們本次遷移幾乎遇到了所有這些問題：

• 源和目標硬件存在差異；

• 使用了不同的操作系統(tǒng)；

• 需要跨域異構(gòu)數(shù)據(jù)庫進行遷移；

• 涉及多個數(shù)據(jù)中心 – Netflix數(shù)據(jù)中心(DC)和AWS云；

• 要遷移的是非常關(guān)鍵的交易計費數(shù)據(jù)；

• 有選擇地遷移數(shù)據(jù)集；
• 需要在最小停機時間的前提下遷移持續(xù)變化的數(shù)據(jù).

在任何遷移項目中,數(shù)據(jù)庫的遷移都是最基本要素,數(shù)據(jù)庫能否成功遷移直接決定了整個項目能否成功.下文將介紹為確保遷移項目成功完成所采取的一些關(guān)鍵措施.

數(shù)據(jù)庫的選擇

為順利處理付款過程中產(chǎn)生的事務(wù),計費應(yīng)用程序的事務(wù)須符合ACID(原子性、一致性、隔離性、持久性)要求.RDBMS似乎是此類數(shù)據(jù)存儲的最佳選擇.

Oracle：由于源數(shù)據(jù)庫使用了Oracle產(chǎn)品,直接遷移至云中運行的Oracle數(shù)據(jù)庫可避免進行跨數(shù)據(jù)庫遷移,降低代碼開發(fā)和配置工作量.我們過去在生產(chǎn)環(huán)境中使用Oracle產(chǎn)品的體驗也讓自己對該產(chǎn)品的性能和伸縮性更有信心.然而考慮到許可成本以及“依原樣”遷移遺留數(shù)據(jù)所要產(chǎn)生的技術(shù)債,最終只能尋求其他解決方案.

AWS RDS MySQL：理想情況下我們會選擇MySQL?RDS作為后端,畢竟亞馬遜在關(guān)系型數(shù)據(jù)庫即服務(wù)產(chǎn)品的管理和升級方面做的挺好,為了實現(xiàn)高可用還提供了多可用區(qū)(AZ)支持.然而RDS的主要不足之處在于存儲容量有著6TB上限.我們遷移時的容量已接近10TB.

AWS Aurora：AWS Aurora可以滿足我們對存儲容量的需求,但目前還是Beta測試版.

PostgreSQL：PostgreSQL是一種強大的對象-關(guān)系開源數(shù)據(jù)庫系統(tǒng),但我們團隊內(nèi)部缺乏足夠的PostgreSQL使用經(jīng)驗.在自己的數(shù)據(jù)中心內(nèi)我們主要使用Oracle和MySQL作為后端數(shù)據(jù)庫,更重要的是選擇PostgreSQL會導(dǎo)致未來無法無縫遷移至Aurora,因為Aurora使用了基于MySQL的引擎.

EC2 MySQL：最終我們的計費系統(tǒng)選擇使用EC2 MySQL,這種技術(shù)無須許可成本,同時未來可以直接遷移至Aurora.該方式需要在i2.8xlarge實例上使用InnoDB引擎配置MySQL.

生產(chǎn)數(shù)據(jù)庫體系結(jié)構(gòu)

為確保計費應(yīng)用程序可以承受基礎(chǔ)結(jié)構(gòu)、區(qū)域和地域故障,并將可能的停機時間降至最低,高可用性和伸縮性是我們設(shè)計整個體系結(jié)構(gòu)時最主要的考慮因素.

通過在另一個區(qū)域內(nèi)為數(shù)據(jù)庫主副本創(chuàng)建DRBD副本,即可承受區(qū)域故障,節(jié)點出錯等基礎(chǔ)結(jié)構(gòu)故障,以及EBS卷故障.當本地和遠程寫操作均完成后,會使用“同步復(fù)制協(xié)議”將主要節(jié)點上的寫操作標記為已完成.借此可確保一個節(jié)點的故障絕對不會導(dǎo)致數(shù)據(jù)丟失.雖然這樣的設(shè)計會影響寫操作的延遲,但延遲依然在SLA可接受的范圍內(nèi).

讀取副本可設(shè)置為本地或跨區(qū)域配置,這樣不僅可以滿足對高可用的需求,而且有助于增強伸縮性.來自ETL作業(yè)的讀取流量會分流至讀取副本,借此降低主要數(shù)據(jù)庫執(zhí)行繁重ETL批處理的負擔(dān).

一旦主要MySQL數(shù)據(jù)庫故障,工作負載將被故障轉(zhuǎn)移至使用同步模式進行復(fù)制的DRBD輔助節(jié)點.輔助節(jié)點開始承擔(dān)主節(jié)點的角色后,會更改數(shù)據(jù)庫主機的route53 DNS記錄將其指向新的主節(jié)點.按照設(shè)計,計費應(yīng)用程序與生俱來的“批處理”特性可順利應(yīng)對此類停機事件.CNAME記錄傳播工作完成后,客戶端連接不會回退(Fallback),而是會建立指向新主節(jié)點的連接.

遷移工具的選擇

我們在遷移工具的選擇方面花費了大量時間和精力.概念驗證工作成功與否的最主要條件在于能否重啟動批載荷(Bulk load)、雙向復(fù)制,以及數(shù)據(jù)完整性.在評估遷移工具時我們主要側(cè)重于下列幾個條件.

• 批/增量載荷的重啟動；

• 雙向復(fù)制；

• 每個表并行性(Parallelism per table)；

• 數(shù)據(jù)完整性；

• 傳輸過程中錯誤報告；

• 上線后回滾的能力；

• 性能；
• 易用性.

GoldenGate以豐富的功能脫穎而出,該產(chǎn)品很好地滿足了我們的需求.GoldenGate可以在遇到故障后重啟動批載荷(很少的幾張表就達到數(shù)百GB容量),該產(chǎn)品的雙向復(fù)制功能可以讓我們從MySQL輕松回滾到Oracle.

GoldenGate的主要不足在于了解該工具工作原理所面臨的學(xué)習(xí)曲線.此外該產(chǎn)品使用了易于出錯的手工配置過程,這也增大了項目難度.如果源表沒有主鍵或唯一鍵,GoldenGate會使用所有列作為提取和復(fù)制操作的增補日志鍵對.但我們發(fā)現(xiàn)了一些問題,例如復(fù)制到目標的數(shù)據(jù)僅僅是相關(guān)表的增量載荷,因此決定在切換這些表的過程中執(zhí)行不預(yù)定義主鍵或唯一鍵的完整加載.GoldenGate的優(yōu)勢和包含的功能遠遠超過了所造成的困難,我們最終選擇使用該工具.

架構(gòu)轉(zhuǎn)換和驗證

由于源和目標數(shù)據(jù)庫存在差異,數(shù)據(jù)類型和長度也有所不同,為了在遷移數(shù)據(jù)的同時確保數(shù)據(jù)完整性,驗證工作變得必不可少.

數(shù)據(jù)類型誤配造成的問題需要花些時間來修復(fù).例如因為一些歷史遺留原因,Oracle中的很多數(shù)值已定義為Number數(shù)據(jù)類型,MySQL缺少類似的類型.Oracle中的Number數(shù)據(jù)類型會存儲定數(shù)和浮點數(shù),這一點比較難以處理.

一些源表中的列使用Number代表整數(shù),另一些情況則會代表十進制數(shù)值,其中一些值的長度甚至達到38位.作為對比,MySQL使用了明確的數(shù)據(jù)類型,例如Int、bigInt、decimal、double等,而bigInt不能超過18位.因此必須確保通過恰當?shù)挠成湟员阍贛ySQL中反應(yīng)精確的值.

分區(qū)表(Partitioned table)需要特殊處理,與Oracle的做法不同,MySQL會將分區(qū)鍵視作主鍵和唯一鍵的一部分.為確保不對應(yīng)用邏輯和查詢產(chǎn)生影響,必須用恰當?shù)姆謪^(qū)鍵重新定義目標架構(gòu).

默認值的處理在MySQL和Oracle之間也有不同.對于包含NOT NULL值的列,MySQL會確定該列暗含的默認值,在MySQL中啟用Strict模式即可看到此類數(shù)據(jù)轉(zhuǎn)換問題,這樣的事務(wù)會執(zhí)行失敗并顯示在GoldenGate的錯誤日志中.

架構(gòu)轉(zhuǎn)換工具：為了實現(xiàn)架構(gòu)轉(zhuǎn)換并進行驗證,我們評估了多種工具,但由于原有架構(gòu)設(shè)計中所存在的問題,這些工具默認提供的架構(gòu)轉(zhuǎn)換功能無法使用.即使GoldenGate也無法將Oracle架構(gòu)轉(zhuǎn)換為相應(yīng)的MySQL版本,因此只能首先由應(yīng)用程序的所有者重新定義架構(gòu).

優(yōu)化架構(gòu)也是我們此次遷移的目標之一,數(shù)據(jù)庫和應(yīng)用程序團隊合作審閱了數(shù)據(jù)類型,并通過多次迭代找出了所有誤配的內(nèi)容.在存在誤配的情況下,GoldenGate會對這些值進行截斷以符合MySQL數(shù)據(jù)類型的要求.問了緩解這一問題,我們主要借助數(shù)據(jù)對比工具和GoldenGate錯誤日志找出源和目標之間數(shù)據(jù)類型的誤配.

數(shù)據(jù)完整性

完整加載和增量加載執(zhí)行完畢后,又遇到另一個讓人氣餒的問題：必須核實目標副本的數(shù)據(jù)完整性.由于Oracle和MySQL使用了不同數(shù)據(jù)類型,無法通過用普通封裝腳本對比行鍵(Rowkey)哈希值的方式保證數(shù)據(jù)的精確性.

雖然有幾個第三方工具能跨越不同數(shù)據(jù)庫對實際值進行數(shù)據(jù)對比,但總量10TB的數(shù)據(jù)集比較起來也不容易.最終我們使用這些工具對比了樣本數(shù)據(jù)集,借此找出了少數(shù)由于架構(gòu)映射錯誤導(dǎo)致的不一致問題.

測試刷新：確保數(shù)據(jù)完整性的方法之一是使用應(yīng)用程序?qū)ιa(chǎn)數(shù)據(jù)庫的副本進行測試.為此可安排從MySQL生產(chǎn)數(shù)據(jù)庫進行刷新并用于測試.考慮到生產(chǎn)環(huán)境使用EBS作為存儲,只要創(chuàng)建EBS快照即可輕松創(chuàng)建測試環(huán)境,同時可在測試中執(zhí)行時間點恢復(fù).為確保足夠高的數(shù)據(jù)質(zhì)量,這一過程重復(fù)了多次.

Sqoop作業(yè)：我們在數(shù)據(jù)校正過程中使用了ETL作業(yè)和報表,并使用Sqoop作業(yè)從Oracle中拉取創(chuàng)建報表所需的數(shù)據(jù).此外還針對MySQL配置了這些作業(yè).在源和目標之間進行持續(xù)復(fù)制的過程中,會在ETL的特定時間窗口內(nèi)運行報表,這樣即可找出增量加載過程中產(chǎn)生的變化.

行計數(shù)(Row count)是用于對源/目標進行比較和匹配的另一種方法.為此需要首先暫停目標的增量加載,并對Oracle和MySQL的行數(shù)進行匹配.在使用GoldenGate完整加載表之后也會對行計數(shù)的結(jié)果進行比較.

性能調(diào)優(yōu)

基礎(chǔ)結(jié)構(gòu)：計費應(yīng)用程序?qū)?shù)據(jù)持久保存在數(shù)據(jù)中心內(nèi)兩個Oracle數(shù)據(jù)庫中,運行數(shù)據(jù)庫的計算機性能極為強大,使用了IBM Power 7,32顆雙核心64位處理器,750GB內(nèi)存,通過SVC MCS集群分配TB級別的存儲,集群使用了4GB/s接口,運行RAID10配置的8G4集群.

遷移過程中最大的顧慮是性能,目標數(shù)據(jù)庫將整合到一個裝備有32顆vCPU和244GB內(nèi)存的i2.8xlarge服務(wù)器上.為了優(yōu)化查詢性能,應(yīng)用程序團隊在應(yīng)用層進行了大量調(diào)優(yōu).在Vector的幫助下,性能團隊可以方便地發(fā)現(xiàn)性能瓶頸,通過調(diào)整特定的系統(tǒng)和內(nèi)核參數(shù)解決這些問題.詳細信息請參閱附件.

我們用EBS供應(yīng)的IOPS卷組建RAID0實現(xiàn)了極高的讀寫性能.為了通過每個卷獲得更高吞吐率,共使用5個容量各4TB的卷,而沒有使用更大容量的單個卷.這樣做也可以加快創(chuàng)建快照和還原的速度.

數(shù)據(jù)庫：對于MySQL的使用我們還有一個比較大的顧慮,擔(dān)心計費應(yīng)用程序在對數(shù)據(jù)執(zhí)行批處理過程中MySQL的吞吐率無法滿足數(shù)據(jù)規(guī)模的需求.Percona為此提供了顧問支持,在遷移過程中以及遷移之后,MySQL數(shù)據(jù)庫的性能表現(xiàn)都讓我們感到滿意.

這里的訣竅在于使用兩個cnf文件,一個用于遷移數(shù)據(jù)的過程中對innodb_log_file_size之類的參數(shù)進行優(yōu)化,以便執(zhí)行批量插入；第二個cnf文件用于在實時生產(chǎn)應(yīng)用程序工作負載中對innodb_buffer_pool_instances之類的參數(shù)進行調(diào)整,借此促進事務(wù)的實時加載.詳情請參閱附件.

數(shù)據(jù)加載：在概念驗證過程中,我們針對開啟和關(guān)閉索引兩種情況測試了表的初始加載,并決定在加載前啟用所有索引.這樣做的原因在于MySQL中索引是通過單線程方式創(chuàng)建的(大部分表有多個索引),因此我們改為使用GoldenGate的并行加載功能在合理的時間內(nèi)為表中填入索引.最后一次割接過程中還啟用了外鍵約束.

我們學(xué)到的另一個竅門是按照實例的內(nèi)核數(shù)量執(zhí)行相同遍數(shù)的完整和增量加載過程.如果這些過程的執(zhí)行遍數(shù)超過內(nèi)核數(shù)量,數(shù)據(jù)加載性能將大幅降低,因為實例需要花費更多時間進行上下文切換.通過完整加載和增量加載將10TB數(shù)據(jù)裝入目標MySQL數(shù)據(jù)庫,這一過程用了大約兩周時間.

結(jié)論

雖然對任何遷移項目來說,數(shù)據(jù)庫的遷移都是最大挑戰(zhàn),但真正決定項目成功與否的關(guān)鍵在于要確保一開始就選擇了正確的方法,并且在整個執(zhí)行過程中與應(yīng)用程序團隊密切合作.

回顧整個遷移過程,這個項目的成功完全是組織內(nèi)部不同團隊通力合作的成果,大家一起制定的整個遷移計劃是促成這一切的關(guān)鍵!為了在不影響業(yè)務(wù)的前提下順利完成整個充滿挑戰(zhàn)的遷移項目,除了人員和團隊之間的相互協(xié)調(diào),自由的文化和責(zé)任感也是促成這一切必不可少的要素.

附件

批量插入時對數(shù)據(jù)庫的調(diào)節(jié)

高事務(wù)吞吐率的數(shù)據(jù)庫調(diào)節(jié)

存儲

• 使用5個4TB EBS PIOPS卷組建RAID0

• 使用LVM管理同一卷組中的兩個邏輯卷(DB和DRBD元數(shù)據(jù))

CPU調(diào)度器方面的調(diào)節(jié)

虛擬機的調(diào)節(jié)

文件系統(tǒng)和IO存儲指標

文章出處：InfoQ

本文翻譯已獲授權(quán)有刪節(jié),原文地址：

http://techblog.netflix.com/2016/07/netflix-billing-migration-to-aws-part-ii.html

http://techblog.netflix.com/2016/08/netflix-billing-migration-to-aws-part.html

本文譯者：大愚若智

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4447.html