行业专家最近写了一篇文章，揭露了关于数据湖架构、数据湖定义和数据湖分析的常见误区。其文章名为“什么是数据湖?需要来避免最大的迷思。”在那篇文章中，构建了有关数据湖及其在企业数据策略中的适用范围的当前对话。对于那些希望从数据湖中获取价值的人来说，由于顾问和供应商的建议相互矛盾，这个主题历来是令人困惑和不透明的。

一个可能特别令人困惑的领域是人们认为数据湖仅用于“大数据”。如果花时间阅读湖泊上的资料，就会认为只有一种类型。人们将数据湖描述为庞大的、无所不包的实体，旨在容纳所有知识。好消息是，湖泊不仅仅用于“大数据”，而且比以往任何时候都有更多的机会将其纳入数据堆栈。

不同类型的数据湖

就像大自然一样，湖泊具有各种不同的形状和大小。每个都有自然状态，通常反映数据生态系统，就像自然界中反映鱼类，鸟类或其他生物的生态系统一样。

不幸的是，“大数据”角度给人们的印象是湖泊仅用于“里海”规模的数据工作。这无疑使使用数据湖变得令人生畏。因此，以如此大的角度来描述事物使得那些可以从中受益的人们无法接近湖泊的概念。这里有一些数据湖的例子。

伟大的“里海”：就像里海是一个大水域一样，这种类型的湖泊也是一个庞大而广泛的，种类繁多的数据集。广泛收集的各种数据反映了整个企业的信息。这就是大多数数据湖工作的框架。

暂时的“湖泊”：就像沙漠中可以有小的临时湖泊一样，短暂的短暂存在。它们可以用于项目、试点、PoC或点解决方案，并且它们的打开与关闭速度一样快。

领域“项目”：这些湖泊与临时数据湖泊一样，通常侧重于特定的知识领域。但是，与临时湖不同，该湖将随着时间的推移而持续存在。这些也可能是“浅”的，这意味着它们可能专注于狭窄的数据域，例如媒体、社交、Web分析、电子邮件或类似的数据源。

最近，与客户合作创建了“域”型湖泊。该湖会将Adobe事件数据保存到AWS，以支持企业Oracle Cloud环境。为什么选择AWS to Oracle?对于客户的OracleBI环境，这是一种高效且具有成本效益的数据消耗模式，尤其是考虑到使用AWS Lake和Athena作为湖内容的按需查询服务的敏捷性和经济性。

通过设计，所有类型的湖泊都应采用抽象技术，以最大程度地降低风险并为您提供更大的灵活性。而且，它们的结构应易于使用，而与大小无关。这确保了数据科学家，业务用户或分析师所使用的湖泊都具有易于数据使用的结构化环境。

数据湖入门

成为成功的早期采用者意味着采取业务价值方法而不是技术方法。当组织考虑如何入门时，这里有一些提示：

重点：寻找机会，在其中部署“临时”或“项目”解决方案。这将确保您降低风险并克服技术和组织挑战，以便您的团队可以对湖泊建立信心。

热情：确保内部有一位“传道者”或“倡导者”，他们对组织的解决方案和采用充满热情。

简单：拥护简单性和敏捷性，使人员、流程和技术选择贯穿于此。缺乏复杂性不应被看作是缺陷，而是周到的设计的副产品。

狭义：通过限制湖泊来理解数据(例如从ERP、CRM、销售点、市场营销或广告数据中导出)来使范围狭窄且定义明确。此阶段的数据素养将帮助您了解有关数据结构、提取、治理，质量和测试的工作流。

实验：将数据湖与现代BI和Tableau、Power BI、Amazon Quicksight或Looker等分析工具配对。这将使非技术用户有机会通过湖泊进行实验和探索数据访问。这使组织可以与其他用户群互动，以评估性能瓶颈，发现改进机会，与任何现有EDW系统(或其他数据系统)的可能链接以及其他候选数据源。

关注业务价值而不是技术，可以为组织提供一个在整体数据和分析策略的框架内进行工作的机会。这样可以提高速度，并帮助组织实现数据湖目标并衡量业务绩效的进度。这也导致了完善的共享术语、最佳实践以及对建立更好平台的投资。