Baleen Analytics

大规模数据过滤带来意外惊喜。

Pat Helland

须鲸是海洋中最大鲸鱼口中发现的一种物质。须鲸的构造类似于指甲，被用作巨大的过滤器，使这些鲸鱼能够舀起大量海水，同时保留营养丰富的磷虾和其他海洋生物作为食物。磷虾是类似于虾的小型甲壳类动物。我将它们视为“虾味十足”的虾，但它们为地球上最大的动物提供了大部分食物。

Escaping the Singularity: Baleen Analytics

与这些鲸鱼一样，数据分析越来越多地收集它能找到的任何东西，而不考虑形状、形式或模式。通过摄取任何事物和一切事物，而忽略其来源或卫生状况，我们正在发现以前无法获得的模式和见解。通过将数据保存在 JSON、XML、Avro 或其他半结构化形式中，这得到了极大的便利。

本文探讨了这种“后期绑定”模式对数据分析以及服务和微服务之间消息传递的影响。似乎许多不同来源之间的良好理解可以带来更大的灵活性和互连性。灵活性越来越胜过完美性。

退化到未来

在 90 年代中期，我帮助构建了世界上第一个事务性 N 层应用程序平台的架构。这是一个非常棒的团队，也是我职业生涯的亮点之一。应用程序开发人员创建了组件以及它们的接口。组件部署在多台服务器上，工作流在客户端、服务器和多个具有明确定义的事务行为的数据库之间流动时，具有动态激活和负载均衡。RPC（远程过程调用）基于接口中的方法调用，这些接口是预先定义的。

我们对早期绑定和后期绑定接口之间的权衡进行了许多喧闹而生动的辩论。 早期绑定接口是预先定义的。它们指定了方法集、访问控制策略以及调用一个挑剔的服务所需的一切，该服务必须拥有一切完美才能处理远程方法调用。早期绑定接口保存在某种形式的共享存储库中，潜在的客户端可以从中吸取它们，以确保完全合规。在许多方面，这反映了组件如何用于组成单片单进程应用程序。我们许多人认为，早期绑定是接口的最终进化步骤，为交换提供了最紧密的语义。

相比之下，后期绑定接口则随意得多。目标服务可能会记录发送给服务的半结构化消息中所需的大致格式。该服务将获取此信息并弄清楚它可以弄清楚什么。通常，这效果很好。目标服务经常会逐步增强，以便更好地绞尽脑汁，充分利用从调用者那里收到的几乎无法理解的垃圾。最早版本的 SOAP（简单对象访问协议）和 REST（表述性状态转移）都是后期绑定接口机制的示例。

在许多方面，早期绑定和后期绑定接口之间的差异在于愿景和目标。早期绑定提供了目的的清晰和明确。您对调用者和被调用者的语义紧密性更有信心。这在交互组合相对较小的相对较小的世界中非常有意义；它可以帮助调试两个组件的交互。另一方面，当调用和被调用组件的集合变得很大时，随着组件随时间推移而发展，这种相同的语义紧密性会带来巨大的挑战。当调用和被调用组件位于不同的部门甚至公司时，对更改施加的摩擦可能会让人难以承受。

早期的分布式系统是从单服务器大型机和小型计算机发展而来的。愿景是将集中式机器扩展到利用单个组织在单个信任域下的单个数据中心中多台计算机的计算能力。多年来，这已经演变成不同信任环境中松散耦合服务的嘈杂合奏，每个服务都以自己的速度向前发展。事实证明，当组件协同工作时，成功互操作的能力比清晰明确的语义更有价值。 虽然我一开始没有预料到这一点，但在后视镜中这很明显。

SQL 及其 DDL

SQL 是主要的关联数据库语言。关系系统非常出色、功能强大，并且用于保存和处理大量重要数据，尤其是用于运营公司的数据。关系代数（SQL 的理论支柱）需要明确定义的模式，以描述数据如何结构化为表、行和列。模式在数据库中使用 DDL（数据定义语言）捕获。

SQL 的模式是早期绑定的。它是声明式的，并且可以进行事务性更新。如果在数据库中使用事务更改了 DDL，则新的 DDL 将用于定义更改后查询的行为。旧的 DDL 在更改之前生效。在任何时间点，DDL 都有一个单一的结构，用于定义数据库的形状和形式以及如何查询它。

