自從像AWS這樣的公共雲產品開闢了大資料分析功能以來，小企業通過挖掘大量的資料做到只有大企業才能做到的事情，至今大約有10年時間。這些事情其中包括網路日誌、客戶購買記錄等，並通過按使需付費的方式提供低成本的商品叢集。

自從像AWS這樣的公共雲產品開闢了大資料分析功能以來，小企業通過挖掘大量的資料做到只有大企業才能做到的事情，至今大約有10年時間。這些事情其中包括網路日誌、客戶購買記錄等，並通過按使需付費的方式提供低成本的商品叢集。在這十年中，這些產品蓬勃發展，涵蓋了從實時(亞秒級延遲)流媒體式分析到用於分析批量模式工作的企業資料倉庫，而企業資料倉庫則可能需要數天或數週才能完成。很多初學者，對大資料的概念都是模糊不清的，大資料是什麼，能做什麼，學的時候，該按照什麼線路去學習，學完往哪方面發展，想深入瞭解，想學習的同學歡迎加入大資料學習qq群：458345782，有大量乾貨（零基礎以及進階的經典實戰）分享給大家，並且有清華大學畢業的資深大資料講師給大家免費授課，給大家分享目前國內最完整的大資料高階實戰實用學習流程體系。

以下將介紹用於大資料堆疊的五個最有用的架構，以及每個架構的優點，以便更好地理解和權衡。此外，還對成本(按$ - $$$$$的規模)、何時使用、熱門產品，以及每種架構的提示和技巧進行了闡述。

|| 五個大資料架構

在此並沒有什麼特別的順序，使用者在AWS公共雲旅程中可能遇到的五個頂級大資料架構是：

•流媒體- 允許攝取(並可能分析)任務關鍵型實時資料，這些資料可能會以爆發的形式出現在使用者面前。

•通用(或特定)的批處理叢集—在可擴充套件、經濟高效的叢集中提供通用儲存和計算功能，可以執行其他四種架構的任何和所有功能。

•NoSQL引擎 - 使架構師能夠處理“3V” —高速度、高容量，以及底層資料的多樣性/可變性。

•企業資料倉庫(EDW) - 允許組織為多年的歷史資料維護一個單獨的資料庫，並對該資料執行各種長期執行的分析。

•就地分析 - 允許使用者將資料“就地”儲存在低成本儲存引擎中，並針對該資料執行高效能的即席查詢，而無需建立單獨的、昂貴的“叢集”。

(1)流媒體

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

•關鍵任務資料—即使丟失一筆交易也會給使用者帶來災難性的後果。

•負載中的爆發尖峰——物聯網的基礎設施可能會從完全無聲的狀態轉變為同時與其通話裝置中的一個。

•實時響應 - 高延遲響應對使用者來說可能是災難性的。

這裡有很多現實世界的例子，從特斯拉公司的電動汽車(基本上是移動的4G裝置)不斷將汽車的位置傳送到資料中心，通知司機下一個充電站在哪裡。此外，人們喜歡的日本一家高度自動化的壽司專營店：Sushiro。Sushiro所做的是將RFID感測器放在每個壽司盤底，然後，壽司傳送帶上的感測器跟蹤每個盤子的動態，將資料點發送到AWS Kinesis，其後端響應儀表板的更新，通知壽司廚師，例如“丟掉即將過期變質的食物，或者製作更多的雞蛋壽司，或者解凍更多的金槍魚”，通過使用流媒體技術，該連鎖店不僅有上述的實時效率推薦，而且還可以獲得每家餐廳的歷史資訊，並且可以瞭解顧客購買的趨勢。

Sushiro是一個很好的例子，因為它符合流媒體的所有三個要求。其儀表板現在對業務運營至關重要。

•成本：$$ - $$$$$(通常為RAM密集型)

•適用性：任務關鍵型資料，負載爆發尖峰，實時響應。使用者需要構建KPI的實時儀表板。

•注意事項：獨立的流媒體解決方案的構建和維護成本很高。擴充套件可能具有挑戰性，特別是如果在EC2上構建。失敗對企業來說可能是災難性的，但大多數產品都提供故障保護，例如複製優化、備份和災難恢復，以避免這種情況。

•受歡迎的產品：Kinesis(託管服務)，Kafka(基於EC2)，Spark Streaming(作為託管服務和基於EC2)和Storm。

