五个顶级的大数据架构
|
副标题[/!--empirenews.page--]
自从像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)。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