SQL 在 OLTP（在线事务处理）方面表现出色。这支持来自数千个并发用户的活动在线更新。许多系统在 OLAP（在线分析处理）方面也很出色，其中针对大型数据集合处理复杂且通常很大的查询。系统在处理针对快速变化的 OLTP 数据的 OLAP 查询方面越来越好，但这仍然是一项艰巨的挑战。

应对这一挑战的一种方法是将数据从 OLTP 系统移出，转移到更易于处理的地方，而不会干扰在线事务工作。一种常见的技术是处理事务系统的日志，因为它们会流向数据库使用的存储。通过这种方式，可以保持略微滞后的分析系统。稍微旧数据的模式的形状和形式在 DDL 中捕获，截至执行更新的时间点。要正确理解此数据，您必须了解时间点模式。

将动态 SQL 解释为时间点 SQL 会导致同时捕获数据及其模式的图像。随着时间的推移，您会拥有许多数据集，每个数据集都有自己的模式，并且您希望将它们一起分析。将此数据投影为从数据库数据派生的 JSON 半结构化对象的情况并不少见。¹ 这尤其方便，因为投影的半结构化对象的语义包含它们自己的模式，这些模式在数据修改时是有意义的。它们是自描述的。这就是我所说的描述性元数据。^2,4

不匹配和混合匹配

通常，SQL 数据库不是唯一的数据来源。如今，有传感器、摄像头馈送、事件流、来自不知名地方的上传、来自合作伙伴的变更数据、客户趋势分析、新闻馈送等等。随着公司推出更多服务器来保存数据（无论是虚拟的还是物理的），新的数据正在大量涌入。所有这些数据都具有某种形式的元数据来描述其含义。元数据可能位于对象或事件上，也可能位于数据集或事件流上。但是，如果没有元数据，您很可能会启动一些软件来识别模式，然后附加元数据。

随着机器学习的进步，通过检查原始数据来发现模式变得越来越实用。半结构化数据对象通常具有层次结构，并且层次结构中的每个节点都带有标签。即使不同的对象具有不同的元数据，并且来自不同的来源，通过比较和对比这些不同的对象并标记相似的事物，我们发现越来越成功。从语义上讲，这可以被认为是随着模式的检测为单个对象装饰新属性。在学习过程中，这是一个迭代过程，其中模式在将添加到新数据的属性与旧数据上的属性相关联后出现。过一段时间后，机器学习变得足够熟练，可以在新数据到达时做得很好。

ELT 与 ETL：首先加载

ETL（提取、转换和加载）是一种历史悠久的机制，用于从具有完善模式的系统下载数据，并将数据转换为目标模式。有时，由于模式映射不完美，这会丢失一些知识。^3,4 几十年来，这一直是跨独立系统共享数据的经过考验的可靠机制。

ELT（提取、加载和转换）有些不同。在这种方案中，即使没有模式，目标系统也会吸收数据。通常，半结构化对象中存在所需模式的某个子集，但并非总是如此。通过检查对象中的数据并寻找模式，系统可以分配解释。

ELT 及其延迟元数据分配具有优点和缺点。与跨服务的过程调用中的后期绑定类似，ELT 更具适应性，并且更容易接受差异和演变。此外，与后期绑定类似，它可能无法完美匹配语义，而是给出“足够好”的答案。

粉碎文档以增加您的理解

当您想到粉碎文档时，您会想到确保纸张变成无法理解的小碎片。在复杂的分析环境中，情况恰恰相反。您可以找到与其他文档中具有相同元数据的数据属性。通过找到共性或非常好的共性，您可以将来自许多文档的这些属性的值组合在一起。将文档分解为组成属性并将它们单独存储称为粉碎。

有时，文档中的所有属性都会被粉碎到这些分组中。有时，某些属性与其他属性不太匹配，并且保留在原始文档中。根据文档的内容，粉碎的表示形式可能足够完整，以便在需要时重新构成原始文档。在这种情况下，您可以丢弃原始文档而不会丢失数据。

通过将这些相关属性彼此相邻放置，可以将它们视为一列，并创建超快的面向列的分析。发生这种情况时，系统会收集数据，按推断的关系组织数据，并创建快速分析能力。随着更多数据的摄取，它会被重组以支持快速查询。其他信息不断合并到旧信息中。现在，可以对粉碎的输入文档执行非常快速的分析。