•提示和技巧：使用Kinesis作為初學者(易於使用、體積小、成本低)。許多組織轉向基於EC2的Kafka(如果他們只需要流媒體)或Spark Streaming，以獲得更好的控制，並降低大批量成本。這是AWS中為數不多的幾次託管任務，像Kinesis這樣的託管服務最終會比基於EC2的Kafka解決方案花費更多的費用。

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

使用Hadoop/Spark這些系統，使用者可以獲得高度可擴充套件、低成本(商用硬體和開源軟體)儲存和計算，這些儲存和計算可能會遇到大量問題，從而以儘可能低的成本對資料進行批量分析。

Hadoop技術非常成熟，提供了一個非常豐富的軟體生態系統，可以利用這些通用計算和儲存資源提供從資料倉庫到流媒體，甚至NoSQL的所有內容。

在Hadoop之上，現在可以執行Spark，它帶有自己的可擴充套件框架，以低延遲(高記憶體)方式提供上述所有功能，甚至適用於流媒體和NoSQL。

•成本：$ - $$$$(高度依賴於記憶體需求)

•適用性：最低成本、最大靈活性。如果希望採用一個叢集完成所有任務，並從Hadoop或Spark內部部署轉移，那麼這是一個不錯的選擇，非常適合機器學習。

•注意事項：一個全能的系統很少把每件事都做好，但這可以通過使用Spark和為每個工作量身定製的叢集來大大減輕工作負荷。

•熱門產品：EMR(託管服務，也將執行Spark)，Cloudera(基於EC2)，Hortonworks(通過EMR作為託管服務，基於EC2)。

•提示和技巧：在S3儲存桶中長期儲存源資料，構建叢集，並根據需要將資料載入到叢集中，然後在分析任務完成後立即關閉所有資料。這實際上正是預設情況下EMR的工作原理，但即使使用的是Cloudera或Hortonworks(現在功能幾乎相同)，也可以輕鬆編寫上述所有內容。利用EC2現場例項可以節省80%-90%的成本，並檢查自己的分析，以便可以向上或向下旋轉叢集。以利用成本最低的spot視窗。

(3)NoSQL引擎

Velocity(併發事務)在這裡特別重要，這些引擎被設計為處理任意數量的併發讀寫。雖然其他系統通常不能用於終端使用者(需要低延遲響應)和員工分析團隊(可能會使用長時間執行的查詢鎖定多個表)，同時，NoSQL引擎可以擴充套件以適應一個系統的兩個主伺服器。一些開發允許以低延遲方式實時加入和查詢該資料。

•成本：$$ - $$$(通常為記憶體密集型)

•適用性：“3V”問題。簡單和/或快速變化的資料模型。需要構建KPI的實時儀表板。

•警告：必須放棄交易和豐富多樣的SQL。由於它不使用SQL，因此無法使用Tableau和Microstrategy等視覺化工具直接查詢資料。擴充套件(尤其是新增新節點和重新平衡)可能很困難，並且會影響使用者延遲和系統可用性。

•受歡迎的產品：DynamoDB(託管服務)，Neptune(託管服務，目前仍處於測試階段)，Cassandra(基於EC2)，CouchDB(基於EC2)和HBase(通過EMR作為託管服務，基於EC2)。

•提示和技巧：努力採用AWS管理的服務DynamoDB，而不是配置EC2並載入第三方系統。定期修剪終端使用者DynamoDB表，並在這些歷史表上建立每週或每月的表。使用Dynamic DynamoDB“自動調整”配置的容量，使其始終滿足消耗。使用DynamoDB Streams可以對客戶服務取消等關鍵事件進行實時響應，或者在第二個區域提供備份。

(4)企業資料倉庫(EDW)

企業資料倉庫(EDW)與此處提到的其他系統截然不同。它提供了人們稱之為“OLAP”(線上分析處理，可以支援來自內部使用者的一些長時間執行的查詢)與“OLTP”(線上事務處理，可以支援來自終端使用者的大量讀取和寫入)功能，如Oracle的RDBMS或MySQL。當然，可以使用OLTP系統作為企業資料倉庫(EDW)，但是大多數人都將OLTP資料庫集中在最近使用者的低延遲，最近事件(如“跟蹤上週的訂單”)需求和定期(通常是每天)視窗更舊資料輸出到OLAP系統，業務使用者可以在數月或數年的資料中執行長時間的查詢。

