数据管道的未来

我们之前研究了当前的数据和事件生态系统,以及数据管道必须解决的7个挑战。接下来, 让我们展望未来。为了了解事情的进展, 首先看看它们的去向是很有用的.

200年前, 如果你想在某个地方发短信, 你写了一封信, 可能等了很多年才得到回应。150年前, 你可以用电报在短短一天内完成大致相同的事情。几十年后, 电话和无线电能够立即传输和接收。

8 0年前, 由于第一台商业电视, 视觉信息也发生了同样的情况。其次是上世纪 8 0年代初个人电脑的兴起, 那里的数据可以很容易地存储和搜索 (本地)。然后, 就在25年前, 万维网出现了, 随之而来的是对动态分布式数据存储的需求。

我们学到了什么？

为了参数起见, 让我们认为我们的 “消息” 和 “数据” 是相同的。那么, 我们学到了什么呢？随着每一次创新, 我们管道中的数据都在增长和转变, 包括:

• 金额-系统 (数据管道) 需要在设定的时间范围内处理的数据量。
• 速度-数据通过管道的速度, 这随后会影响响应的预期速度。
• 目的–传输的数据所服务的函数。是消息负载本身？传输机制使用的元数据？格式？头？其他系统的说明？
• 轨迹-数据向其中移动的方向。数据不再仅仅是在一个点之间移动, 例如用电报, 而是经常同时在几组不同的点之间移动, 例如电视广播。或对等网络或区块链。这意味着, 对于每一个生产者来说, 可能有很多消费者。
• 格式-数据可能以结构化、非结构化、纯文本、加密、二进制甚至嵌入其他数据的方式存在。数据也可以是管道中后续系统的命令。或其中的任何组合。

那么, 现在呢？

随着移动和智能手机、移动设备以及最近具有连接基础设施和设备的物联网世界的出现, 我们看到生成的数据量激增, 并在形式和功能上继续发生变化。

根据idc 的数据, 2016年产生的数据有 16.1 zb。预计到 2025年, 这一比例将增长到 163 zb, 全球用户预计平均每18秒与数据驱动的终端设备进行一次交互。

让我们来看看我们认为数据管道和组件在功能、设计、合规性、可用性、性能和可扩展性方面需要能够实现的目标, 以应对这种规模功能

就在十年前, 管道通常是单向的、点对点的, 处理孤立的业务背景数据, 并在 cpu 资源和带宽免费的非工作时间内批量接收 (通常通过不灵活的 etl 来严格地接收架构刚性)。

如今, 数据无处不在, 甚至可能对生活至关重要.因此, 数据处于用户日常生活的前景。因此, 管道可能需要多定向运行 (从接收到一个或多个中央数据湖或数据仓库进行处理, 再到边缘数据中心, 甚至是要处理、可视化和呈现的端点设备)。

这在很大程度上发生在实时或近实时。端到点(也被称为cor-边缘) 分析, 就像在一些现代汽车中发现的分析一样, 就是一个很好的例子。

从这些现象中出现的一个有趣的副作用趋势是, 数据管道不仅仅是支持业务的 it 组件, 而且越来越多地是业务。

alooma是数据管道即服务的一个显著例子;许多其他服务在特定的域中工作, 其核心是实时数据管道。

随着嵌入式物联网设备的激增和移动实时数据的增长, 在此类管道中生成的海量数据必须得到适应并适当提供。这表明了一些要求:

1. 管道及其组件必须能够以最少 (如果有的话) 人机交互的方式自动缩放、分片和分区容忍度。

2. 管道及其数据流应该是可排除故障的, 并且可以动态配置。

3. 管道应该是不可知论的–并且能够容纳–一系列格式, 从完全符合 acid 到完全结构化的数据。

4. 管道实现捕获、修复和重新查询错误事件的措施。

分析管道还将越来越多地成为接收数据并用于培训 ai 和 ml 模型的渠道.这已经内置到像 apache hivemall这样的系统中, 这些系统位于数据管道之上, 进行扣除、检测异常或将数据转换为命令, 例如端点设备或连接的系统。

这些系统将通过更新数据管道和产品的软件组件, 在很大程度上实现持续改进的自我延续和自动化。

也就是说, 在未来, 人类支持这些 ai 系统的挑战将不是培训智能算法或设备 (ai 将学会自我训练), 而是关注事物, 并在必要时进行干预, 以重新训练机器学习组件, 因为它自我发展, 以防止这些系统出轨。

2. 设计

我们已经讨论了当前和未来数据管道的必要性, 以支持核心到端点系统、指数增长的数据量以及接近实时速度.但在数据管道本身的设计中, 其他一些趋势也越来越普遍。

对于任何自我完善的管道来说, 一个重要的考虑因素是杀虫开关

由于 sql 是理解数据的常见范例,管道将继续演变为更像数据库: 管道中的数据可以以飞行为模型, 并且可以使用 st 在任何时间点 (无论是运动中的数据还是静止的位置) 查询管道中的数据和 sql。

我们已经看到流媒体 sql 变体, 如ksql 、amazon kinesis 上的 sql、 apache 方解石和 apache 将要卡 sql, 它们开始支持窗口和联接之类的内容。

虽然这些示例查询流中的数据, 但下一步是使从管道中的任何位置从单个 sql 接口查询数据成为可能。这与像 con流畅这样的供应商目前谈论的表流二元性的概念有关。

另一个设计问题涉及使用区块链或分布式分类账的系统的处理.顺序对于区块链上的事务很重要, 而在许多情况下, 在存在网络分区的情况下,需要调整一致性和可用性之间的折衷.

