開(kāi)發(fā)應(yīng)用程序遷移方法以使用Amazon Redshift 使您的數(shù)據(jù)倉(cāng)庫(kù)現(xiàn)代化

時(shí)至今日，各類(lèi)組織都面對(duì)著前所未有的數(shù)據(jù)量增長(zhǎng)與數(shù)據(jù)復(fù)雜性提升。但是，如此寶貴的資產(chǎn)中只有一小部分可被實(shí)際用于分析。傳統(tǒng)的本地MPP數(shù)據(jù)倉(cāng)庫(kù)（例如Teradata、IBM Netezza、Greenplum以及Vertica等）都采用嚴(yán)格的架構(gòu)設(shè)定，無(wú)法適應(yīng)現(xiàn)代大數(shù)據(jù)分析用例。這類(lèi)傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)的部署與運(yùn)營(yíng)成本也更高，需要在軟件及硬件層面進(jìn)行大量前期投資。另外，它們也無(wú)法支持需要高級(jí)機(jī)器學(xué)習(xí)與個(gè)性化體驗(yàn)的現(xiàn)代用例，例如實(shí)時(shí)或預(yù)測(cè)式分析與應(yīng)用程序。

Amazon Redshift是一項(xiàng)快速、全托管、云原生且極具成本效益的數(shù)據(jù)倉(cāng)庫(kù)，能夠?qū)⒛姆治龉艿缽倪@些限制中解放出來(lái)。大家可以在您的Amazon Redshift集群當(dāng)中面向PB級(jí)別的龐大數(shù)據(jù)執(zhí)行查詢(xún)，甚至可以直接對(duì)接數(shù)據(jù)湖中高達(dá)EB級(jí)別的數(shù)據(jù)集合。大家還可以在幾分鐘之內(nèi)建立一套云數(shù)據(jù)倉(cāng)庫(kù)，每小時(shí)起步使用成本僅為0.25美元，而后以每TB每年1000美元的低廉價(jià)格將數(shù)據(jù)體量擴(kuò)展至PB水平——這一成本甚至不足其他競(jìng)爭(zhēng)對(duì)手解決方案的十分之一。

面對(duì)當(dāng)前數(shù)以萬(wàn)計(jì)的全球部署與快速增長(zhǎng)，Amazon Redshift也迎來(lái)了無(wú)數(shù)希望從傳統(tǒng)MPP數(shù)據(jù)倉(cāng)庫(kù)遷移至這一新型云端數(shù)據(jù)倉(cāng)庫(kù)解決方案的客戶(hù)，以及由他們帶來(lái)的巨大需求。AWS Schema Conversion Tool(SCT)能夠自動(dòng)將源數(shù)據(jù)庫(kù)schema與大多數(shù)數(shù)據(jù)庫(kù)代碼對(duì)象（包括視圖、存儲(chǔ)過(guò)程與函數(shù)）轉(zhuǎn)換為Amazon Redshift中的等效功能，極大提升此類(lèi)MPP遷移效果的可預(yù)測(cè)性。SCT還可以使用內(nèi)置數(shù)據(jù)遷移代理，幫助客戶(hù)將數(shù)據(jù)從多個(gè)數(shù)據(jù)倉(cāng)庫(kù)處統(tǒng)一遷移至Amazon Redshift。

大規(guī)模MPP數(shù)據(jù)倉(cāng)庫(kù)遷移不僅伴隨著極高的項(xiàng)目復(fù)雜性，同時(shí)也在資源、時(shí)間與成本方面帶來(lái)一系列風(fēng)險(xiǎn)挑戰(zhàn)。但通過(guò)以主題及對(duì)象層級(jí)為基礎(chǔ)的數(shù)據(jù)倉(cāng)庫(kù)遷移路線圖，大家可以極大降低陳舊數(shù)據(jù)倉(cāng)庫(kù)與工作負(fù)載遷移所帶來(lái)的復(fù)雜度水平。

AWS Professional Services結(jié)合我們過(guò)去幾年中參與的一系列大型MPP數(shù)據(jù)倉(cāng)庫(kù)遷移項(xiàng)目，設(shè)計(jì)并開(kāi)發(fā)出這款工具。相關(guān)方法充分汲取來(lái)自ETL與報(bào)告工作負(fù)載中的分析經(jīng)驗(yàn)，全面考量其間涉及的高復(fù)雜度依賴(lài)關(guān)系。以多個(gè)維度為基礎(chǔ)，其將復(fù)雜的數(shù)據(jù)倉(cāng)庫(kù)遷移項(xiàng)目拆分成多個(gè)邏輯與系統(tǒng)波次，包括業(yè)務(wù)優(yōu)先級(jí)、數(shù)據(jù)依賴(lài)關(guān)系、工作負(fù)載概況以及現(xiàn)有服務(wù)水平協(xié)議（SLA）等。

