数据湖不仅适用于大数据
数据湖不仅仅适用于“大数据”，而且您拥有比以往更多的机会让它们成为数据堆栈的一部分。
揭述了关于数据湖架构，数据湖定义和数据湖分析的常见误解。它被称为“为什么数据湖？为了避免最大的神话而站起来”。在那篇文章中，我们构建了当前关于数据湖的对话以及它们如何适应企业数据策略。对于那些希望从数据湖获取价值的人来说，由于顾问和供应商的建议相互矛盾，这个主题一直令人困惑和不透明。
一个特别令人困惑的领域是人们认为湖泊仅仅是“大数据”。如果你花时间阅读湖泊上的材料，你会认为只有一种类型，它看起来像海洋海洋（它是一个湖，尽管名称中有“海”）。人们将数据湖描述为庞大的，无所不包的实体，旨在掌握所有知识。好消息是，湖泊不仅仅是“大数据”，而且你有更多的机会让它们成为数据堆栈的一部分。
有不同类型的数据湖
正如他们在自然界中所做的那样，湖泊有各种不同的形状和大小。每个国家都有一个自然状态，通常反映数据生态系统，就像自然界反映鱼类，鸟类或其他生物的生态系统一样。
不幸的是，“大数据”角度给人的印象是湖泊仅用于“里海”规模数据的努力。这无疑使数据湖的使用变得令人生畏。因此，以如此大规模的方式描述事物使得湖泊的概念对于那些可以从较小规模受益的人来说是不可接近的。以下是一些数据湖示例;
伟大的“里海”：就像里海是一个巨大的水域，这种类型的湖泊是一个庞大，广泛的存储库 - 多样化的数据集。这些广泛的各种数据集合反映了整个企业的信息。这就是大多数数据湖工作的框架。
临时“短暂”：就像沙漠可以拥有小型临时湖泊一样，短暂存在短暂的时间。它们可以用于项目，飞行员，PoC或点解决方案，并且可以在打开时尽快关闭。
领域“项目”：这些湖泊，如短暂的数据湖泊，通常专注于特定的知识领域。然而，与Ephemeral湖不同，这个湖将持续一段时间。这些也可能是“浅薄的”，这意味着它们可能集中在狭窄的数据领域，如媒体，社交，网络分析，电子邮件或类似的数据源。
我们最近与一位客户合作创建了一个“Domain”型湖泊。该湖将 Adobe事件数据保存到AWS以支持企业Oracle云 环境。为什么AWS到Oracle？对于客户Oracle BI环境而言，这是一种高效且经济高效的数据消费模式，特别是考虑到使用AWS湖和Athena作为湖内容的按需查询服务的灵活性和经济性。
按照设计，所有类型的湖泊都应该采用抽象方式，将风险降至最低，并为您提供更大的灵活性。此外，它们的结构应易于消费，与其大小无关。这确保了数据科学家或业务用户或分析师使用的湖泊都具有易于数据消费的环境。Data Lakes入门
成为一个成功的早期采用者意味着采用商业价值方法而不是技术方法。在您考虑如何入门时，以下是一些提示：
重点：寻找可以部署“短暂”或“项目”解决方案的机会。这将确保您降低风险并克服技术和组织方面的挑战，以便您的团队建立对湖泊的信心。
激情： 确保你内部有一个“传道者”或“倡导者”，一个对公司内部的解决方案和采用充满热情的人。
简单：拥抱简洁和敏捷，通过这个镜头选择人员，流程和技术。缺乏复杂性不应被视为缺陷，而是经验丰富的设计的副产品。
缩小：通过限制湖泊来理解数据，比如ERP，CRM，销售点，营销或广告数据的出口，保持范围狭窄和明确定义。此阶段的数据素养将帮助您了解有关数据结构，摄取，治理，质量和测试的工作流程。
实验： 将您的湖与现代BI和分析工具（如Tableau，Power BI，Amazon Quicksight或Looker）配对。这将使非技术用户有机会通过湖泊进行实验和探索数据访问。这使您可以使用不同的用户群来评估性能瓶颈，发现改进机会，可能与任何现有EDW系统（或其他数据系统）的链接以及其他候选数据源。
专注于业务价值而非技术，使您有机会在整体数据和分析战略的背景下构建您的工作。这可以提高速度，帮助您实现数据湖目标并衡量业务绩效的进度。这也导致细化共享术语，最佳实践以及对构建更好平台的投资。
