時(shí)至今日，各類組織都面對著前所未有的數(shù)據(jù)量增長與數(shù)據(jù)復(fù)雜性提升。但是，如此寶貴的資產(chǎn)中只有一小部分可被實(shí)際用于分析。傳統(tǒng)的本地MPP數(shù)據(jù)倉庫（例如Teradata、IBM Netezza、Greenplum以及Vertica等）都采用嚴(yán)格的架構(gòu)設(shè)定，無法適應(yīng)現(xiàn)代大數(shù)據(jù)分析用例。這類傳統(tǒng)數(shù)據(jù)倉庫的部署與運(yùn)營成本也更高，需要在軟件及硬件層面進(jìn)行大量前期投資。另外，它們也無法支持需要高級機(jī)器學(xué)習(xí)與個(gè)性化體驗(yàn)的現(xiàn)代用例，例如實(shí)時(shí)或預(yù)測式分析與應(yīng)用程序。
Amazon Redshift是一項(xiàng)快速、全托管、云原生且極具成本效益的數(shù)據(jù)倉庫，能夠?qū)⒛姆治龉艿缽倪@些限制中解放出來。大家可以在您的Amazon Redshift集群當(dāng)中面向PB級別的龐大數(shù)據(jù)執(zhí)行查詢，甚至可以直接對接數(shù)據(jù)湖中高達(dá)EB級別的數(shù)據(jù)集合。大家還可以在幾分鐘之內(nèi)建立一套云數(shù)據(jù)倉庫，每小時(shí)起步使用成本僅為0.25美元，而后以每TB每年1000美元的低廉價(jià)格將數(shù)據(jù)體量擴(kuò)展至PB水平——這一成本甚至不足其他競爭對手解決方案的十分之一。
面對當(dāng)前數(shù)以萬計(jì)的全球部署與快速增長，Amazon Redshift也迎來了無數(shù)希望從傳統(tǒng)MPP數(shù)據(jù)倉庫遷移至這一新型云端數(shù)據(jù)倉庫解決方案的客戶，以及由他們帶來的巨大需求。AWS Schema Conversion Tool(SCT)能夠自動(dòng)將源數(shù)據(jù)庫schema與大多數(shù)數(shù)據(jù)庫代碼對象（包括視圖、存儲過程與函數(shù)）轉(zhuǎn)換為Amazon Redshift中的等效功能，極大提升此類MPP遷移效果的可預(yù)測性。SCT還可以使用內(nèi)置數(shù)據(jù)遷移代理，幫助客戶將數(shù)據(jù)從多個(gè)數(shù)據(jù)倉庫處統(tǒng)一遷移至Amazon Redshift。
大規(guī)模MPP數(shù)據(jù)倉庫遷移不僅伴隨著極高的項(xiàng)目復(fù)雜性，同時(shí)也在資源、時(shí)間與成本方面帶來一系列風(fēng)險(xiǎn)挑戰(zhàn)。但通過以主題及對象層級為基礎(chǔ)的數(shù)據(jù)倉庫遷移路線圖，大家可以極大降低陳舊數(shù)據(jù)倉庫與工作負(fù)載遷移所帶來的復(fù)雜度水平。
AWS Professional Services結(jié)合我們過去幾年中參與的一系列大型MPP數(shù)據(jù)倉庫遷移項(xiàng)目，設(shè)計(jì)并開發(fā)出這款工具。相關(guān)方法充分汲取來自ETL與報(bào)告工作負(fù)載中的分析經(jīng)驗(yàn)，全面考量其間涉及的高復(fù)雜度依賴關(guān)系。以多個(gè)維度為基礎(chǔ)，其將復(fù)雜的數(shù)據(jù)倉庫遷移項(xiàng)目拆分成多個(gè)邏輯與系統(tǒng)波次，包括業(yè)務(wù)優(yōu)先級、數(shù)據(jù)依賴關(guān)系、工作負(fù)載概況以及現(xiàn)有服務(wù)水平協(xié)議（SLA）等。
基于消費(fèi)的遷移方法
基于消費(fèi)的遷移模式已經(jīng)被證明是一種行之有效且效率極高的MPP數(shù)據(jù)倉庫遷移方法。該模式通過一系列操作將工作負(fù)載從源MPP數(shù)據(jù)倉庫遷移至Amazon Redshift。在完全淘汰源MPP數(shù)據(jù)倉庫之前，大家應(yīng)并行運(yùn)行源MPP數(shù)據(jù)倉庫與Amazon Redshift并保持一段時(shí)間。
數(shù)據(jù)倉庫擁有以下兩大邏輯組件：
·主題域——數(shù)據(jù)源與數(shù)據(jù)域的組合，其通常與業(yè)務(wù)功能（例如銷售或支付）相關(guān)聯(lián)。
·應(yīng)用程序——一種分析方法，通過消費(fèi)一個(gè)或者多個(gè)主題域?yàn)榭蛻籼峁﹥r(jià)值。
以下示意圖，展示了數(shù)據(jù)主題域與信息消耗的具體工作流。
圖一：消費(fèi)應(yīng)用程序（報(bào)告/分析）與主題域（數(shù)據(jù)源/域）。
這種方法有助于促進(jìn)客戶建立數(shù)據(jù)驅(qū)動(dòng)型企業(yè)（D2E）。具體優(yōu)勢包括：1）幫助深入理解客戶的業(yè)務(wù)環(huán)境與用例；2）有助于制定企業(yè)數(shù)據(jù)遷移路線圖。
主題域與應(yīng)用程序之間的親和度映射
要確定應(yīng)該將哪些應(yīng)用程序及其相關(guān)主題域納入哪些波次，我們需要在應(yīng)用程序與主題域之間做出詳細(xì)映射。下表所示，為此類映射的相關(guān)示例。
圖二：應(yīng)用程序（分析）與主題域之初是的親和度映射。
這種映射的基礎(chǔ)，在于查詢執(zhí)行元數(shù)據(jù)——元數(shù)據(jù)通常存儲在傳統(tǒng)數(shù)據(jù)倉庫的系統(tǒng)表當(dāng)中。這種映射關(guān)系也將成為各個(gè)波次（即應(yīng)用程序?qū)ο笈c相關(guān)主題域的單步遷移）的創(chuàng)建基礎(chǔ)。您可以通過相同的方式得出下一步遷移操作，以更詳盡的方式（下探至表層級）建立數(shù)據(jù)源與主題域間的映射，并據(jù)此制定出更詳盡的遷移項(xiàng)目規(guī)劃。
上表中使用的排序方法非常重要。最右側(cè)的列，為主題域在應(yīng)用程序中出現(xiàn)的總次數(shù)（自上而下，為最常見的主題域到出現(xiàn)頻率最低的主題域）。最下行則為應(yīng)用程序中出現(xiàn)的主題域數(shù)量（從左至右，為包含主題域最多的應(yīng)用程序到包含主題域最少的應(yīng)用程序）。
在其他條件完全相同的情況下，我們的第一波遷移應(yīng)該從哪些應(yīng)用程序與分析開始？最佳實(shí)踐是選擇其中的某個(gè)中間位置（例如上表中的Analytic 8或者9位置）。如果從最左側(cè)的列（Analytic 1）開始，那么該波次中會包含大量對象（源與表、視圖、ETL腳本、數(shù)據(jù)格式、清理以及公開例程等），這將導(dǎo)致操作強(qiáng)度過大且完成周期過長?；蛘?，如果您從最右側(cè)的列（Analytic 19）開始，則涵蓋的主題域過少，并導(dǎo)致完成整體遷移所需要的波次更多、總體遷移周期更長。另外，從最右側(cè)開始也無法幫助我們了解整體項(xiàng)目的復(fù)雜度水平。
遷移波次與對象域集成
下表所示，為以上親和度圖的分波次遷移方案（階梯步進(jìn)）。在每個(gè)波次中（可能包含一個(gè)或者多個(gè)應(yīng)用程序或分析）總是存在新的主題域（綠色框體）以及在先前波次中已經(jīng)遷移完成的主題域（藍(lán)色框體）。基于波次的最佳遷移方法，在于將遷移波次的設(shè)計(jì)中保證每個(gè)后續(xù)波次中包含的新build越來越少。在以下示例中，隨著最初幾個(gè)波次的完成，我們需要集成至后續(xù)波次中的新主題域越來越少——也正因?yàn)槿绱?，我們才建議從親和度表的中間位置向左移動(dòng)。最終，這種方式能夠加快遷移項(xiàng)目的整體執(zhí)行速度。
圖三：階梯步進(jìn)模式與對象域集成。
第0波通常包含各應(yīng)用程序使用的共享或基礎(chǔ)維度數(shù)據(jù)或表（例如Time以及Organization）。每一波至少應(yīng)該包含一個(gè)錨應(yīng)用，且該錨應(yīng)用需要包含新的主題域或數(shù)據(jù)源。那么，我們在各波次中選擇錨應(yīng)用時(shí)，又該考慮哪些具體因素？首先，該波次內(nèi)的錨應(yīng)用與其他波次中的錨應(yīng)用應(yīng)盡可能保持較低的依賴度，而且從業(yè)務(wù)角度來看，錨應(yīng)用本身應(yīng)該具有較高的重要性。所有波次中的錨應(yīng)用組合還應(yīng)該涵蓋所有主題域。
在以上示例中，我們設(shè)置了六個(gè)不同的遷移波次。下表總結(jié)了其中使用的對應(yīng)錨應(yīng)用：
其他所有應(yīng)用程序（分析）將進(jìn)行自動(dòng)處理，因?yàn)樗鼈兯蕾嚨闹黝}域已經(jīng)在上述各波次中構(gòu)建完成。
關(guān)于各波次中應(yīng)用程序選擇的最佳實(shí)踐
要確定總遷移波次數(shù)量，以及每個(gè)波次中應(yīng)包含哪些應(yīng)用程序，請考慮以下因素：
·業(yè)務(wù)優(yōu)先級——即應(yīng)用程序在客戶數(shù)據(jù)驅(qū)動(dòng)型企業(yè)（D2E）旅程中的具體價(jià)值。
·工作負(fù)載概況——工作負(fù)載主要屬于ETL（寫入密集型）還是查詢（只讀?。?。
·數(shù)據(jù)共享要求——不同應(yīng)用程序可能使用同一表中的數(shù)據(jù)。
·應(yīng)用程序SLA——各應(yīng)用程序?yàn)樽罱K用戶做出的性能承諾指標(biāo)。
·依賴關(guān)系——不同應(yīng)用程序之間的功能依賴關(guān)系。
最佳波次數(shù)量將根據(jù)以上標(biāo)準(zhǔn)核算得出，最佳實(shí)踐建議在單一遷移項(xiàng)目當(dāng)中最多包含10個(gè)波次，保證您能夠有效對遷移進(jìn)行規(guī)劃、執(zhí)行與監(jiān)控。
關(guān)于哪些應(yīng)用程序應(yīng)該被納入哪個(gè)波次以及對應(yīng)理由，由于應(yīng)用程序之間的交互與性能影響往往非常復(fù)雜，因此很難通過第一原理快速做出判斷。以下是一些相關(guān)最佳實(shí)踐：
·通過實(shí)驗(yàn)與測試加深對應(yīng)用程序間交互方式以及相關(guān)性能影響的理解。
·根據(jù)相通的數(shù)據(jù)共享要求對應(yīng)用程序進(jìn)行分組。
·請注意，并不是所有工作負(fù)載都能隨著集群規(guī)模的擴(kuò)大獲得更佳性能。例如，簡單的儀表板查詢可能反而在小型集群上運(yùn)行得更快，而只有足夠復(fù)雜的查詢才能充分利用大規(guī)模Amazon Redshift集群中的所有分片。
·考慮對具有不同工作負(fù)載與訪問模式的應(yīng)用程序進(jìn)行分組。
·考慮為不同應(yīng)用程序波次提供專用集群。
·為每款應(yīng)用程序建立工作負(fù)載概況。
Amazon Redshift集群大小調(diào)整指南
Amazon Redshift節(jié)點(diǎn)類型將直接決定節(jié)點(diǎn)中配備的CPU、內(nèi)存、存儲容量以及存儲驅(qū)動(dòng)器類型。RA3節(jié)點(diǎn)類型允許您獨(dú)立擴(kuò)展計(jì)算與存儲資源，大家也需要為實(shí)際使用的計(jì)算量與Amazon Redshift托管存儲（RMS）單獨(dú)付費(fèi)。DS2節(jié)點(diǎn)類型則經(jīng)過優(yōu)化，能夠存儲大量數(shù)據(jù)并使用磁盤驅(qū)動(dòng)器（HDD）存儲形式。如果您目前正在使用DS2節(jié)點(diǎn)，請考慮升級至RA3集群，從而以相同的成本獲得2倍的性能與存儲資源。密集型計(jì)算（DC）節(jié)點(diǎn)類型則針對計(jì)算類工作負(fù)載進(jìn)行優(yōu)化。由于DC2節(jié)點(diǎn)類型使用固態(tài)存儲（SSD）驅(qū)動(dòng)器，因此相當(dāng)于對性能密集型工作負(fù)載進(jìn)行了優(yōu)化。
各Amazon Redshift節(jié)點(diǎn)類型還提供不同的節(jié)點(diǎn)大小選項(xiàng)。節(jié)點(diǎn)大小與節(jié)點(diǎn)數(shù)量決定了集群中的總體存儲容量。我們建議：1）如果壓縮后的數(shù)據(jù)大小小于1 TB，則應(yīng)選擇DC2節(jié)點(diǎn)類型；2）如果壓縮后的數(shù)據(jù)大小超過1 TB，請選擇RA3節(jié)點(diǎn)類型（RA3.4xlarge或者RA3.16xlarge）。
您在節(jié)點(diǎn)類型的選擇當(dāng)中，應(yīng)考慮以下幾項(xiàng)影響因素：
·下游系統(tǒng)為了滿足服務(wù)水平協(xié)議（SLA）所提出的實(shí)際計(jì)算資源需求。
·您需要在數(shù)據(jù)庫中支持的查詢與并發(fā)操作復(fù)雜度。
·在實(shí)現(xiàn)工作負(fù)載最佳性能與保障預(yù)算之間做出權(quán)衡。
·您希望存儲在集群中的數(shù)據(jù)量。
隨著數(shù)據(jù)與性能需求的不斷變化，您還可以輕松調(diào)整集群大小，以充分利用Amazon Redshift提供的計(jì)算與存儲選項(xiàng)。您可以使用Elastic Resize在幾分鐘之內(nèi)實(shí)現(xiàn)對Amazon Redshift集群的規(guī)模伸縮調(diào)整，處理可預(yù)測的峰值工作負(fù)載，并通過自動(dòng)并發(fā)擴(kuò)展功能提高即席查詢工作負(fù)載的性能表現(xiàn)。
除了將傳統(tǒng)MPP數(shù)據(jù)倉庫內(nèi)的數(shù)據(jù)遷移至Amazon Redshift托管存儲中之外，將這類數(shù)據(jù)遷移至其他目的地的場景也相當(dāng)常見。您可以將冷數(shù)據(jù)或歷史數(shù)據(jù)發(fā)送至Amazon S3數(shù)據(jù)湖以節(jié)約成本，也可以將溫?cái)?shù)據(jù)或熱數(shù)據(jù)發(fā)送至Amazon Redshift集群以實(shí)現(xiàn)最佳性能。Amazon Redshift Spectrum可幫助您輕松查詢并聯(lián)接各Amazon Redshift數(shù)據(jù)倉庫與Amazon S3數(shù)據(jù)湖之間的數(shù)據(jù)。使用AWS Glue與AWS Lambda函數(shù)帶來的強(qiáng)大無服務(wù)器數(shù)據(jù)湖架構(gòu)以及“湖邊小屋”架構(gòu)功能，您可以進(jìn)一步簡化ETL數(shù)據(jù)管道并將Amazon S3數(shù)據(jù)湖中的數(shù)據(jù)與云端數(shù)據(jù)倉庫相結(jié)合，最大限度減少需要加載至Amazon Redshift的數(shù)據(jù)量。
總結(jié)
本文演示了如何為復(fù)雜項(xiàng)目開發(fā)出基于波次的完整應(yīng)用程序遷移方法，使用Amazon Redshift實(shí)現(xiàn)傳統(tǒng)MPP數(shù)據(jù)倉庫的現(xiàn)代化轉(zhuǎn)型。此外，本文還立足業(yè)務(wù)優(yōu)先級、數(shù)據(jù)依賴關(guān)系、工作負(fù)載概況以及現(xiàn)有服務(wù)水平協(xié)議（SLA）等多個(gè)層面分享了最佳實(shí)踐與經(jīng)驗(yàn)心得。
這里要感謝AWS同事Corina Radovanovich,Jackie Jiang,Hunter Grider,Srinath Madabushi,Matt Scaer,Dilip Kikla,Vinay Shukla,Eugene Kawamoto,Maor Kleider,Himanshu Raja,Britt Johnston以及Jason Berkowitz為本文撰寫提供的寶貴反饋與建議。
Original URL:https://aws.amazon.com/cn/blogs/big-data/develop-an-application-migration-methodology-to-modernize-your-data-warehouse-with-amazon-redshift/
AWS
專欄
閩公網(wǎng)安備 35010202001226號
