实时业务时代：现代数据基础设施不进行ETL

企业是24小时运作的。这包括从网站、后勤办公、供应链等各个方面。过去，一切都是通过批处理运行的。就在几年前，操作系统会暂停以便将数据加载到数据仓库中并运行报告。现在的报告则关注事物的实时状况。已经没有时间进行 ETL。

许多 IT 架构仍然基于中心和辐射系统。操作系统将数据提供给数据仓库，然后数据仓库再提供给其他系统。专业的可视化软件根据“仓库”创建报告和仪表板。然而，这种情况正在发生变化，这些业务变化需要数据库和系统架构进行适应。

▌更少的副本，更好的数据库

过去十年中，伴随着大规模云迁移和可扩展性努力的一部分，许多公司采用了许多专用数据库。在许多公司中，网站由 NoSQL 数据库支持，而涉及资金的关键系统则位于大型计算机或关系数据库上。这只是问题的表面。对于许多问题，还使用了更专业的数据库。通常，这种架构需要使用传统的批处理过程来处理大量数据。操作复杂性不仅导致了延迟，还导致了故障。这种架构本不是为了可扩展性而设计的，而是被拼凑在一起以止住问题的蔓延。

数据库正在发生变化。关系数据库现在能够处理非结构化、文档和 JSON 数据。NoSQL 数据库现在至少具有一定的事务支持。同时，分布式 SQL 数据库在保持与现有 SQL 数据库和工具兼容的同时，实现数据完整性、关系数据和极端可扩展性。

然而，仅凭这一点还不够。事务性或运营系统与分析系统之间的界限不能成为边界。数据库需要同时处理大量用户和长时间运行的查询，至少在大部分时间里是这样。为此，事务/运营数据库正在添加列式索引或 MPP（大规模并行处理）功能等分析功能。现在可以在一些分布式数据库上运行分析查询，例如 MariaDB Xpand（分布式 SQL）或 Couchbase（分布式 NoSQL）。

▌永不提取

这并不是说现在的技术已经达到不再需要专用数据库的地步。目前没有哪个运营数据库能够处理PB级别的分析。在某些边缘情况下，只有时间序列或其他专用数据库才能发挥作用。让事情变得更简单或实现实时分析的诀窍是避免提取。

在许多情况下，答案是如何首次捕获数据。与其将数据发送到一个数据库，然后从另一个数据库中提取数据，不如将事务同时应用于两者。像 Apache Kafka 或 Amazon Kinesis 这样的现代工具可以实现这种数据流。虽然这种方法确保数据能够毫无延迟地同时到达两个地方，但它需要更复杂的开发来确保数据完整性。通过避免数据的推拉，事务和分析数据库可以同时更新，从而在需要专用数据库时实现实时分析。

有些分析型数据库无法做到这一点。在这种情况下，可以作为权宜之计使用更加常规的批量加载。然而，要有效地执行此操作，源操作数据库需要承担更多长时间运行的查询，可能在高峰时段进行。这就需要内置列式索引或 MPP（大规模并行处理）。

▌数据库新旧更迭

客户端-服务器数据库在它们的时代是惊人的。它们演变为充分利用众多 CPU 和控制器，为各种应用程序提供性能。然而，客户端-服务器数据库是为员工、工作组和内部系统设计的，而不是互联网。在现代 Web 规模系统和数据无处不在的时代，它们已经变得完全难以维持。

许多应用程序使用许多不同的独立数据库。优点是如果其中一个出现故障，影响范围较小。缺点是总有一些东西在不断出现问题。将较少的数据库合并到分布式数据织物中，允许 IT 部门创建更可靠的数据基础设施，以较少的停机时间处理不同数量的数据和流量。这也意味着在分析数据时，需要推送的数据更少。

支持新的商业模式和实时运营分析只是分布式数据库架构的两个优点。另一个优点是，通过减少数据的副本数量，理解数据血统和确保数据完整性变得更简单。在不同系统中存储更多的数据副本会增加数据不匹配的可能性。有时数据不匹配仅仅是不同的时间索引，而其他时候则是真正的错误。通过将数据整合到更少且更有能力的系统中，您可以减少副本数量并减少检查的工作量。

▌全新实时架构

通过主要依赖既能处理事务又能处理分析的通用分布式数据库，并在更大的分析案例中使用流处理，您可以支持现代企业所需的实时运营分析。这些数据库和工具在云端和本地都容易获取，并且已经广泛应用于生产环境。

改变是困难的，而且需要时间。这不仅仅是一个技术问题，还涉及人员和后勤问题。许多应用程序已经采用了独立的架构，并独立于其他数据基础设施的开发周期。然而，经济压力、日益激烈的竞争和新的商业模式正在推动着即使是最保守和坚定的公司进行这种变革。

与此同时，许多组织正在使用云迁移来刷新他们的 IT 架构。无论如何或为什么，商业现在都是实时的。数据架构必须与之相匹配。

本文作者：Andrew C. Oliver （MariaDB 的高级产品营销总监）

本文由“云原生数据库”小编翻译，更多内容请关注公号“云原生数据库”