自從像AWS這樣的公共云產(chǎn)品開(kāi)辟了大數(shù)據(jù)分析功能以來(lái)，小企業(yè)通過(guò)挖掘大量的數(shù)據(jù)做到只有大企業(yè)才能做到的事情，至今大約有10年時(shí)間。這些事情其中包括網(wǎng)絡(luò)日志、客戶(hù)購(gòu)買(mǎi)記錄等，并通過(guò)按使需付費(fèi)的方式提供低成本的商品集群。在這十年中，這些產(chǎn)品蓬勃發(fā)展，涵蓋了從實(shí)時(shí)(亞秒級(jí)延遲)流媒體式分析到用于分析批量模式工作的企業(yè)數(shù)據(jù)倉(cāng)庫(kù)，而企業(yè)數(shù)據(jù)倉(cāng)庫(kù)則可能需要數(shù)天或數(shù)周才能完成。

以下將介紹用于大數(shù)據(jù)堆棧的五個(gè)最有用的架構(gòu)，以及每個(gè)架構(gòu)的優(yōu)點(diǎn)，以便更好地理解和權(quán)衡。此外，還對(duì)成本(按$ - $$$$$的規(guī)模)、何時(shí)使用、熱門(mén)產(chǎn)品，以及每種架構(gòu)的提示和技巧進(jìn)行了闡述。

五個(gè)大數(shù)據(jù)架構(gòu)

在此并沒(méi)有什么特別的順序，用戶(hù)在AWS公共云旅程中可能遇到的五個(gè)***大數(shù)據(jù)架構(gòu)是：

• 流媒體- 允許攝取(并可能分析)任務(wù)關(guān)鍵型實(shí)時(shí)數(shù)據(jù)，這些數(shù)據(jù)可能會(huì)以爆發(fā)的形式出現(xiàn)在用戶(hù)面前。
• 通用(或特定)的批處理集群—在可擴(kuò)展、經(jīng)濟(jì)高效的集群中提供通用存儲(chǔ)和計(jì)算功能，可以執(zhí)行其他四種架構(gòu)的任何和所有功能。
• NoSQL引擎 - 使架構(gòu)師能夠處理“3V” —高速度、高容量，以及底層數(shù)據(jù)的多樣性/可變性。
• 企業(yè)數(shù)據(jù)倉(cāng)庫(kù)(EDW) - 允許組織為多年的歷史數(shù)據(jù)維護(hù)一個(gè)單獨(dú)的數(shù)據(jù)庫(kù)，并對(duì)該數(shù)據(jù)運(yùn)行各種長(zhǎng)期運(yùn)行的分析。
• 就地分析 - 允許用戶(hù)將數(shù)據(jù)“就地”保存在低成本存儲(chǔ)引擎中，并針對(duì)該數(shù)據(jù)運(yùn)行高性能的即席查詢(xún)，而無(wú)需創(chuàng)建單獨(dú)的、昂貴的“集群”。

1. 流媒體

流媒體解決方案由以下多個(gè)因素定義：

• 關(guān)鍵任務(wù)數(shù)據(jù)—即使丟失一筆交易也會(huì)給用戶(hù)帶來(lái)災(zāi)難性的后果。
• 負(fù)載中的爆發(fā)尖峰——物聯(lián)網(wǎng)的基礎(chǔ)設(shè)施可能會(huì)從完全無(wú)聲的狀態(tài)轉(zhuǎn)變?yōu)橥瑫r(shí)與其通話(huà)設(shè)備中的一個(gè)。
• 實(shí)時(shí)響應(yīng) - 高延遲響應(yīng)對(duì)用戶(hù)來(lái)說(shuō)可能是災(zāi)難性的。

這里有很多現(xiàn)實(shí)世界的例子，從特斯拉公司的電動(dòng)汽車(chē)(基本上是移動(dòng)的4G設(shè)備)不斷將汽車(chē)的位置發(fā)送到數(shù)據(jù)中心，通知司機(jī)下一個(gè)充電站在哪里。此外，人們喜歡的日本一家高度自動(dòng)化的壽司專(zhuān)營(yíng)店：Sushiro。Sushiro所做的是將RFID傳感器放在每個(gè)壽司盤(pán)底，然后，壽司傳送帶上的傳感器跟蹤每個(gè)盤(pán)子的動(dòng)態(tài)，將數(shù)據(jù)點(diǎn)發(fā)送到AWS Kinesis，其后端響應(yīng)儀表板的更新，通知壽司廚師，例如“丟掉即將過(guò)期變質(zhì)的食物，或者制作更多的雞蛋壽司，或者解凍更多的金槍魚(yú)”，通過(guò)使用流媒體技術(shù)，該連鎖店不僅有上述的實(shí)時(shí)效率推薦，而且還可以獲得每家餐廳的歷史信息，并且可以了解顧客購(gòu)買(mǎi)的趨勢(shì)。

