设计数据密集型应用程序_架构数据密集型应用程序–第1部分

最新推荐文章于 2022-10-11 19:03:22 发布

danpu0978

最新推荐文章于 2022-10-11 19:03:22 发布

阅读量579

点赞数

文章标签：大数据编程语言 hadoop 数据库 python

原文链接：https://www.javacodegeeks.com/2015/08/architecting-data-intensive-applications-part-1.html

版权

设计数据密集型应用程序

介绍

本质上，每个软件应用程序都可以分为两种类型：计算密集型应用程序和数据密集型应用程序。然后，有一些应用程序介于这两个极端之间。

今天，我将讨论如何为专注于利用企业数据的应用程序定义高级体系结构，以建立一个数据驱动的组织，该组织能够处理其数量巨大且正在变化的大量数据。快速产生。
我打算创建一系列博客，这些博客旨在解决构建大数据架构的不同方面。这是开始博客，在此博客文章中，我将讨论以下内容：

数据生态系统
架构大数据应用程序–高层架构
定义架构的原理，能力和模式

在接下来的博客文章中，我将重点介绍以下内容：

Lambda建筑
数据提取管道（Kafka，Flume）
数据处理–实时以及批处理（MR，Spark，Storm）
Kappa建筑
数据索引和查询
数据治理

我希望您喜欢阅读这些概念，就像我将它们放在这里一样。

数据生态系统

当今世界的数据包含各种来源。这些来源可能在组织内部，例如CRM数据，OLTP数据，账单数据，产品数据或您经常使用的任何其他类型的数据。组织内还有许多数据可用于各种分析目的。主要是运行应用程序负载的各种服务器的日志数据。

还有一些数据是在公司自身的生态系统之外生成的。例如。客户访问公司网站，有关公司的事件流，来自油井传感器的事件，发推特介绍公司服务的人员，员工在其Facebook帐户上张贴有关公司事件的图片，黑客试图通过到公司的防御系统等等。所有这类数据可以大致分为以下几类：

结构化数据（例如，来自CRM系统的数据）
半结构化数据（例如CSV导出文件，基于XML或JSON的数据等）
非结构化数据（视频文件，音频文件等）

所有这些数据源为公司提供了一个提高流程效率的机会，或者为客户提供优质服务的机会，或者在为时已晚之前检测并避免安全漏洞。因此，最重要的是，从任何来源收集的每条数据都可以为组织带来潜在的好处。为了充分利用这一优势，公司必须具备的首要条件是能够存储大量数据并处理这些数据的系统。

了解您将在应用程序中利用的数据类型非常重要。这种理解将为您提供一个选择适合您的工具和技术的良好基础，而不是让这些工具和技术为您服务。您可以做到这一点，即努力使某种技术适用于您的用例，但是与为您的目的定制的工具相比，您将花费在该技术上的工作会更多（有时会更多）。

因此，明智地选择。 Hadoop并不是所有大数据用例的答案。

数据生态系统

大数据（参考）架构

因此，我们实际上如何着手为大数据用例定义架构。一个良好的起点是拥有一个参考体系结构，该体系结构将指导您完成大数据应用程序中涉及的高级流程。您可以找到大数据领域中许多供应商开发的大数据参考体系结构，无论它们是像Apache，Hortonworks之类的开源软件，还是诸如Cloudera，Oracle，IBM等商业软件。

我更喜欢保持简单，并且现在不对参考体系结构进行过多的详细介绍。我会让它在整个博客中自然发展。

下图来自Cloudera的一个博客：http://blog.cloudera.com/blog/2014/09/getting-started-with-big-data-architecture/

这是一篇了解高级大数据架构方法的不错的博客文章。我对其进行了少许修改以使其与技术无关，并添加了IMO的Data Governance（数据治理），这是一个非常重要的跨领域方面，需要单独使用。

让我们了解以上每个细节。

数据摄取：摄取是将数据带到目标系统的过程，在这种情况下，是诸如Hadoop或Mongo或Cassandra之类的大数据存储系统，或任何其他可以有效处理数据量的系统。此数据可以以批量格式（批量提取）到达，也可以是连续的数据流（事件或流提取）。

