谈谈数据管理的前世今生

我第一次接触数据仓库是在20世纪末。它给我留下了深刻的印象，因为它是管理数据的第一个真正的体系结构方法，在此之前，我已经在异构数据库和点对点应用程序接口的世界中工作了多年。回顾自那时以来的近30年，很明显，数据仓库只是数据管理的开始，而不是我们当时天真地相信的最终状态。现在，我们正处于第三代数据管理的早期阶段。让我们看看数据管理发展的每个阶段，以了解我们从哪里来，我们现在在哪里，以及在不久的将来可能会发生什么。

第一代数据管理-数据仓库

1988年，Barry Devlin和Paul Murphy在IBM Systems Journal上发表了一篇文章，描述了一种用于数据管理的体系结构，其中的核心组件是他们称之为业务数据仓库的东西。在1991年，IBM宣布数据仓库作为一个产品。Bill Inmon的《开发数据仓库》一书从1992年开始普及数据仓库。在20世纪90年代和本世纪初，数据仓库被世界各地的企业广泛采用。数据仓库被认为是通过集成和主题导向来控制数据混乱的方法。很多关于数据仓库的宣传都集中在创造一个数据单一版本的事实上。

下图说明了一个典型的数据仓库体系结构。数据源几乎都是内部生成的企业数据，来自ERP、SaaS应用程序和遗留系统等业务系统的数据。源数据完全由结构化数据组成，最常见的是在关系数据库中，但有时在文件系统、层次数据库和网络数据库中。ETL流程通过转换将数据从数据源移动到数据仓库，以集成、清理和聚合数据。仓库本身使用了RDBMS技术。主要应用于BI和分析报告。

数据仓库在形式化数据体系结构和数据管理实践方面迈出了重要的第一步。消除冗余数据源之间的不一致性，为业务用户访问提供可理解的数据源，降低复杂和脆弱的点对点应用程序接口的复杂性，这些都是说明数据仓库成功的有价值的成就。

然而，数据仓库并不完全成功。很少有数据仓库实现了单一真实版本(SVOT)的目标。事实上，在我所有的研究、咨询和项目中，从未遇到过一个完全实现了SVOT的数据仓库组织。由于合并、收购和竞争的内部项目导致了多个数据仓库，数据仓库本身变成了使数据差异的部分。最近进行的调查显示，只有一个数据仓库的公司不到10%。

此外，数据仓库在解决20世纪90年代数据管理挑战的同时，数据管理的巨大变化也给21世纪的数据管理带来了新的挑战。

第二代数据管理-数据湖

在世纪之交后不久，我们经历了数据管理的巨大转变——我经常称之为数据地震。正如地震会动摇地球表面的基础一样，数据地震也动摇了建立在20世纪90年代建筑上的数据管理实践的基础。曾经稳定的数据管理世界迅速变得动态和不稳定。新世纪到来时，数据管理取得了许多进步，对新方法提出了要求:大数据技术、云计算、数据湖以及分析和自助服务的优化成为数据管理的优先事项。

上图展示了第二代数据管理的典型参考体系结构。数据湖是一个核心架构组件，它消除了RDBMS作为主要数据库技术的限制。NoSQL数据库提供了存储和管理非结构化和不同结构化数据的功能。在数据库中存储数据之前强加模式的需求消失了。不再需要将所有数据集成到单个内聚模式中，事实上也不再需要。从数据科学家的原始数据到用于基本报告的集成和聚合数据，多层次的数据细化已经成为新的最佳实践。云部署提供了处理大量数据时所需的可伸缩性和弹性。Hadoop等技术为处理大数据提供了手段。新的数据管理角色，比如数据科学家和数据工程师以及高级分析和数据科学领域的新用例出现了。更多的数据，更多种类的数据，更多的用例，更多的用户……这些都是下一代数据管理架构的驱动力。

但是数据仓库(或者大多数公司都有多个数据仓库)并没有消失。尽管许多人宣称数据仓库已经死亡，但数据仓库仍然存在。数据仓库并没有死。大数据可以扩展和丰富数据仓库，但无法取代数据仓库。数据仓库集成了关键和有价值的企业数据，这些数据在大数据源中找不到，并且仍然是描述性、说明性和决策分析的主要数据资源。它作为企业记忆，收集历史的主体，使时间序列和趋势分析成为可能。同样重要的是，数据仓库组织和结构数据，以使其易于理解，并对许多不同的业务涉众使用有用。在许多实现中，数据仓库成为数据湖的额外数据源，尽管目前许多数据架构师都在努力确定如何最好地将数据湖和数据仓库定位为互补的数据源。

数据湖是成功的吗?这是个很难回答的问题。有许多成功的案例，但也有许多代价高昂的失败的报道。我认为事实上，数据湖的概念是成功的，因为它回应了大数据、非结构化数据、可伸缩性和弹性的挑战。失败不是观念的失败。它们是执行的失败，计划、组织和管理的失败，将数据湖变成了数据沼泽。

数据湖为数据管理事业做出了积极的贡献。在一个数字经济和商业数字转型的世界里，我们不能仅仅因为数据不适合第一代架构而忽视数据。很多有意义的见解的数据来源都来自大数据源——网络活动、移动活动、社交媒体，以及依赖于流处理的机器和传感器数据。数据湖提供了管理数据并使其可用于分析的体系结构和原则。

