架构师可以选择一个主要的云服务提供商和/或Hadoop系统来存放他们的数据。移动、转换、编目和管理数据则是另一回事，因此架构师在全力寻找驯服信息结构的解决方案后，来找我，他们认为自己一定遗漏了什么:“难道没有单一的平台吗?他们问。

很遗憾,没有。只有最佳的工具或数据管理平台处于过渡阶段。

这背后是有历史的。数据管理中间件公司往往规模相对较小。IBM、Oracle和SAP等信息管理供应商挑选了一些较小的数据管理供应商，并将其产品作为解决方案添加到其整体平台组合中，以作为其大数据和云系统的推动者进行销售。随着市场转向大数据和云计算等新架构，小型供应商没有资金先发制人地建立能力。大型供应商解决了80%的企业依靠传统可靠技术运营业务的规则。因此，数据管理和治理已经落后于大数据和云趋势。最终，两家供应商都采取了观望策略，只有当客户开始表现出更高的兴趣时(在RFI/RFP中)，才会构建功能和重新架构解决方案。

我们的Forrester Wave™评估记录了这个故事。正如Forrester所看到的，2011年50%的公司都在构建Hadoop数据湖，而分析/BI很快就转移到了云端，我们Waves中的数据管理供应商才刚刚开始弄清楚如何在这些环境中工作，并在2015年在本地运行。即使在今天，许多供应商仍然提供一种内部部署工具和另一种云工具。更新的可能只能在云中运行。

风险投资家和私募股权公司很早就开始投资大数据初创公司。但是，当已经有一个用于摄取、管道、安全性和元数据的开源工具的完整市场时，很少有初创公司出现。钱在哪里呢?因此，市场转向了机器学习的更性感的价值主张，投资者的资金也随之而来。当你有洞察时，为什么还要关心数据呢?

企业关心的是数据。他们总是这样，而且总是这样。这是一个组织中最大的技术和人才债务领域。大数据湖的失败和物联网、人工智能等扩展系统领域的停滞，都源于滞后的数据基础。这是一种本末倒置的情况。

“太好了!你说。“很好的历史课。那么我们该怎么做做?”

认识新工具的本质。忽略应用于产品名称和优惠的平台和解决方案标签。可用的是针对特定数据用例的松散整合功能。商业产品中存在完整解决方案的潜力。用户界面和体验比开源更好。存在更多的通信和协作功能。供应商知道法规遵从性和安全支持对于任何企业都是非常重要的。如果没有领先的云和Hadoop平台的连接器，或者领先的BI和业务应用程序，这是一个交易破坏者。获取这些工具的基准策略归结为了解用户及其流程、元数据存储库的开放性和订阅模型。最终，你需要解决今天的问题，给自己成长的空间(看看我的同事Noel Yuhanna刚刚发表的文章能否经得住时间的考验)．您将尽早重构您的平台。

现在，以下是您需要了解的主要数据管理工具:

  • 元数据管理。您将需要两到三个数据目录:一个用于物理和逻辑元数据管理，数据工程师需要构建和管理系统;一个用于数据管理员管理逻辑元数据、语义和数据策略;可能还有第三个数据目录，它支持BI分析师和数据科学家使用数据的搜索和消费功能，如果数据管理员的数据治理目录不能完成工作的话。是的，Collibra、EDQ和Informatica是共同的伙伴。在Hadoop生态系统中使用Navigator或Atlas的Alation对于数据湖来说也并不罕见。
  • 主数据管理。通常会运行传统的基于关系的MDM工具来支持系统之间复杂的数据映射。它位于数据库和集成的核心。然后，当逻辑模型需要更多准备和转换为语义模型或业务模型时，基于图的MDM可以处理更接近BI和业务应用程序系统的客户和产品的复杂视图。然后是数据虚拟化和Kafka内部的DIY MDM，它为BI视图、微服务和esb提供数据模型和映射。
  • 数据集成。这就是有趣的开始，因为ETL、数据虚拟化、数据总线、流、复制、摄取工具和数据准备都独立存在或在集成的管道中。工作负载模式定义了使用哪些数据集成工具，以及在数据流或生态系统(云/本地)中需要这些工具的位置。您的数据体系结构采用与事务、业务流程、自动化、分析和分析(OLAP)以及操作(OLTP)工作负载一致的引用模式。参考体系结构首先是为数据流设计的，而不是传统意义上的数据源。
  • 数据分析和沿袭。独立或嵌入式-选择。但关键是，如果概要分析和沿袭分析是嵌入式的，那么它很可能是面向基本解决方案的。用于元数据和数据源捕获的存储库配置文件。用于逻辑和业务元数据以及源沿袭的数据治理工具概要。用于物理和逻辑元数据、数据关系和源沿袭的数据目录概要。有些可能会分析数据流元数据。独立工具往往侧重于元数据、模型、沿袭和用于根本原因分析的数据流分析。要注意谁将使用该工具，他们需要知道什么，以及为了理解数据，所有数据职责都必须进行概要分析和沿袭分析。