伴隨技術(shù)的不斷發(fā)展，數(shù)據(jù)分析工具已經(jīng)從簡單的決策支持系統(tǒng)逐漸進(jìn)化為更加現(xiàn)代化的云數(shù)據(jù)服務(wù)。作為云時代的巨頭，亞馬遜也提供了兩個基于云計算的數(shù)據(jù)倉庫服務(wù)：Amazon Redshift和Amazon Relational Database Service（RDS）。
盡管Amazon Redshift和RDS都是面向分析的云服務(wù)，但它們的應(yīng)用場景存在一定的差異。在采用這兩項(xiàng)服務(wù)之前，你首先需要弄清楚幾個問題：
一問：你能否像Amazon Redshift一樣把數(shù)據(jù)加載進(jìn)來？
如果你的企業(yè)已經(jīng)部署了數(shù)據(jù)倉庫或數(shù)據(jù)集市系統(tǒng)，那么你肯定花了很多時間和精力開發(fā)定制化的ETL腳本來加載數(shù)據(jù)。如果你想要使用Redshift服務(wù)，那么就必須修改腳本代碼來適應(yīng)Redshift的數(shù)據(jù)加載方式。
將數(shù)據(jù)加載到Redshift的最佳方式是通過一個遠(yuǎn)程主機(jī)，Simple Storage Service（S3）服務(wù)或使用COPY命令的AWS Elastic MapReduce。COPY命令是采用并行的方式來執(zhí)行數(shù)據(jù)加載任務(wù)的，它還可以在加載的過程中對數(shù)據(jù)進(jìn)行壓縮。
如果你的ETL腳本中嵌入了比較復(fù)雜的業(yè)務(wù)邏輯，那么你可以將最終的輸出重新定向到一個本地文件或S3，然后使用COPY命令來進(jìn)行加載。
Redshift可能還需要對你的ETL流程進(jìn)行修改，但如果ETL腳本可以重復(fù)利用，只要把修改后的業(yè)務(wù)邏輯套入的話，那么使用Redshift就不存在任何問題，而且它特別適用于數(shù)據(jù)量比較大的系統(tǒng)。
二問：你是否愿意改用基于PostgreSQL的數(shù)據(jù)庫？
RDS支持多個類型的數(shù)據(jù)庫，包括MySQL、Oracle、SQL Server和PostgreSQL。如果你的分析數(shù)據(jù)庫使用了一些特定功能，比如Oracle文本查詢，那么你就需要慎重考慮是否采用新的服務(wù)了。因?yàn)槟阈枰烟囟ǖ奈谋舅阉鞔a進(jìn)行修改，從而能夠調(diào)用Amazon CloudSearch服務(wù)。而且除了Redshift之外，你還需要對CloudSearch進(jìn)行配置與維護(hù)。
這時，你可以通過Amazon RDS來繼續(xù)使用之前已經(jīng)部署的關(guān)系型數(shù)據(jù)庫和與之相關(guān)的特定功能。
除了像搜索這樣的高級服務(wù)之外，你還可以使用與索引和強(qiáng)制約束這樣更細(xì)粒度的功能。Redshift使用UTF-8字符，而新版本的SQL Server支持UTF-16，這意味著將數(shù)據(jù)映射到UTF-8會存在一定的挑戰(zhàn)，這個過程中可能會存在一些你意想不到的陷阱。
如果你對使用基于PostgreSQL這樣的數(shù)據(jù)庫沒有什么特殊需求的話，那么Redshift的優(yōu)勢就能夠體現(xiàn)出來了，它將成為你的最佳云數(shù)據(jù)倉庫。
三問：你的數(shù)據(jù)倉庫是否需要擴(kuò)展性和高可用性？
關(guān)系型數(shù)據(jù)庫的擴(kuò)展是一項(xiàng)非?？简?yàn)DBA能力的工作。你可以在大型服務(wù)器上部署亞馬遜數(shù)據(jù)倉庫然后進(jìn)行縱向的擴(kuò)展，直到它無法滿足你的性能需求。記住，縱向擴(kuò)展并不會增加可用性，單點(diǎn)故障的隱患將一直存在。
如果你已經(jīng)精通熱備份維護(hù)以及采用讀復(fù)制集來改善查詢性能的話，那么一個可擴(kuò)展的RDS對于你來說就不算什么了。如果不熟悉這些工作的話，那么除了維護(hù)RDS之外，你還需要額外進(jìn)行高可用性和擴(kuò)展性的維護(hù)。
AmazonRedshift采用服務(wù)器集群的部署方式，它的擴(kuò)展更加容易。通過向Redshift集群添加節(jié)點(diǎn)，它可以提供線性或接近線性的性能提升。也就是說如果你在雙節(jié)點(diǎn)的基礎(chǔ)上再添加兩個節(jié)點(diǎn)，那么它的性能也將提升兩倍。在節(jié)點(diǎn)發(fā)生故障的時候，Redshift還會負(fù)責(zé)恢復(fù)的工作。發(fā)生故障的節(jié)點(diǎn)將被新的節(jié)點(diǎn)取代，而數(shù)據(jù)則可以從S3中自動進(jìn)行恢復(fù)。
如果擴(kuò)展性和可用性對于你的企業(yè)至關(guān)重要的話，那么Redshift無疑會是更好的選擇。
四問：你的應(yīng)用是否需要強(qiáng)制進(jìn)行完整性約束？
你很難想象一個關(guān)系型數(shù)據(jù)庫管理系統(tǒng)會不要求完整性約束，但Redshift就沒有。這主要是出于性能方面的考慮。在寫入操作完成之前，如果對每個節(jié)點(diǎn)進(jìn)行查詢?nèi)缓蟮却答佉员氵M(jìn)行完整性約束話，那么系統(tǒng)的延時問題就一定會出現(xiàn)。
這使得加載程序需要進(jìn)行主鍵、外鍵以及唯一鍵約束的檢查。如果你的應(yīng)用必須要進(jìn)行完整性約束，那么RDS服務(wù)將會是更好的選擇。
另一方面，Redshift更多的是一款云數(shù)據(jù)倉庫。如果你可以接受Redshift的約束性特質(zhì)，那么它會是不錯的選擇。特別是在數(shù)據(jù)量比較大的情況下，Redshift幾乎可以說是你唯一的選擇。而RDS對于小一些的數(shù)據(jù)集市部署更加適合。
京公網(wǎng)安備 11010502049343號