五個頂級的大數據架構

 

本文將介紹用於大數據堆棧的五個最有用的架構，以及每一個架構的優勢，以便更好地理解和權衡。此外，還對成本、什麼時候使用、熱門產品，以及每種架構的提示和技巧進行了闡述。

自從像AWS這樣的公共雲產品開闢了大數據分析功能以來，小企業經過挖掘大量的數據作到只有大企業才能作到的事情，至今大約有10年時間。這些事情其中包括網絡日誌、客戶購買記錄等，並經過按使需付費的方式提供低成本的商品集羣。在這十年中，這些產品蓬勃發展，涵蓋了從實時(亞秒級延遲)流媒體式分析到用於分析批量模式工做的企業數據倉庫，而企業數據倉庫則可能須要數天或數週才能完成。

如下將介紹用於大數據堆棧的五個最有用的架構，以及每一個架構的優勢，以便更好地理解和權衡。此外，還對成本(按$ - $$$$$的規模)、什麼時候使用、熱門產品，以及每種架構的提示和技巧進行了闡述。若是你想了解大數據的學習路線，想學習大數據知識以及須要免費的學習資料能夠加羣：784789432.歡迎你的加入。天天下午三點開直播分享基礎知識，晚上20:00都會開直播給你們分享大數據項目實戰。

五個大數據架構

在此並無什麼特別的順序，用戶在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)同樣發揮做用。

具備執行TMTOWTDI的能力是一件好事，AWS公司努力提供最適合用戶需求的服務。若是用戶從頭開始，在AWS認證的全球知識培訓課程中花費三天時間將能夠提供知足其需求的服務，並讓用戶儘快開始運營，而且順利實施。