Sushiro是一個(gè)很好的例子，因?yàn)樗狭髅襟w的所有三個(gè)要求。其儀表板現(xiàn)在對(duì)業(yè)務(wù)運(yùn)營(yíng)至關(guān)重要。

• 成本：$$ - $$$$$(通常為RAM密集型)
• 適用性：任務(wù)關(guān)鍵型數(shù)據(jù)，負(fù)載爆發(fā)尖峰，實(shí)時(shí)響應(yīng)。用戶(hù)需要構(gòu)建KPI的實(shí)時(shí)儀表板。
• 注意事項(xiàng)：獨(dú)立的流媒體解決方案的構(gòu)建和維護(hù)成本很高。擴(kuò)展可能具有挑戰(zhàn)性，特別是如果在EC2上構(gòu)建。失敗對(duì)企業(yè)來(lái)說(shuō)可能是災(zāi)難性的，但大多數(shù)產(chǎn)品都提供故障保護(hù)，例如復(fù)制優(yōu)化、備份和災(zāi)難恢復(fù)，以避免這種情況。
• 受歡迎的產(chǎn)品：Kinesis(托管服務(wù))，Kafka(基于EC2)，Spark Streaming(作為托管服務(wù)和基于EC2)和Storm。
• 提示和技巧：使用Kinesis作為初學(xué)者(易于使用、體積小、成本低)。許多組織轉(zhuǎn)向基于EC2的Kafka(如果他們只需要流媒體)或Spark Streaming，以獲得更好的控制，并降低大批量成本。這是AWS中為數(shù)不多的幾次托管任務(wù)，像Kinesis這樣的托管服務(wù)最終會(huì)比基于EC2的Kafka解決方案花費(fèi)更多的費(fèi)用。

2. 通用(或特定)的批處理集群

使用Hadoop/Spark這些系統(tǒng)，用戶(hù)可以獲得高度可擴(kuò)展、低成本(商用硬件和開(kāi)源軟件)存儲(chǔ)和計(jì)算，這些存儲(chǔ)和計(jì)算可能會(huì)遇到大量問(wèn)題，從而以盡可能低的成本對(duì)數(shù)據(jù)進(jìn)行批量分析。

Hadoop技術(shù)非常成熟，提供了一個(gè)非常豐富的軟件生態(tài)系統(tǒng)，可以利用這些通用計(jì)算和存儲(chǔ)資源提供從數(shù)據(jù)倉(cāng)庫(kù)到流媒體，甚至NoSQL的所有內(nèi)容。

在Hadoop之上，現(xiàn)在可以運(yùn)行Spark，它帶有自己的可擴(kuò)展框架，以低延遲(高內(nèi)存)方式提供上述所有功能，甚至適用于流媒體和NoSQL。

• 成本：$ - $$$$(高度依賴(lài)于內(nèi)存需求)
• 適用性：***成本、***靈活性。如果希望采用一個(gè)集群完成所有任務(wù)，并從Hadoop或Spark內(nèi)部部署轉(zhuǎn)移，那么這是一個(gè)不錯(cuò)的選擇，非常適合機(jī)器學(xué)習(xí)。
• 注意事項(xiàng)：一個(gè)全能的系統(tǒng)很少把每件事都做好，但這可以通過(guò)使用Spark和為每個(gè)工作量身定制的集群來(lái)大大減輕工作負(fù)荷。
• 熱門(mén)產(chǎn)品：EMR(托管服務(wù)，也將運(yùn)行Spark)，Cloudera(基于EC2)，Hortonworks(通過(guò)EMR作為托管服務(wù)，基于EC2)。
• 提示和技巧：在S3存儲(chǔ)桶中長(zhǎng)期存儲(chǔ)源數(shù)據(jù)，構(gòu)建集群，并根據(jù)需要將數(shù)據(jù)加載到集群中，然后在分析任務(wù)完成后立即關(guān)閉所有數(shù)據(jù)。這實(shí)際上正是默認(rèn)情況下EMR的工作原理，但即使使用的是Cloudera或Hortonworks(現(xiàn)在功能幾乎相同)，也可以輕松編寫(xiě)上述所有內(nèi)容。利用EC2現(xiàn)場(chǎng)實(shí)例可以節(jié)省80%-90%的成本，并檢查自己的分析，以便可以向上或向下旋轉(zhuǎn)集群。以利用成本***的spot窗口。

3. NoSQL引擎

