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