自从像AWS这样的公共云产品开辟了大数据分析功能以来，小企业通过挖掘大量的数据做到只有大企业才能做到的事情，至今大约有10年时间。这些事情其中包括网络日志、客户购买记录等，并通过按使需付费的方式提供低成本的商品集群。在这十年中，这些产品蓬勃发展，涵盖了从实时(亚秒级延迟)流媒体式分析到用于分析批量模式工作的企业数据仓库，而企业数据仓库则可能需要数天或数周才能完成。
以下将介绍用于大数据堆栈的五个最有用的架构，以及每个架构的优点，以便更好地理解和权衡。此外，还对成本(按$ - $$$$$的规模)、何时使用、热门产品，以及每种架构的提示和技巧进行了阐述。
五个大数据架构
在此并没有什么特别的顺序，用户在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认证的全球知识培训课程中花费三天时间将可以提供满足其需求的服务，并让用户尽快开始运营，并且顺利实施。