批量提取：通常在您要将数据从一个源提取到另一个源时使用。例如，您要将CRM数据导入Hadoop。通常，您要做的是从关系数据库中进行数据转储，并将此数据转储加载到大数据存储平台中。因此，您正在批量或批量提取数据。
流摄取：当您有连续的数据源定期在毫秒到秒的范围内发出事件时，则需要一种单独的机制将此类数据摄取到大数据存储平台中。通常，您将使用某种排队系统，在该系统中将定期编写和读取事件。拥有排队系统有助于减轻源中的负载。

正如我们将在以后的博客中看到的那样，拥有一个强大的数据摄取系统，该系统能够扩展，分布式并支持并行消耗，对于您的大数据应用程序至关重要。

快速说明：避免将任何类型的单一使用者队列用作数据摄取实现。

数据准备：数据准备是通常在实际处理数据之前执行的步骤。因此，它也可以称为预处理。但是，Preparation和Preprocessing之间的主要区别在于，数据只准备一次，以便可以通过不同的处理脚本有效地对其进行处理。因此，我们在这里将其称为数据准备。

数据准备涉及以下步骤：

以正确的格式存储数据，以便处理脚本可以有效地对其进行处理（PlainText，CSV，SequenceFile，Avro，Parquet）
跨主机对数据进行分区，以实现数据局部性
数据访问–以使多个团队可以在不干扰彼此工作的情况下使用数据的方式在整个群集中分布数据。这通常称为多租户。定义访问控制列表，不同的用户组等是数据访问策略的一部分

数据处理：数据处理就是关于获取输入数据，例如将其转换为可用格式。不同的文件格式或将存储在HDFS中的CSV转换为初始Hive表。理想情况下，执行转换步骤时不要丢失任何信息。取而代之的是，您只需重组数据即可有效地使用它。完成转换后，就可以开始对数据进行某种分析。分析可以在整个数据集上执行，也可以在数据的子集上执行。通常，对数据集的分析可以表示为有向非循环图，您在其中有一个起始节点，需要执行多个步骤，这些步骤通常由应用于前一节点输出的某种形式的业务规则选择，然后最终达到最后一个节点是您的业务分析算法的结果。理想情况下，此输出可以单独或通过与其他输出组合来回答业务查询。此输出称为视图。要记住的一件事是，分析算法不会更改您的原始数据。取而代之的是，它只读取内存中，磁盘上或其他位置的其他位置的数据，然后对其进行修改并将其另存为视图。

您的原始数据被视为您的主数据，这是整个应用程序的唯一真实来源。如果您拥有主数据，则始终可以再次创建视图。但是，如果您的主数据被损坏，则无法恢复。因此，在为您的主数据管理设计系统时要格外小心。

工作流管理：在给定的时间，将在主数据集上运行多个分析作业。可能有10个不同的Map reduce作业正在运行，或者有x个配置单元脚本，sqoop作业，pig脚本等。需要以某种方式对其进行管理，以便在正确的时间安排它们，而不消耗大量资源。可能是您需要使包含许多配置单元脚本的整个工作流程自动化。工作流管理是用于管理在大数据系统上执行的不同作业的组件。

数据访问：对数据的访问都是关于通过简单SQL界面，使用Hive查询或通过诸如Solr之类的索引引擎进行查询来找到查询数据的机制。此处对数据的访问主要涉及对主数据的访问，这是事实的唯一来源。您的访问方法可能很多，例如Hive脚本，JDBC接口，REST API等，也可能是所有团队都在使用的单一机制。您需要根据组织内部的设置和条件进行选择。

数据洞察力：分析完数据后，您需要回答用户的查询。回答查询可能涉及查看单个分析作业的输出或合并各个作业的输出。可视化数据有时也被认为是深入了解数据的一部分。数据处理通常会产生关键绩效指标（KPI）。这些KPI通常会告诉您整个故事的一部分。例如，监视调制解调器等客户前提设备（CPE）的分析系统可以产生LAN配置错误或网络错误之类的KPI。这些KPI给出了对该问题的初步看法，但可能无法全面了解。例如。由于许多原因，可能会发生网络错误。因此，需要将这些KPI与其他数据集相关联，以深入了解实际问题。

