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

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

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

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

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

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

基于消費的遷移方法

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

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

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

·應(yīng)用程序——一種分析方法，通過消費一個或者多個主題域為客戶提供價值。

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

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

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

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

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

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

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

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

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

遷移波次與對象域集成

下表所示，為以上親和度圖的分波次遷移方案（階梯步進）。在每個波次中（可能包含一個或者多個應(yīng)用程序或分析）總是存在新的主題域（綠色框體）以及在先前波次中已經(jīng)遷移完成的主題域（藍色框體）?；诓ù蔚淖罴堰w移方法，在于將遷移波次的設(shè)計中保證每個后續(xù)波次中包含的新build越來越少。在以下示例中，隨著最初幾個波次的完成，我們需要集成至后續(xù)波次中的新主題域越來越少——也正因為如此，我們才建議從親和度表的中間位置向左移動。最終，這種方式能夠加快遷移項目的整體執(zhí)行速度。

圖三：階梯步進模式與對象域集成。

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

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

其他所有應(yīng)用程序（分析）將進行自動處理，因為它們所依賴的主題域已經(jīng)在上述各波次中構(gòu)建完成。

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

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

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

·工作負載概況——工作負載主要屬于ETL（寫入密集型）還是查詢（只讀?。?。

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

·應(yīng)用程序SLA——各應(yīng)用程序為最終用戶做出的性能承諾指標。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

隨著數(shù)據(jù)與性能需求的不斷變化，您還可以輕松調(diào)整集群大小，以充分利用Amazon Redshift提供的計算與存儲選項。您可以使用Elastic Resize在幾分鐘之內(nèi)實現(xiàn)對Amazon Redshift集群的規(guī)模伸縮調(diào)整，處理可預(yù)測的峰值工作負載，并通過自動并發(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é)約成本，也可以將溫數(shù)據(jù)或熱數(shù)據(jù)發(fā)送至Amazon Redshift集群以實現(xiàn)最佳性能。Amazon Redshift Spectrum可幫助您輕松查詢并聯(lián)接各Amazon Redshift數(shù)據(jù)倉庫與Amazon S3數(shù)據(jù)湖之間的數(shù)據(jù)。使用AWS Glue與AWS Lambda函數(shù)帶來的強大無服務(wù)器數(shù)據(jù)湖架構(gòu)以及“湖邊小屋”架構(gòu)功能，您可以進一步簡化ETL數(shù)據(jù)管道并將Amazon S3數(shù)據(jù)湖中的數(shù)據(jù)與云端數(shù)據(jù)倉庫相結(jié)合，最大限度減少需要加載至Amazon Redshift的數(shù)據(jù)量。

總結(jié)

本文演示了如何為復(fù)雜項目開發(fā)出基于波次的完整應(yīng)用程序遷移方法，使用Amazon Redshift實現(xiàn)傳統(tǒng)MPP數(shù)據(jù)倉庫的現(xiàn)代化轉(zhuǎn)型。此外，本文還立足業(yè)務(wù)優(yōu)先級、數(shù)據(jù)依賴關(guān)系、工作負載概況以及現(xiàn)有服務(wù)水平協(xié)議（SLA）等多個層面分享了最佳實踐與經(jīng)驗心得。

這里要感謝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/