第二代数据管理并非没有麻烦。不稳定且快速变化的开源技术甚至对最好的变更管理人员都构成了挑战。云技术引发了对锁定的担忧。随着批处理ETL多个、多向、通常是实时数据管道的转变，数据处理变得更加复杂。数据沿袭难以跟踪，数据治理也很困难。数据访问常常是痛苦的，因为在湖中查找数据并不容易，特别是在缺乏元数据的情况下。数据湖和数据仓库之间的重叠和不一致表明，数据湖是另一个数据筒仓。

大数据和数据湖的数据架构代表了当今大多数组织的现状——他们正在实现什么或他们希望构建什么。在我们迈向下一个数据管理成熟度级别时，展望未来是很重要的。创新技术供应商已经朝着下一代数据管理工具迈进，以应对第二代数据管理的挑战。

第三代数据管理-数据目录，数据中心，数据结构

数据管理的下一个发展将解决以数据湖为中心的架构的困难。数据目录解决了查找和理解数据的困难，并使元数据管理向前迈进了一大步。数据目录是第三代技术中最成熟的，但广泛采用才刚刚开始。数据中心缓解了数据湖和数据仓库作为多个和分离的筒仓的困难。数据架构为复杂的数据管理添加了智能工具，并满足了成功使用DataOps的许多需求。

下图说明了数据目录、数据中心和数据结构如何构成第三代数据管理的核心。

数据目录最初是由自助数据分析工具驱动的，它为非技术数据和业务分析师提供了友好的、无需代码的工具来报告、分析和可视化数据。自助数据准备工具提供了改进、丰富、格式化和混合数据的功能。然而，大多数数据分析师都是盲目工作的，对存在的数据集、这些数据集的内容以及每个数据集的质量和有用性都不了解。数据目录消除了盲目性，使数据集易于搜索和描述，因此分析师可以快速轻松地找到他们需要的数据，并评估其有效性。目录已经成为数据管理、数据管理协作和元数据管理的首选技术。

数据中心不仅仅是数据整合的另一种形式。健壮的数据中心包括数据存储、协调、索引、处理、治理、元数据、搜索和探索等特性。来自多个源(包括操作源和分析源)的数据通过复制和/或发布-订阅接口获得，并存储在集线器中。注意，数据湖和数据仓库并没有消失。它们成为了输入到中心的数据来源。批处理、流处理和AI/ML处理是集线器概念的核心。AI/ML是一个显著特征，它使分析处理能够移动到数据位置，而不是通过网络移动大量数据进行处理。索引、搜索、数据探索、数据保护、协调和元数据管理等特性构成了健壮的数据中心的基本功能。

数据结构是架构和技术的组合，其设计目的是减轻管理许多不同类型数据、使用多个数据库管理系统并跨各种平台部署的复杂性。如今，典型的数据管理组织将数据部署在本地数据中心和多个云环境中。它们的数据包含关系数据库、文档存储、图形数据库等等。处理技术跨越了从批处理ETL到变更数据捕获、流处理和复杂事件处理的各种技术。工具、技术、平台和数据类型的多样性使得跨多个平台管理处理、访问、安全性和集成变得困难。数据架构提供了一个统一的数据管理平台。它是一个单一的平台，用于管理不同的数据和部署在多个数据中心(云和本地)上的不同技术。数据编排是数据结构的主要工作，这一工作需要与数据存储、摄入、传输、准备和管道互操作。安全性、元数据管理、治理和保护的特性是必不可少的。数据访问是通过支持查询、API和数据服务来提供的。

第三代数据管理带来了新的能力，并将人工智能和机器学习的力量用于数据管理。它解决了在数据湖世界中管理的许多挑战。它是完美的吗?我真的很怀疑，但随着产品目录、数据中心和数据结构的不断成熟，我们会看到进步。它是最终状态吗?我认为这也不太可能。在数据管理的发展过程中还会有更多的事情发生。

超越第三代数据管理-下一代是什么

下图说明了上面描述的三代数据管理架构和实践。这显然是一个渐进的过程，每一次能力的进步都会带来新的挑战，需要更多的创新。我认为这是过去、现在和不久的将来;第一代已经过去，第二代已经过去，第三代即将到来。不久的将来我们会看到什么呢?

作为数据结构的逻辑扩展，第四代数据管理将提供自我驱动的数据管理功能。无人驾驶汽车几乎肯定会重塑交通的世界。自动驾驶汽车知道自己的位置和目的地，可以导航、避免碰撞，并在需要维修或其他帮助时发出警报。自动驾驶汽车为重塑数据传输和数据管理的世界提供了一个很好的隐喻。与自动驾驶汽车类似，自我驱动的数据知道自己的位置和目的地，可以导航数据管道，并可以将数据传递到任何需要的地方。在输入的时候，数据会自动地从着陆区通过数据湖、数据仓库、分析应用程序、仪表板、记分卡、报告以及任何可能需要的地方在生态系统中移动。在整个过程中，将自动应用正确的集成、转换和标记。