Velocity(并發(fā)事務(wù))在這里特別重要，這些引擎被設(shè)計(jì)為處理任意數(shù)量的并發(fā)讀寫(xiě)。雖然其他系統(tǒng)通常不能用于最終用戶(hù)(需要低延遲響應(yīng))和員工分析團(tuán)隊(duì)(可能會(huì)使用長(zhǎng)時(shí)間運(yùn)行的查詢(xún)鎖定多個(gè)表)，同時(shí)，NoSQL引擎可以擴(kuò)展以適應(yīng)一個(gè)系統(tǒng)的兩個(gè)主服務(wù)器。一些開(kāi)發(fā)允許以低延遲方式實(shí)時(shí)加入和查詢(xún)?cè)摂?shù)據(jù)。

• 成本：$$ - $$$(通常為內(nèi)存密集型)
• 適用性：“3V”問(wèn)題。簡(jiǎn)單和/或快速變化的數(shù)據(jù)模型。需要構(gòu)建KPI的實(shí)時(shí)儀表板。
• 警告：必須放棄交易和豐富多樣的SQL。由于它不使用SQL，因此無(wú)法使用Tableau和Microstrategy等可視化工具直接查詢(xún)數(shù)據(jù)。擴(kuò)展(尤其是添加新節(jié)點(diǎn)和重新平衡)可能很困難，并且會(huì)影響用戶(hù)延遲和系統(tǒng)可用性。
• 受歡迎的產(chǎn)品：DynamoDB(托管服務(wù))，Neptune(托管服務(wù)，目前仍處于測(cè)試階段)，Cassandra(基于EC2)，CouchDB(基于EC2)和HBase(通過(guò)EMR作為托管服務(wù)，基于EC2)。
• 提示和技巧：努力采用AWS管理的服務(wù)DynamoDB，而不是配置EC2并加載第三方系統(tǒng)。定期修剪最終用戶(hù)DynamoDB表，并在這些歷史表上創(chuàng)建每周或每月的表。使用Dynamic DynamoDB“自動(dòng)調(diào)整”配置的容量，使其始終滿(mǎn)足消耗。使用DynamoDB Streams可以對(duì)客戶(hù)服務(wù)取消等關(guān)鍵事件進(jìn)行實(shí)時(shí)響應(yīng)，或者在第二個(gè)區(qū)域提供備份。

4. 企業(yè)數(shù)據(jù)倉(cāng)庫(kù)(EDW)

企業(yè)數(shù)據(jù)倉(cāng)庫(kù)(EDW)與此處提到的其他系統(tǒng)截然不同。它提供了人們稱(chēng)之為“OLAP”(在線分析處理，可以支持來(lái)自?xún)?nèi)部用戶(hù)的一些長(zhǎng)時(shí)間運(yùn)行的查詢(xún))與“OLTP”(在線事務(wù)處理，可以支持來(lái)自最終用戶(hù)的大量讀取和寫(xiě)入)功能，如Oracle的RDBMS或MySQL。當(dāng)然，可以使用OLTP系統(tǒng)作為企業(yè)數(shù)據(jù)倉(cāng)庫(kù)(EDW)，但是大多數(shù)人都將OLTP數(shù)據(jù)庫(kù)集中在最近用戶(hù)的低延遲，最近事件(如“跟蹤上周的訂單”)需求和定期(通常是每天)窗口更舊數(shù)據(jù)輸出到OLAP系統(tǒng)，業(yè)務(wù)用戶(hù)可以在數(shù)月或數(shù)年的數(shù)據(jù)中運(yùn)行長(zhǎng)時(shí)間的查詢(xún)。

這些OLAP系統(tǒng)使用諸如列式存儲(chǔ)、數(shù)據(jù)非規(guī)范化(創(chuàng)建具有幾乎***維度的“數(shù)據(jù)立方體”)等策略，并提供RDBMS級(jí)ANSI 92 SQL依從性，這意味著可以完全訪問(wèn)SQL功能，并且可以定制Tableau等可視化工具直接與他們合作。

• 成本：$$ - $$$$$(通常需要大量節(jié)點(diǎn)來(lái)存儲(chǔ)和處理大量數(shù)據(jù))。
• 適用性：如果希望專(zhuān)門(mén)針對(duì)業(yè)務(wù)價(jià)值分析數(shù)據(jù)或構(gòu)建KPI的實(shí)時(shí)儀表板。
• 警告：確保團(tuán)隊(duì)了解OLAP和OLTP之間的區(qū)別，并確保他們以正確的方式使用每個(gè)OLAP和OLTP。
• 提示和技巧：與EMR/Hadoop一樣，只在需要時(shí)啟動(dòng)集群，將源數(shù)據(jù)保存在S3存儲(chǔ)桶中(這實(shí)際上是Redshift默認(rèn)工作的方式)。標(biāo)記集群，以便用能夠以自動(dòng)方式快速識(shí)別和關(guān)閉未使用的容量。考慮保留以控制成本。真正了解可用的不同節(jié)點(diǎn)類(lèi)型(高存儲(chǔ)、高吞吐量)以便利用每個(gè)節(jié)點(diǎn)類(lèi)型。采用本機(jī)加密，因?yàn)樗梢詫⑿阅芙档投噙_(dá)20%-25%。通過(guò)O'Reilly課程深入了解Redshift，或考慮通過(guò)出色的“數(shù)據(jù)倉(cāng)庫(kù)”課程進(jìn)行面對(duì)面培訓(xùn)，該課程幾乎完全涵蓋Redshift。