基于消費(fèi)的遷移方法

基于消費(fèi)的遷移模式已經(jīng)被證明是一種行之有效且效率極高的MPP數(shù)據(jù)倉(cāng)庫(kù)遷移方法。該模式通過(guò)一系列操作將工作負(fù)載從源MPP數(shù)據(jù)倉(cāng)庫(kù)遷移至Amazon Redshift。在完全淘汰源MPP數(shù)據(jù)倉(cāng)庫(kù)之前，大家應(yīng)并行運(yùn)行源MPP數(shù)據(jù)倉(cāng)庫(kù)與Amazon Redshift并保持一段時(shí)間。

數(shù)據(jù)倉(cāng)庫(kù)擁有以下兩大邏輯組件：

·主題域——數(shù)據(jù)源與數(shù)據(jù)域的組合，其通常與業(yè)務(wù)功能（例如銷(xiāo)售或支付）相關(guān)聯(lián)。

·應(yīng)用程序——一種分析方法，通過(guò)消費(fèi)一個(gè)或者多個(gè)主題域?yàn)榭蛻?hù)提供價(jià)值。

以下示意圖，展示了數(shù)據(jù)主題域與信息消耗的具體工作流。

圖一：消費(fèi)應(yīng)用程序（報(bào)告/分析）與主題域（數(shù)據(jù)源/域）。

這種方法有助于促進(jìn)客戶(hù)建立數(shù)據(jù)驅(qū)動(dòng)型企業(yè)（D2E）。具體優(yōu)勢(shì)包括：1）幫助深入理解客戶(hù)的業(yè)務(wù)環(huán)境與用例；2）有助于制定企業(yè)數(shù)據(jù)遷移路線圖。

主題域與應(yīng)用程序之間的親和度映射

要確定應(yīng)該將哪些應(yīng)用程序及其相關(guān)主題域納入哪些波次，我們需要在應(yīng)用程序與主題域之間做出詳細(xì)映射。下表所示，為此類(lèi)映射的相關(guān)示例。

圖二：應(yīng)用程序（分析）與主題域之初是的親和度映射。

這種映射的基礎(chǔ)，在于查詢(xún)執(zhí)行元數(shù)據(jù)——元數(shù)據(jù)通常存儲(chǔ)在傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)的系統(tǒng)表當(dāng)中。這種映射關(guān)系也將成為各個(gè)波次（即應(yīng)用程序?qū)ο笈c相關(guān)主題域的單步遷移）的創(chuàng)建基礎(chǔ)。您可以通過(guò)相同的方式得出下一步遷移操作，以更詳盡的方式（下探至表層級(jí)）建立數(shù)據(jù)源與主題域間的映射，并據(jù)此制定出更詳盡的遷移項(xiàng)目規(guī)劃。

上表中使用的排序方法非常重要。最右側(cè)的列，為主題域在應(yīng)用程序中出現(xiàn)的總次數(shù)（自上而下，為最常見(jiàn)的主題域到出現(xiàn)頻率最低的主題域）。最下行則為應(yīng)用程序中出現(xiàn)的主題域數(shù)量（從左至右，為包含主題域最多的應(yīng)用程序到包含主題域最少的應(yīng)用程序）。

在其他條件完全相同的情況下，我們的第一波遷移應(yīng)該從哪些應(yīng)用程序與分析開(kāi)始？最佳實(shí)踐是選擇其中的某個(gè)中間位置（例如上表中的Analytic 8或者9位置）。如果從最左側(cè)的列（Analytic 1）開(kāi)始，那么該波次中會(huì)包含大量對(duì)象（源與表、視圖、ETL腳本、數(shù)據(jù)格式、清理以及公開(kāi)例程等），這將導(dǎo)致操作強(qiáng)度過(guò)大且完成周期過(guò)長(zhǎng)?；蛘?，如果您從最右側(cè)的列（Analytic 19）開(kāi)始，則涵蓋的主題域過(guò)少，并導(dǎo)致完成整體遷移所需要的波次更多、總體遷移周期更長(zhǎng)。另外，從最右側(cè)開(kāi)始也無(wú)法幫助我們了解整體項(xiàng)目的復(fù)雜度水平。

遷移波次與對(duì)象域集成

下表所示，為以上親和度圖的分波次遷移方案（階梯步進(jìn)）。在每個(gè)波次中（可能包含一個(gè)或者多個(gè)應(yīng)用程序或分析）總是存在新的主題域（綠色框體）以及在先前波次中已經(jīng)遷移完成的主題域（藍(lán)色框體）。基于波次的最佳遷移方法，在于將遷移波次的設(shè)計(jì)中保證每個(gè)后續(xù)波次中包含的新build越來(lái)越少。在以下示例中，隨著最初幾個(gè)波次的完成，我們需要集成至后續(xù)波次中的新主題域越來(lái)越少——也正因?yàn)槿绱耍覀儾沤ㄗh從親和度表的中間位置向左移動(dòng)。最終，這種方式能夠加快遷移項(xiàng)目的整體執(zhí)行速度。