這些OLAP系統使用諸如列式儲存、資料非規範化(建立具有幾乎無限維度的“資料立方體”)等策略，並提供RDBMS級ANSI 92 SQL依從性，這意味著可以完全訪問SQL功能，並且可以定製Tableau等視覺化工具直接與他們合作。

•成本：$$ - $$$$$(通常需要大量節點來儲存和處理大量資料)。

•適用性：如果希望專門針對業務價值分析資料或構建KPI的實時儀表板。

•警告：確保團隊瞭解OLAP和OLTP之間的區別，並確保他們以正確的方式使用每個OLAP和OLTP。

•提示和技巧：與EMR/Hadoop一樣，只在需要時啟動叢集，將源資料儲存在S3儲存桶中(這實際上是Redshift預設工作的方式)。標記叢集，以便用能夠以自動方式快速識別和關閉未使用的容量。考慮保留以控制成本。真正瞭解可用的不同節點型別(高儲存、高吞吐量)以便利用每個節點型別。採用本機加密，因為它可以將效能降低多達20%-25%。通過O'Reilly課程深入瞭解Redshift，或考慮通過出色的“資料倉庫”課程進行面對面培訓，該課程幾乎完全涵蓋Redshift。

(5)就地分析

幾年前，Presto通過提供高效能的資料分析改變了遊戲規則，而無需將資料從原生的、低成本的長期儲存中移出。其最終結果是，可以簡單地執行查詢，而不是必須為昂貴的EMR或Redshift叢集支付全部費用。而是隻按使用的內容收費。

此外，人們需要很多時間來嘗試選擇(然後管理)EMR或Redshift叢集的正確節點和節點數。採用Presto，人們不再知道也不關心這種差別，而這一切都在使用者需要的時候起到作用。

最後，Presto支援RDBMS級別的ANSI-92 SQL相容性，這意味著所有視覺化工具都可以直接使用它，具有的SQL背景可以在ad-hoc查詢中全面使用。

•費用：$ - $$

•適用性：成本極低。沒有任何管理。可以作為低成本、中等效能的企業資料倉庫(EDW)。它不需要將資料複製到第二個系統。大型連線和複雜分析效果很好。

•警告：需要最低延遲。為了獲得不錯的效能，可能會使用序列化格式Parquet、壓縮、重新分割槽等重新格式化儲存的資料。可能需要多輪查詢調整和/或重新格式化才能獲得正確的結果。目前不支援UDF或事務。

•熱門產品：AWS Athena(用於查詢S3資料的託管服務)，EMR(託管服務-可以自動安裝Presto)，自我管理的Presto(基於EC2–使用者永遠不想在AWS中執行此操作)。

•提示和技巧：只需使用Athena。利用AWS Glue構建ETL管道，以獲取原始資料，並將其重新格式化為S3或Athena可以更有效地使用的內容。使用S3生命週期策略將原有的資料移動到低成本的歸檔儲存(如Glacier)。

|| 把它們放在一起

通過了解將在公共雲中執行的五個頂級大資料架構，使用者現在可以獲得有關最佳應用位置的可操作資訊，以及潛伏的位置。

一旦使用者開始在AWS公共雲中構建大資料架構，將很快了解到更多的架構，並且在很多情況下，企業可能會最終同時使用上述所有內容，可能使用Kinesis將客戶資料流媒體傳輸到DynamoDB和S3。使用者可能偶爾會在該源資料上啟動EMR(進行某些機器學習)或Redshift(分析KPI)叢集，或者可以選擇以可以通過AWS Athena就地訪問的方式格式化資料，讓它像企業資料倉庫(EDW)一樣發揮作用。

很多初學者，對大資料的概念都是模糊不清的，大資料是什麼，能做什麼，學的時候，該按照什麼線路去學習，學完往哪方面發展，想深入瞭解，想學習的同學歡迎加入大資料學習qq群：458345782，有大量乾貨（零基礎以及進階的經典實戰）分享給大家，並且有清華大學畢業的資深大資料講師給大家免費授課，給大家分享目前國內最完整的大資料高階實戰實用學習流程體系。