类似于radixdlt等技术已经执行的方式, 我们将看到更多这些系统将不可变、有序、事件分类账作为可理解一致的分布式数据库实现.

在之前的一篇文章中, 我们介绍了发布-订阅机制的起源。这对我们数据的轨迹也很重要。与其在每个数据生成器和使用者之间进行点对点集成 (系统复杂性等于n * n), 不如围绕一个共同的接口 (复杂性等于n + n)构建数据通信, 而不是在每个数据生成器和使用者之间进行点对点集成。使我们的消费者足够聪明, 可以决定他们将使用哪些数据。

作为设计考虑,公共子机制仍将是数据管道的主要参与者;除了阿帕奇·卡夫卡和亚马逊 kinesis, 我们将继续看到该空间的破坏者, 例如 apache 普尔斯。

所有这些点背后的设计考虑是不可变的有序事件日志。简单地说, 生成器以事务顺序追加到日志中, 而智能使用者则选择他们所使用的事件。

资料来源: 马丁·克莱普曼2018年卡夫卡峰会演讲,卡夫卡是数据库吗？

不可变的有序事件日志是当今大多数数据管道中的一项功能, 它不会去任何地方。

3. 合规性 (包括安全)

那么, 如何保护这样一个事件日志中的数据呢？事实证明, 比简单地保护整个日志要复杂得多。

gdpr 合规规则很复杂, 但一般规定, 具有欧盟公民姓名或身份证的个人数据应保持准确、最新、安全、透明的使用, 并限制在最低限度内完成工作

这使得保护顺序事件日志成为一个挑战, 因为日志中不同范围的行或分区可能对应于不同用户的数据。那你是做什么的？

一种选择是, 在将任何个人身份信息写入数据存储之前, 先放弃这些信息。然而, 在最近的一次谈话中, 阿洛马的 yair weinberger 被问到了这个问题, 并提出了未来管道设计师可以做出的三种选择:

1.如果数据难以访问, 则不存在.在这里, 我们的想法是将日志的不同分区写入不同的位置。一旦对数据的权限被吊销 (或日落), 删除或拒绝对该位置的访问。

2.自动匿名.电子邮件地址和识别信息可以在您离开时进行哈希处理。

3.选择性地撤消加密密钥.日志中的不同分区在存储时使用密钥进行加密。当数据权限日落时, 销毁关联的密钥。

来自爱沙尼亚的 ectx目前提供了另一种选择:

4.完全不要移动数据!可以远程查询日志并进行分析, 而无需将数据导入到系统中 (这也提供了无需在导入前准备数据的额外优势!

因此, 您可以选择是否将数据管道输送到您控制的系统或就地查询数据 (或从远程和本地位置的组合执行上述所有操作)。但在以下方面可能需要考虑一些权衡:

• 延迟。
• 隧道安全。
• 数据存储 (合规性) 要求。
• 存储空间要求 (和相关费用)。
• 所需的 cpu/gpu 功率 (和相关费用)。

4. 可用性 (包括可设计性)

设计涉及如何设计数据管道 (包括它们拥有哪些功能和属性) 来处理其需求 (以及其数据的要求)。设计性更多地与用户在设计管道时必须使用的功能有关。

随着管道变得越来越常见, 管道将从构建块类型的组件 (如时间序列数据库、分布式分类帐、全文搜索、键值存储以及分区的分布式流媒体平台) 进行组装.我们希望用户能找到完整的、通用的预组装配置, 只需点击一下即可安装。

内置抽象层后, 对管道进行编码和配置的需求将减少, 尽管自定义始终是可能的。这意味着 gui 将可用于整个生命周期 (从安装和配置到部署和使用, 最后是报废)。这些管道将自动缩放, 并有可能根据需要添加功能齐全的模块化 “构建块”。

宝藏数据、阿洛马、兰多普和流媒体等解决方案已经让用户可以通过 gui 处理 apache 卡卡卡和/或数据管道的各个方面。

5. 性能 (包括可靠性)

正如您可能猜测的那样, 随着数据管道变得更加普遍, 性能通常必须继续提高: 延迟将接近零, 而平均失败时间将永远接近但是, 随着时间的推移, 我们预测访问数据存储和流的延迟将继续减少。

作为可靠性指标, 测量平均时间到故障 (mttf) 也是如此: 随着时间的推移, 管道将接近零故障 (而mttf →)。这是一种渐近关系, 因为当然, 查询总是需要一些时间, 并且总会有一些失败。

正如scylladb 等公司所证明的那样, 组件将从解释代码或 jvm 代码转移到本地编码元素, 这将全面提高速度、延迟和吞吐量。

这些改进将在大量增长的负载下进行, 无论是在核心、边缘数据中心还是端点设备上进行计算。

6. 可扩展性

即使在系统内生成的数据数量也可能超过存储所有数据的容量。这意味着, devops 未来的工作人员可能需要决定哪些数据保持不稳定和临时, 哪些数据是持久的和存储的。

元数据将继续节省空间, 元数据的格式很可能会继续推进, 以便这些节省能够更加复杂。尽管有所有这些发展, 管道及其数据存储将需要能够大规模的自动缩放, 以适应未来的负载和速度。这包括模块化和添加组件的能力 (通过容器或虚拟机, 可根据需要打开和关闭组件)。

包装

要在 2025年 (及以后) 达到 163 zb, 管道需要容纳在数量、速度、目的、轨迹和格式方面不断演变和转换的数据, 仅举几个属性为例。

明天的数据管道将继续演变, 就像过去的数据管道已经发展到今天一样。我们研究了数据管道和组件在功能、设计、合规性、可用性、性能和可伸缩性方面需要实现的一些目标。

这个帖子最初出现在 aiven. io。