数据治理：数据治理是指管理企业数据的过程和策略。管理任务可能涉及数据可用性，数据可用性，数据安全性等。数据治理的重要方面是数据沿袭。数据沿袭定义为数据的生命周期。我们从数据的来源开始，并在数据被修改或移动的每个步骤中捕获元数据。出于各种原因，数据沿袭很重要。它可能是审核数据的重要工具。或者，用户可能想知道他在报告中看到的图形实际来自何处以及如何得出。

数据管道：数据管道是一种在体系结构的不同组件之间移动数据的机制。将其视为容错和分布式的数据总线

从本质上讲，大数据系统的所有高级架构都包含在其中。仍然需要为体系结构定义很多细节，这些细节主要涉及系统的非功能性需求，例如可用性，性能，弹性，维护性等。我们将在以后的博客中详细介绍每个细节。

现在，我想重点介绍如何定义大数据系统的高级体系结构。

现在，一旦您清楚地知道您确实在处理大数据，并且需要一个系统来处理您的大数据，下一步就是明确定义系统应该建立的原则以及您所做的任何假设。通常，这些原则指导系统的整个体系结构，并且在系统的整个生命周期中都不会改变。

根据系统原理，您开始确定系统的功能，例如安全性，分布式处理，可靠的消息传递等。最后，在定义功能后，您将查看与功能完全匹配并支持体系结构原理的不同模式。因此，从本质上讲，您需要执行以下步骤：

定义架构原则
定义架构能力
定义架构模式

让我们看一个定义上述每个示例的示例

定义架构原则

除非毫无疑问地证明该原则不再适合该应用程序的总体目标，否则就必须遵循架构原则。将建筑原理视为经过大量思考和讨论而编写的诫命，即使可以对这些规则进行例外处理，也应该很少。因此，作为一名架构师，定义不仅与项目的总体目标相一致的原则，而且还要考虑其他方面，例如团队的组成，当前可用的硬件等，变得极为重要。

以下是一些架构原则示例：

该应用程序需要跨节点分布。这可能意味着可以使用该平台将平台组件透明地部署到整个网络上的多个节点上。
应用程序应在负载下进行扩展，并在活动较少时进行缩减，而无需停机。这通常称为动态缩放。
平台的服务应开发为使用轻量级通信协议进行交互的松耦合组件。

在定义架构原则时，请确保它们不影响技术。因此，原理不应该是这样的：

“应使用Java 7开发应用程序”

原则是高层架构问题。低层详细信息（例如实现详细信息，测试详细信息）应保留在其中。

定义架构功能

一旦清楚地确定了架构原则，下一步应该是定义系统应支持的功能。通常，您定义每个体系结构层（UI层，应用程序网关，业务层，集成层，数据层，有时还包括硬件层）的功能，以及跨体系结构不同层的功能，例如日志记录和监视功能。

这是典型的4层架构的不同层上的功能示例

能力是使用一组功能和/或模式来实现某些所需结果的能力。因此，当我说安全性是一种功能时，我的意思是我们希望在服务网关级别具有身份验证和授权。现在，下一步是使用OAuth还是SAML或JWT或其他任何技术。但是我已经确定在服务网关层我需要适当的安全性，否则我将损害我的应用程序。因此，对于每个层，您都开始思考构建系统所需的功能集。因此，对于大数据系统，您可能需要分布式处理能力，可靠的消息传递能力，流处理能力，批处理能力，工作流管理能力，数据复制能力，数据分区能力等。

不要忘记在任何可能的时间回顾架构原则，只是为了与您的原则保持一致。

识别建筑图案

定义体系结构功能后，您将进入下一步，实际确定如何最好地实现该功能。例如，如果您具有数据分区功能，则需要定义将用于分区数据的模式。例如，您将使用基于哈希的分区还是使用基于范围的分区。有时，确定模式/策略非常容易（因为您可能只有一个模式，因此不必做出选择），或者当您需要理解并在不同的模式和策略之间进行选择时，可能会很困难。

在另一篇博客文章中，我将详细介绍可扩展的分布式架构的不同模式。目前，重要的是要了解，识别和记录应用程序的模式是其成功的重要第一步。您无需详尽定义功能或模式，但是在开始转移到体系结构的其他部分之前，应该对它们有所了解。