5. 就地分析

幾年前，Presto通過(guò)提供高性能的數(shù)據(jù)分析改變了游戲規(guī)則，而無(wú)需將數(shù)據(jù)從原生的、低成本的長(zhǎng)期存儲(chǔ)中移出。其最終結(jié)果是，可以簡(jiǎn)單地運(yùn)行查詢(xún)，而不是必須為昂貴的EMR或Redshift集群支付全部費(fèi)用。而是只按使用的內(nèi)容收費(fèi)。

此外，人們需要很多時(shí)間來(lái)嘗試選擇(然后管理)EMR或Redshift集群的正確節(jié)點(diǎn)和節(jié)點(diǎn)數(shù)。采用Presto，人們不再知道也不關(guān)心這種差別，而這一切都在用戶(hù)需要的時(shí)候起到作用。

***，Presto支持RDBMS級(jí)別的ANSI-92 SQL兼容性，這意味著所有可視化工具都可以直接使用它，具有的SQL背景可以在ad-hoc查詢(xún)中全面使用。

• 費(fèi)用：$ - $$
• 適用性：成本極低。沒(méi)有任何管理。可以作為低成本、中等性能的企業(yè)數(shù)據(jù)倉(cāng)庫(kù)(EDW)。它不需要將數(shù)據(jù)復(fù)制到第二個(gè)系統(tǒng)。大型連接和復(fù)雜分析效果很好。
• 警告：需要***延遲。為了獲得不錯(cuò)的性能，可能會(huì)使用序列化格式Parquet、壓縮、重新分區(qū)等重新格式化存儲(chǔ)的數(shù)據(jù)。可能需要多輪查詢(xún)調(diào)整和/或重新格式化才能獲得正確的結(jié)果。目前不支持UDF或事務(wù)。
• 熱門(mén)產(chǎn)品：AWS Athena(用于查詢(xún)S3數(shù)據(jù)的托管服務(wù))，EMR(托管服務(wù)-可以自動(dòng)安裝Presto)，自我管理的Presto(基于EC2–用戶(hù)永遠(yuǎn)不想在AWS中執(zhí)行此操作)。
• 提示和技巧：只需使用Athena。利用AWS Glue構(gòu)建ETL管道，以獲取原始數(shù)據(jù)，并將其重新格式化為S3或Athena可以更有效地使用的內(nèi)容。使用S3生命周期策略將原有的數(shù)據(jù)移動(dòng)到低成本的歸檔存儲(chǔ)(如Glacier)。

把它們放在一起

通過(guò)了解將在公共云中運(yùn)行的五個(gè)***大數(shù)據(jù)架構(gòu)，用戶(hù)現(xiàn)在可以獲得有關(guān)***應(yīng)用位置的可操作信息，以及潛伏的位置。

一旦用戶(hù)開(kāi)始在AWS公共云中構(gòu)建大數(shù)據(jù)架構(gòu)，將很快了解到更多的架構(gòu)，并且在很多情況下，企業(yè)可能會(huì)最終同時(shí)使用上述所有內(nèi)容，可能使用Kinesis將客戶(hù)數(shù)據(jù)流媒體傳輸?shù)紻ynamoDB和S3。用戶(hù)可能偶爾會(huì)在該源數(shù)據(jù)上啟動(dòng)EMR(進(jìn)行某些機(jī)器學(xué)習(xí))或Redshift(分析KPI)集群，或者可以選擇以可以通過(guò)AWS Athena就地訪問(wèn)的方式格式化數(shù)據(jù)，讓它像企業(yè)數(shù)據(jù)倉(cāng)庫(kù)(EDW)一樣發(fā)揮作用。

具有執(zhí)行TMTOWTDI的能力是一件好事，AWS公司努力提供最適合用戶(hù)需求的服務(wù)。如果用戶(hù)從頭開(kāi)始，在AWS認(rèn)證的全球知識(shí)培訓(xùn)課程中花費(fèi)三天時(shí)間將可以提供滿(mǎn)足其需求的服務(wù)，并讓用戶(hù)盡快開(kāi)始運(yùn)營(yíng)，并且順利實(shí)施。