第1篇：通过流式数据集成实现数据价值（1）
本篇为通过流式数据集成实现数据价值的第2篇——流式数据集成。
流式数据集成是对企业数据的实时连续收集和移动，以高吞吐量和低延迟大规模地处理大量数据。数据的处理、分析、关联和传递是在流动中进行的，从而以可靠且可验证的方式提供了数据价值和可见性。
在深入讨论实现流集成所需的内容之前，务必理解此定义中强调的每个概念。
2.1 实时
流式数据集成的首要原则是所有事情都是实时发生的。与传统的提取、转换和加载(ETL)系统或任何使用存储作为中介的体系结构相比，创建、收集、处理、交付或查看数据之间没有延迟。
这个概念意味着数据必须在生成后的微或毫秒内收集。如果一个组织想要对它的业务有即时的了解，任何延迟都会妨碍它理解现在正在发生的事情。
2.2 持续收集
持续收集的结果是一组数据流，这些数据流通过处理管道以及在集群计算机之间、本地和云中实时承载数据。它们既可以用在创建数据时连续处理数据，又可以将其从源端移到最终目标端。
为了提高速度和降低延迟，这些流应主要在内存中运行，而无需写入磁盘，但在出于可靠性和恢复目的而必需的时候，应具有持久性。
2.3 任意企业数据
数据是在企业内部以多种不同方式生成和存储的，并且需要多种不同的技术来访问它。我们已经提到了数据库、文件、消息队列和物联网设备；还包括数据仓库、文档、对象和图形数据库；分布式数据网格；网络路由器；以及许多软件即服务（SaaS）产品。所有这些都可以在本地，云中或混合云体系结构的一部分中。
对于每个类别，都有许多提供程序和格式。单独的文件可以通过几种不同的方式编写，包括使用CSV，JSON，XML，Avro，Parquet或其他多种格式。
流式数据集成的集成组件要求任何此类系统都必须能够从这些企业源中的任何一个连续收集实时数据，而与数据源的类型或数据的格式无关。
2.4 磁盘容量的极限
在考虑数据量时，我们通常引用的数字单位是TB，PB或EB，但这是存储的数据总量。我们需要以不同的方式考虑流系统的数据量。具体来说，我们需要根据生成新数据的速度来考虑它们。
所使用的度量标准可以基于新事件的数量或在特定时间段内创建的字节数。
对于数据库，即使存储在数据库中的数据总量变化不大，存储在事务日志中的插入、更新和删除操作记录每小时也可能高达数十至数百GB。每天来自许多计算机的安全性，网络设备和系统日志可以轻易超过数百到数千亿个事件。在一段时间之后，这些日志中的许多日志将被丢弃，因此磁盘上的容量保持相当稳定，但是新的数据生成速率可能是每天都是TB级。
数据写入磁盘的速度受到物理限制：磁旋转磁盘的速度为50到100MB，固态驱动器（SSD）的速度为200到500MB。大型企业系统通常具有并行系统以实现更高的吞吐量。但是，如果根本不涉及磁盘，则数据生成率最高。使用传输控制协议（TCP），用户数据报协议（UDP）或超文本传输协议（HTTP）之类的协议直接从网络端口读取可以达到更高的数据量，最高可达网卡的速度，通常为1至10GB。
实时连续数据收集和底层流传输架构需要能够处理这样的数据量，在生成数据时从磁盘和端口读取数据，同时在源系统上施加较低的资源使用率。
2.5 规模化
可伸缩的流式数据集成分为许多大类，稍后我们将对此进行更深入的讨论。除了将数据收集扩展到数百个数据源之外，还需要考虑处理和处理内存上下文数据的扩展。
流式数据集成解决方案需要向外扩展。在跨集群分发处理和内存存储数据时，它们需要利用单台机器上的处理器线程和内存。在一个可伸缩的集群中有许多分布式节点，因此在节点之间移动数据的流架构必须是高效的，并且能够利用所有可用的网络带宽。
2.6 高吞吐量
处理大规模高容量的数据，需要对整个系统进行调优，以处理巨大的数据吞吐量。仅仅能够跟上生成的大量数据的收集是不够的。还需要以相同的速度移动、处理和交付数据，以消除与源数据相关的任何延迟。
这涉及到能够根据需要分别扩展系统的收集、处理和交付方面的能力。例如，收集web日志并将其转换为基于云数据仓库可能需要数百个收集节点、数十个处理节点和多个并行交付节点，每个节点都使用多个线程。
此外，系统的每个方面都需要进行调优，以采用最佳实践，确保最佳地使用CPU和最小限度地使用输入/输出(I/O)。内存技术最适合这项任务，特别是在处理和数据移动方面。但是，出于可靠性和恢复的目的，可能需要谨慎地使用持久数据流。
2.7 低延迟
延迟(或管道的结果滞后于数据生成的时间)与吞吐量或规模没有直接关系。它可能具有每秒数百万个事件的吞吐量，但却有很高的延迟(不是您所期望的微秒)。这是因为数据可能需要在管道中通过多个步骤传递，在不同的机器之间移动，或者在本地系统和云之间传输。
如果目标是最小化延迟，则必须限制处理步骤，I/O和所使用的网络跃点。与使用单个步骤的管道相比，需要许多步骤才能完成多个简单任务的管道将具有更多的延迟，从而将较简单的任务转化为一个更复杂的任务。同样，使用中心辐射型模型的体系结构将比点对点具有更多的延迟。
流式数据集成的一个目标是最小化延迟，同时最大化吞吐量和限制资源消耗。简单的拓扑，例如将实时数据从数据库迁移到云，应该有毫秒的延迟。向这样的管道添加处理只会略微增加延迟。
2.8 处理
源数据很少以交付到异构目标所需的精确形式出现，或者能够用于分析。通常需要删除、压缩、重新格式化或反规范化某些数据。这些任务是通过处理内存中的数据来实现的，通常是通过使用过滤、转换、聚合和更改检测以及充实的组合的数据管道来实现的。
很少有源数据具有交付给异构目标或能够用于分析的确切格式。通常，通常需要删除、压缩、重新格式化或反规范化某些数据。这些任务是通过处理内存中的数据来实现的，通常是通过结合过滤、转换、聚合和变更检测，以及配合数据管道来完成的。
2.8.1 过滤
过滤是一种非常广泛的功能，它使用多种技术，范围从简单（仅允许通过日志文件中的错误和警告消息通过）、中等（仅允许与一组正则表达式中的一个匹配的事件通过）、复杂（将数据与机器学习模型进行匹配以得出其相关性，并且仅传递相关数据）。由于过滤是针对单个事件（通过包含或排除事件）起作用的，因此很容易看出我们如何在一个或多个数据流中实时，内存地应用此事件。
过滤是一个非常广泛的功能，它使用多种技术。它的范围可以从简单(只允许错误和警告消息日志文件通过)、中间(只允许事件相匹配的一组正则表达式通过)、复杂(匹配数据对机器学习模型，推导其相关性，只有通过相关数据)。由于过滤是针对单个事件（通过包含或排除事件）起作用的，因此很容易看出我们如何在一个或多个数据流中实时地、在内存中应用它。
2.8.2 转换
转换涉及到对数据应用一些函数来修改其结构。例如：一个简单的转换是将名字（FirstName）和姓氏（LastName）字段连接起来，以创建一个完整的用户名称（FullName）。排列是无限的，但常见的任务包括诸如：转换数据类型、解析日期和时间字段、执行混淆或加密的数据保护隐私、执行基于IP地址查找溯源位置或组织数据、将从一种数据格式转换为另一个(例如Avro、JSON)、或通过匹配正则表达式提取部分数据。
2.8.3 聚合和变更检测
聚合是压缩或分组数据（通常是时间序列数据）以减小其粒度的常用术语。这可能涉及基本的统计分析、抽样或其他保留信息内容但降低数据频率的方法。一个相关的概念是变更检测，顾名思义，变更检测仅在数据变更时才输出数据。
根据定义，数据聚合发生在多个事件上。因此，聚合的范围通常是一个时间窗口，或者由其他规则定义以保留事件。因此，考虑到需要将成千上万个事件保存在内存中，而聚合需要一定的规模来确定边缘设备的硬件需求，因此聚合比过滤需要更多的内存。
2.8.3 丰富数据
丰富数据对于数据库，物联网和其他用例也至关重要。在许多情况下，原始数据可能没有足够的上下文被认为有用。它可能包含ID，代码或其他数据，这些数据对下游分析家几乎没有价值。通过将实时数据与某些上下文（例如设备，零件，客户等）结合起来，它就变成了有价值的信息。实时充实数据流类似于数据库世界中的非正态化，通常会增加而不是减少数据的大小。
2.8.4 实现选项
建立流式数据集成管道的人员必须可以访问所有这些处理任务。并且那些构建管道的人需要了解如何使用数据。以下是有关如何执行这些任务的一些选项：
- 为每个简单任务安排单独的操作员，执行处理
- 使用Java或Python之类的编程语言对处理进行编码
- 使用声明性语言（例如SQL）定义处理
可以在单个管道中混合和匹配这些技术，但是如果希望最小化处理步骤、最大化吞吐量和减少延迟，可以使用SQL之类的语言(可以透明地编译高性能代码)，这在易用性、灵活性和速度之间提供了很好的折衷。
2.9 分析
流式数据集成不仅仅具有通过流内处理在源和目标之间连续迁移数据的能力。流数据管道到位后，还可以通过执行实时分析从流数据中获得即时价值。
这种分析可以有多种形式，但通常分为几大类：
- 时间序列和统计分析
- 事件处理和模式检测
- 机器学习算法的实时评分
2.9.1 时间序列和统计分析
时间序列分析可以自然地对流数据执行，因为流式数据本质上是多时态的。也就是说，可以根据可用于按时间排序数据的多个时间戳记对其进行描述。所有数据都会有一个与收集时间相对应的时间戳。另外，某些收集机制可以访问外部时间戳，并且数据本身可以包括其他时间信息。
通过将一定数量的数据保留在内存中或使用增量统计方法，可以生成实时统计量度，例如移动平均值，标准差或回归。我们可以将这些统计信息与规则和其他上下文结合使用，这些规则和上下文本身可以是动态的，以发现统计上的异常行为。
2.9.2 事件处理和模式检测
事件处理或过去称为复杂事件处理(CEP)的技术，使模式能够在事件序列中被检测到。它是时间序列分析的一种形式，但它不是依赖于统计数据，而是寻找预期的和意外的事件。这些通常依赖于事件中的数据来指定模式。
例如，一个统计分析可以发现一个温度是否在一定的时间内变化超过两个标准差。事件处理可以利用这一点，并寻找一种模式，在这种模式中，温度继续升高，而压力在增加，流量在下降，所有这些都在指定的时间内发生。事件处理通常用于已知和可描述模式的地方，这些模式通常来自以前的数据分析结果。
2.9.3 机器学习算法的实时评分
机器学习集成使得预先训练的机器学习模型能够针对流数据执行，从而提供当前数据的实时分析。模型可用于分类、预测或异常检测。我们可以对包含许多变量、周期性行为或无法指定模式的数据使用这种类型的分析。
在流集成数据流中执行分析的最大好处是，结果(因此业务洞察)是即时的——使组织能够对问题发出警报并实时做出决策。
2.10 关联
许多案例需要从多个来源收集实时数据。为了从该数据中提取最大的值，可能需要根据多个数据流之间的关系将该数据连接在一起，比如它通过时间、数据值、位置或更复杂的关联的方式。
例如，通过将计算机信息(如CPU使用量和内存)与应用程序日志中的信息(如警告和响应时间)相关联，可能会发现我们可以用于未来分析和预测的关系。
相关性最关键的方面是：首先，它应该能够跨多个数据流工作。其次，它需要在定义相关事件的规则中具有灵活性，并且易于定义和迭代。最终，必须考虑持续交付。
2.11 持续交付
在收集、处理、关联和分析数据之后，结果几乎总是必须交付到某个地方。“某些地方”可以是文件系统、数据库、数据仓库、数据湖、消息队列或API，既可以是本地的，也可以是云中的。唯一的例外是数据仅用于内存分析。
在可能的情况下，写入数据也应该是连续的(而不是批处理的)，并支持几乎任何企业或云目标和数据格式。与连续收集类似，我们应该使用并行化技术来最大化吞吐量，以确保整个端到端管道不会引入任何延迟。交付的一个重要方面是，应该能够确保所有适用的源数据都被成功地写入，一次且仅一次。
2.12 价值
任何形式的数据处理或分析的目标都是从数据中提取业务价值。数据的价值取决于它的性质，区分数据和信息是很重要的。虽然这些术语经常可以互换使用，但它们不应该互换。数据是未经处理的事实的集合，而信息则是以赋予其价值的方式处理的数据。
为了最大化价值，我们需要提取信息内容，对于时间敏感的数据，这需要在收集数据时立即进行处理。这包括过滤掉无效数据、执行变更检测、用额外的上下文来丰富数据或者执行分析来发现异常并做出预测。流式数据集成允许在数据交付或可视化之前进行此操作，从而确保通过可视化和告警立即将数据的价值提供给业务。
其他增加数据价值的方法包括在单一架构中组合批处理和流处理技术，这被称为Lambda架构。流式数据集成既可以为批处理分析和机器学习提供只支持附加的数据存储，也可以为即时洞察提供实时的内存分析。作为此体系结构的扩展，流处理可以连接历史结果以向流数据添加上下文，或调用预训练的机器学习模型来跨越批处理和实时处理。
2.13 可见性
顾名思义，可见性是我们向用户显示数据的方式，通常是一种交互方式。这可能涉及以图表和表格的形式在仪表板中组合在一起的可视化。仪表板和图表可以搜索、过滤，并提供到辅助页面的详细信息。与更传统的BI软件不同，流可视化常常显示最新的信息，但也可以重新显示历史信息。
可见性在流式数据集成的上下文中可能意味着以下两种情况之一:
- 数据本身和分析结果的可见性
- 数据管道和集成流的可见性
前者提供了对业务价值的洞察，而后者提供了数据收集、处理和交付的操作视图，包括数据量、滞后时间和关于数据管道内异常行为的警报。
2.14 可靠性
任何用于关键任务业务操作的系统都必须可靠。这意味着系统必须做您期望它做的事情，持续运行，并能够从故障中恢复。
在流式数据集成的范围内，能够确保数据的精确处理和交付是非常重要的，这与流的复杂性无关。源生成的所有数据必须被收集、处理并可靠地交付给目标。在服务器、网络、系统或其他故障的情况下，数据流必须从它们停止的地方恢复并继续，确保没有丢失任何数据，并且所有处理过的数据只交付一次。
此外，如果集群中的各个服务器发生故障，系统必须能够在其他节点上恢复数据流，以确保持续的操作。理想情况下，这一切都应该对用户透明地发生，而不需要人工干预。
2.15 可验证
提供可靠性保证只是问题的一半。也越来越有必要能够证明这一点，并提供对这一过程的洞察。通过数据流可见性，包括数据量、事件数量、最后的读和写点以及数据沿袭，用户需要能够证明所有已读的数据都已被处理和写入。
显然，这随源和目标的不同而不同，但原则是您需要跟踪从源到目标的数据，并验证它是否成功地写入了任何目标。业务操作需要以仪表板和报告的形式访问这些信息，并对任何差异发出警报。
2.16 总结
总之，本章首先定义了流集成。然后解释其主要属性，包括:
- 提供任何企业数据的实时连续收集和迁移
- 处理大规模的极端量
- 实现高吞吐量和低延迟
- 启用在流中处理、分析、关联和数据交付
- 最大化数据的价值和可见性
- 确保数据可靠且可验证
流式数据集成应该首先采用流优先的方法来收集数据，然后利用所有这些属性。任何支持流式数据集成的平台都必须提供所有这些功能，以处理多个关键任务和复杂的案例。如果缺少这些属性中的任何一个，就不能说平台是真正的流式数据集成。
在下一章中，我们将讨论流集成管道的开始:实时连续数据收集。