数据湖、数据池和数据海洋

数据湖是结构化、非结构化和半结构化数据的集中式存储库。对于许多公司来说，公共云使数据湖成为可能。这些云需要大量技术来构建和运营。不同数据的集合可能很大、巨大或相对较小。如今，收集数据、命名数据并提供读取访问权限并不太复杂。复杂的是，与大小无关，是对其中包含的所有不同模式和数据进行推理。

我们正在超越期望一切都放在单个数据库中。相反，我们看到不同表示形式、来源和元数据的音调不和谐的合唱。不再可能期望对组合数据的全部细节和细微差别有透彻的理解。越来越重要的是，跨这些许多不同来源获得“足够好”的见解。的确，这通常至关重要。

蓝鲸被认为是地球上曾经存在过的最大动物。据了解，一些巨大的蓝鲸一次吞噬多达 220 吨富含磷虾的海水，并通过口中的须鲸将其过滤。通过这种方式，它们可以只保留最好的东西来吞咽和处理，并用输出物来丰富海水。

在新兴的数据湖、数据池和数据海洋中，拥有能够摄取、分析和标记具有有意义（或部分有意义）元数据的系统的价值是难以置信的。模式匹配和机器学习的最新进展现在正在创造出令人惊讶的有用输出。就像蓝鲸一样。

参考文献

1. Helland, P. 2005。外部数据与内部数据。《创新数据系统研究会议 (CIDR) 论文集》； http://cidrdb.org/cidr2005/papers/P12.pdf。

2. Helland, P. 2011。如果您有太多数据，那么“足够好”就足够了。acmqueue 9(5)； https://queue.org.cn/detail.cfm?id=1988603。

3. Helland, P. 2016。胡言乱语的力量。acmqueue 14(4)； https://queue.org.cn/detail.cfm?id=3003188。

4. Helland, P. 2019。提取、硬塞和加载。acmqueue 17(2)； https://queue.org.cn/detail.cfm?id=3339880。

Pat Helland 自 1978 年以来一直从事事务系统、数据库、应用程序平台、分布式系统、容错系统和消息传递系统的实施工作。为了消遣，他偶尔撰写技术论文。他在 Salesforce 工作。Pat 的博客位于 pathelland.substack.com

最初发表于 Queue 第 18 卷，第 6 期—
在数字图书馆中评论本文

更多相关文章

Ethan Miller、Achilles Benetopoulos、George Neville-Neil、Pankaj Mehra、Daniel Bittman - 远内存中的指针
有效利用新兴的远内存技术需要考虑在父进程上下文之外操作富连接数据。正在开发中的操作系统技术通过公开诸如内存对象和全局不变指针等抽象来提供帮助，这些抽象可以由设备和新实例化的计算来遍历。这些想法将允许运行在未来具有分离内存节点的异构分布式系统上的应用程序利用近内存处理来实现更高的性能，并独立扩展其内存和计算资源以降低成本。

Simson Garfinkel、Jon Stewart - 磨砺您的工具
本文介绍了我们在首次发布十年后更新高性能数字取证工具 BE (bulk_extractor) 的经验。在 2018 年至 2022 年期间，我们将程序从 C++98 更新到 C++17。我们还进行了完整的代码重构并采用了单元测试框架。DF 工具必须经常更新，以跟上其使用方式的变化。对 bulk_extractor 工具更新的描述可以作为可以而且应该做什么的示例。

Pat Helland - 自主计算
自主计算是一种业务工作模式，它使用协作来连接领地及其使者。这种模式基于纸质表格，已经使用了几个世纪。在这里，我们解释了领地、协作和使者。我们研究了使者如何在自主边界之外工作，并且既方便又保持局外人身份。我们还研究了如何启动、长期运行并最终完成跨不同领地的工作。

Archie L. Cobbs - 持久性编程
几年前，我的团队正在为一个增强型 911 (E911) 紧急呼叫中心商业 Java 开发项目工作。我们试图使用传统的 Java over SQL 数据库模型来满足该项目的数据存储需求，但感到沮丧。在对项目的特定要求（和非要求）进行一些反思之后，我们深吸一口气，决定从头开始创建我们自己的自定义持久层。