圖三：階梯步進(jìn)模式與對(duì)象域集成。

第0波通常包含各應(yīng)用程序使用的共享或基礎(chǔ)維度數(shù)據(jù)或表（例如Time以及Organization）。每一波至少應(yīng)該包含一個(gè)錨應(yīng)用，且該錨應(yīng)用需要包含新的主題域或數(shù)據(jù)源。那么，我們?cè)诟鞑ù沃羞x擇錨應(yīng)用時(shí)，又該考慮哪些具體因素？首先，該波次內(nèi)的錨應(yīng)用與其他波次中的錨應(yīng)用應(yīng)盡可能保持較低的依賴(lài)度，而且從業(yè)務(wù)角度來(lái)看，錨應(yīng)用本身應(yīng)該具有較高的重要性。所有波次中的錨應(yīng)用組合還應(yīng)該涵蓋所有主題域。

在以上示例中，我們?cè)O(shè)置了六個(gè)不同的遷移波次。下表總結(jié)了其中使用的對(duì)應(yīng)錨應(yīng)用：

其他所有應(yīng)用程序（分析）將進(jìn)行自動(dòng)處理，因?yàn)樗鼈兯蕾?lài)的主題域已經(jīng)在上述各波次中構(gòu)建完成。

關(guān)于各波次中應(yīng)用程序選擇的最佳實(shí)踐

要確定總遷移波次數(shù)量，以及每個(gè)波次中應(yīng)包含哪些應(yīng)用程序，請(qǐng)考慮以下因素：

·業(yè)務(wù)優(yōu)先級(jí)——即應(yīng)用程序在客戶(hù)數(shù)據(jù)驅(qū)動(dòng)型企業(yè)（D2E）旅程中的具體價(jià)值。

·工作負(fù)載概況——工作負(fù)載主要屬于ETL（寫(xiě)入密集型）還是查詢(xún)（只讀?。?。

·數(shù)據(jù)共享要求——不同應(yīng)用程序可能使用同一表中的數(shù)據(jù)。

·應(yīng)用程序SLA——各應(yīng)用程序?yàn)樽罱K用戶(hù)做出的性能承諾指標(biāo)。

·依賴(lài)關(guān)系——不同應(yīng)用程序之間的功能依賴(lài)關(guān)系。

最佳波次數(shù)量將根據(jù)以上標(biāo)準(zhǔn)核算得出，最佳實(shí)踐建議在單一遷移項(xiàng)目當(dāng)中最多包含10個(gè)波次，保證您能夠有效對(duì)遷移進(jìn)行規(guī)劃、執(zhí)行與監(jiān)控。

關(guān)于哪些應(yīng)用程序應(yīng)該被納入哪個(gè)波次以及對(duì)應(yīng)理由，由于應(yīng)用程序之間的交互與性能影響往往非常復(fù)雜，因此很難通過(guò)第一原理快速做出判斷。以下是一些相關(guān)最佳實(shí)踐：

·通過(guò)實(shí)驗(yàn)與測(cè)試加深對(duì)應(yīng)用程序間交互方式以及相關(guān)性能影響的理解。

·根據(jù)相通的數(shù)據(jù)共享要求對(duì)應(yīng)用程序進(jìn)行分組。

·請(qǐng)注意，并不是所有工作負(fù)載都能隨著集群規(guī)模的擴(kuò)大獲得更佳性能。例如，簡(jiǎn)單的儀表板查詢(xún)可能反而在小型集群上運(yùn)行得更快，而只有足夠復(fù)雜的查詢(xún)才能充分利用大規(guī)模Amazon Redshift集群中的所有分片。

·考慮對(duì)具有不同工作負(fù)載與訪問(wèn)模式的應(yīng)用程序進(jìn)行分組。

·考慮為不同應(yīng)用程序波次提供專(zhuān)用集群。

·為每款應(yīng)用程序建立工作負(fù)載概況。

Amazon Redshift集群大小調(diào)整指南

Amazon Redshift節(jié)點(diǎn)類(lèi)型將直接決定節(jié)點(diǎn)中配備的CPU、內(nèi)存、存儲(chǔ)容量以及存儲(chǔ)驅(qū)動(dòng)器類(lèi)型。RA3節(jié)點(diǎn)類(lèi)型允許您獨(dú)立擴(kuò)展計(jì)算與存儲(chǔ)資源，大家也需要為實(shí)際使用的計(jì)算量與Amazon Redshift托管存儲(chǔ)（RMS）單獨(dú)付費(fèi)。DS2節(jié)點(diǎn)類(lèi)型則經(jīng)過(guò)優(yōu)化，能夠存儲(chǔ)大量數(shù)據(jù)并使用磁盤(pán)驅(qū)動(dòng)器（HDD）存儲(chǔ)形式。如果您目前正在使用DS2節(jié)點(diǎn)，請(qǐng)考慮升級(jí)至RA3集群，從而以相同的成本獲得2倍的性能與存儲(chǔ)資源。密集型計(jì)算（DC）節(jié)點(diǎn)類(lèi)型則針對(duì)計(jì)算類(lèi)工作負(fù)載進(jìn)行優(yōu)化。由于DC2節(jié)點(diǎn)類(lèi)型使用固態(tài)存儲(chǔ)（SSD）驅(qū)動(dòng)器，因此相當(dāng)于對(duì)性能密集型工作負(fù)載進(jìn)行了優(yōu)化。

各Amazon Redshift節(jié)點(diǎn)類(lèi)型還提供不同的節(jié)點(diǎn)大小選項(xiàng)。節(jié)點(diǎn)大小與節(jié)點(diǎn)數(shù)量決定了集群中的總體存儲(chǔ)容量。我們建議：1）如果壓縮后的數(shù)據(jù)大小小于1 TB，則應(yīng)選擇DC2節(jié)點(diǎn)類(lèi)型；2）如果壓縮后的數(shù)據(jù)大小超過(guò)1 TB，請(qǐng)選擇RA3節(jié)點(diǎn)類(lèi)型（RA3.4xlarge或者RA3.16xlarge）。

您在節(jié)點(diǎn)類(lèi)型的選擇當(dāng)中，應(yīng)考慮以下幾項(xiàng)影響因素：

·下游系統(tǒng)為了滿(mǎn)足服務(wù)水平協(xié)議（SLA）所提出的實(shí)際計(jì)算資源需求。

·您需要在數(shù)據(jù)庫(kù)中支持的查詢(xún)與并發(fā)操作復(fù)雜度。

·在實(shí)現(xiàn)工作負(fù)載最佳性能與保障預(yù)算之間做出權(quán)衡。

·您希望存儲(chǔ)在集群中的數(shù)據(jù)量。

隨著數(shù)據(jù)與性能需求的不斷變化，您還可以輕松調(diào)整集群大小，以充分利用Amazon Redshift提供的計(jì)算與存儲(chǔ)選項(xiàng)。您可以使用Elastic Resize在幾分鐘之內(nèi)實(shí)現(xiàn)對(duì)Amazon Redshift集群的規(guī)模伸縮調(diào)整，處理可預(yù)測(cè)的峰值工作負(fù)載，并通過(guò)自動(dòng)并發(fā)擴(kuò)展功能提高即席查詢(xún)工作負(fù)載的性能表現(xiàn)。

除了將傳統(tǒng)MPP數(shù)據(jù)倉(cāng)庫(kù)內(nèi)的數(shù)據(jù)遷移至Amazon Redshift托管存儲(chǔ)中之外，將這類(lèi)數(shù)據(jù)遷移至其他目的地的場(chǎng)景也相當(dāng)常見(jiàn)。您可以將冷數(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可幫助您輕松查詢(xún)并聯(lián)接各Amazon Redshift數(shù)據(jù)倉(cāng)庫(kù)與Amazon S3數(shù)據(jù)湖之間的數(shù)據(jù)。使用AWS Glue與AWS Lambda函數(shù)帶來(lái)的強(qiáng)大無(wú)服務(wù)器數(shù)據(jù)湖架構(gòu)以及“湖邊小屋”架構(gòu)功能，您可以進(jìn)一步簡(jiǎn)化ETL數(shù)據(jù)管道并將Amazon S3數(shù)據(jù)湖中的數(shù)據(jù)與云端數(shù)據(jù)倉(cāng)庫(kù)相結(jié)合，最大限度減少需要加載至Amazon Redshift的數(shù)據(jù)量。

總結(jié)

本文演示了如何為復(fù)雜項(xiàng)目開(kāi)發(fā)出基于波次的完整應(yīng)用程序遷移方法，使用Amazon Redshift實(shí)現(xiàn)傳統(tǒng)MPP數(shù)據(jù)倉(cāng)庫(kù)的現(xiàn)代化轉(zhuǎn)型。此外，本文還立足業(yè)務(wù)優(yōu)先級(jí)、數(shù)據(jù)依賴(lài)關(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為本文撰寫(xiě)提供的寶貴反饋與建議。

Original URL:https://aws.amazon.com/cn/blogs/big-data/develop-an-application-migration-methodology-to-modernize-your-data-warehouse-with-amazon-redshift/