一、什么是敏捷数据湖
“数据湖”是当前很多人、很多企业都在谈论的最新流行的话题之一。可是，让我们认真想一想，数据湖是不是像许多流行的IT词一样，很少有人真正知道如何解释它，能够实现什么价值以及如何设计和构建它。尽管看起来数据湖就像普遍项目一样，但我们会惊讶地发现Gartner预测只有15％的Data Lake项目投入生产。Forrester预测，将有33％的企业将放弃数据湖项目。这个数字让人很震惊！数据湖是关于从企业数据中获取价值的，而根据这些统计数据，它的必杀技似乎很难捉摸。我想改变这一点并分享我的想法，并希望就如何设计，构建和使用成功的Data Lake提供一些指导，供大家参考。这就是要构建敏捷的数据湖。为什么要敏捷？因为必须要成功。
首先，让我们看一下Wikipedia对数据湖的定义：
“数据湖是一种存储存储库，它以原始格式保存大量原始数据，包括结构化、半结构化和非结构化数据。”
但是考虑到我们需要从Data Lake中获得价值，因此Wikipedia的定义还不够。为什么？原因很简单；您可以将任何数据放入湖泊中，但是您需要将数据取出，这意味着必须存在某种结构。数据湖的真正想法是在一个地方存储所有企业数据，范围从原始数据（这意味着源系统数据的精确副本）到转换后的数据，再用于各种业务需求，包括报告，可视化，分析，机器学习，数据科学等等。
我喜欢Amazon Web Services首席布道者Tamara Dull的“修订”定义，他说：
“ 数据湖是一个存储库，它以原生格式存储大量的原始数据，包括结构化、半结构化和非结构化数据，这些数据的结构和需求在需要数据时才被定义。”
这样的定义就好多了！甚至代表敏捷。之所以定义更好，是因为它既包含了数据结构的先决条件，又将在将来的某个时候以某种方式使用存储的数据。从中我们可以放心地期望她的价值，并且采用敏捷方法是必要的。 因此，数据湖包括来自关系数据库的结构化数据（基本行和列），半结构化数据（如CSV，日志，XML，JSON ），非结构化数据（电子邮件，文档，PDF ）甚至二进制数据（通常为 图像，图片） （音频和视频），从而创建一个容纳所有形式数据的集中式数据存储。 然后，数据湖提供了一个数据平台，可以在需要时在其上为业务用例提供服务。数据进入湖泊是不够的，数据也必须在需要的时候以正确的姿势出来。
并且，我们要避免“数据沼泽”，数据沼泽是一个恶化的和不受管理的数据湖，其目标用户无法访问和使用，从而给企业提供的业务价值很小甚至没有。
二、数据湖的形成
在我们深入讨论之前，我想分享一下我们是如何走到这一步的。数据湖代表了数据爆炸(容量变化速度)、历史业务应用程序的增长以及大量的新数据源(物联网、WSL、RSS、社交媒体等)、以及从内部架构到云(和混合)的移动所带来的发展。此外，业务流程变得更加复杂，最近引入了增强业务洞察力和数据挖掘的新技术，还以机器学习和数据科学等新方式探索数据。。在过去的30年中,我们已经看到了数据仓库开创性的实现的商业智能报告直到现在我们将看到的敏捷数据湖支持的多种业务用例的实现。
对我们来说，Data Lakes代表了这种惊人的数据演变的结果，最终应该提供可以在本地，云或混合生态系统中部署的通用基础数据仓库体系结构。
成功的数据湖是基于模式的，元数据驱动的业务数据存储库，满足了数据治理和数据安全的要求。湖中的数据应呈现合并的数据和“真相记录”的汇总，以确保数据的准确性和及时性。遵循敏捷方法论，使用元数据管理，应用数据概要分析，主数据管理等，我认为Data Lake必须代表“全面质量管理”的数据系统。
三、数据湖有什么用
本质上，数据湖用于企业应用程序下游的任何以数据为中心的业务用例，有助于推动企业洞察力和运营效率。以下是一些常见示例：
■商业信息，系统集成和实时数据处理；
■报表，仪表盘和分析；
■业务洞察力，数据挖掘，机器学习和数据科学；
■客户，供应商，产品和服务的360度视图。
四、如何构建敏捷数据湖
您如何构建敏捷数据湖？我们知道，成功的Data Lake可以给企业带来很多种好处。我的问题是，您是否考虑其中的一种？我敢打赌，你一定考虑过。我的下一个问题是；你知道怎么实现吗？您是否能够以正确的方式构建Data Lake并避免沼泽？我认为您正在阅读以了解更多信息。让我们继续...
我相信有三个关键原则你必须首先理解和接受:
⇒正确的实施生态系统，数据模型，体系结构和方法论
⇒卓越的数据处理，治理和安全性的结合
⇒有意识的使用工作设计模式和最佳实践
一个成功的数据湖还必须是敏捷的，它将成为数据处理和信息交付机制，用于增强业务决策和增强领域知识。因此，数据湖必须有一个被管理的生命周期。这个生命周期包含3个关键阶段:
1、数据提取：
提取原始源数据，在着陆区或暂存区中存储（通常写入平面文件中）以进行下游处理和存档。
2、数据适配：
将此数据加载并转换为可用格式，以供业务用户进一步处理和使用。
3、数据消费：
■数据聚合（KPI，数据点或指标）；
■数据分析（事实，预测和趋势）；
■机器学习，数据挖掘和数据科学；
■操作系统反馈和出站数据提要；
■可视化和报告。
我们的挑战在于如何避免数据沼泽。我相信您必须使用正确的架构，数据模型和方法。您确实必须放弃“传统”思维；适应并采用“现代”方法。这是必不可少的。在考虑了这些关键点之前，不要陷入以为知道数据湖是什么以及它如何工作的陷阱。
接下来，让我们再检查这三个阶段。
数据摄取是指捕获、管理数据，并为后续处理做好准备。我认为这就像一箱一箱的数据，倾倒在沙滩上的湖;着陆区称为“持久集结区”。持久，因为一旦到达，它就会留在那里；出于所有实际目的，一旦在下游进行处理，它就会成为有效的存档（并且您不必将其复制到其他地方）。该PSA将包含数据、文本、声音、视频或任何存储的内容。
你可能会注意到，我说的还不是技术。但是，让我至少指出，取决于PSA使用的技术，你可能需要在某个点卸载这些数据。我的想法是，一个有效的文件存储解决方案最适合这个第一阶段。
数据适配是数据的一种全面的、智能的结合，必须有机地适配才能生存和提供价值。这些调整采取了几种形式(我们将在下面介绍)，但本质上首先存储于原始的、最低级别的颗粒化和数据模型中，然后可以针对各种领域用例进行进一步处理，用于业务目的。这里的数据处理要求可能非常复杂，所以我希望尽可能地将其自动化。自动化需要元数据支撑，如果元数据需要治理，别忘了安全。
数据消费不仅仅与业务用户有关，它还与业务信息、业务支持的知识以及从中获得的智慧有关。你们可能对DIKW金字塔很熟悉;数据，信息，知识，智慧。我喜欢在“知识”后面加上“理解”，因为它引导智慧。
数据应被视为企业资产，并作为企业资产进行投资。数据就变成了一种商品，让我们专注于从数据中获得的信息、知识、理解和智慧。因此，它是关于数据和从数据中获取价值的。
1、数据存储系统：数据存储
当我们继续为构建数据湖奠定基础时，让我们看看如何存储数据。我们有很多方法可以做到这一点。
■数据库引擎：
行：传统的关系数据库系统（RDBMS） （即：Oracle，MS SQL Server，MySQL等）
列：相对未知；感觉就像是RDBMS，但针对列进行了优化 （nowflake, Presto, Redshift, Infobright等）
■NoSQL –“不仅仅是SQL”：
非关系式，最终的一致性存储和检索系统 （即：Cassandra，MongoDB等）
■HADOOP：
支持高数据量，速度和多样性的分布式数据处理框架 （即：Cloudera，Hortonworks，MapR，EMR和HD Insights）
■GRAPH –“三重存储”：
Subject-Predicate-Object，无索引的“三元组”；基于图论 （即：AlegroGraph和Neo4J）
■文件系统：
其他所有内容 （例如：ASCII / EBCDIC，CSV，XML，JSON，HTML，AVRO，Parquet）
存储数据的方法有很多，需要考虑很多因素，因此让我们简化一下，并将其称为“数据存储”，无论它们是源数据，中间数据，归档数据还是目标数据存储。只需根据需要为每种类型的数据存储选择技术。
2、数据治理
什么是数据治理？显然，另一个行业之谜。维基百科又来帮忙了：
“数据治理 是组织要遵循的已定义过程，以确保在整个生命周期中都存在高质量的数据。”
有帮助吗？我不这么认为。数据治理的真正想法是确认数据为公司资产，在整个企业范围内对其进行正式投资和管理，因此可以信赖它进行负责任的可靠决策。为了实现这些崇高的目标，至关重要的是要通过目标血统来管理源头。此血统的管理是数据治理的关键部分，应进行良好定义和谨慎的管理。血统管理划分为3个层面：
⇒图解谱系维护有关数据结构的元数据
⇒语义谱系维护有关数据含义的元数据
⇒数据沿袭保留了数据起源的元数据及其可审计性，因为它可以更改，从而允许“当前”和“及时”查询
可以说，关于数据治理，元数据管理，数据准备，数据管理和数据词汇表的适当，深入的讨论是必不可少的，但是如果我这样做了，我们将永远无法完结此文，以后我们在继续就每个领域展开讨论。
3、数据安全
Data Lakes还必须确保数据的安全性，并可根据要求将其删除（禁用）或更新。 保护数据需要访问策略，策略实施，加密和记录维护技术。 实际上，所有公司数据资产都需要这些功能，这些功能应成为任何Data Lake实施的基础。这里要考虑三种数据状态：
⇒静止数据，某些数据存储中不变的，可在整个数据湖生命周期中使用
⇒运动数据，数据在数据湖生命周期本身中移动
⇒面向用户的数据，在数据湖生命周期中可能是最关键的数据
4、敏捷Data Lake技术选择
处理数据进出数据湖需要技术(硬件/软件)来实现。面对如此之多的选择是令人畏惧的。我们很容易把这些想当然，挑出任何听起来不错的东西。只有在更好地理解所涉及的数据、选择的系统和开发工作之后，才会发现做出了错误的选择。这不是数据沼泽的定义吗?我们如何避免这种情况?
一个成功的数据湖必须包含灵活的体系结构、数据模型和方法。我们已经讨论过了，但是选择正确的“技术”更多的是关于业务数据需求和预期的用例。您可以将数据湖设计从技术堆栈中分离出来。为了说明这一点,这是一个“Marketecture”图描绘了许多不同的技术选项穿越敏捷数据湖架构。
如上所示，有许多流行的技术可用，您可以选择不同的功能来适应数据湖生命周期的每个阶段。Dan Linstedt创建了这种方法，并且已经编写了很多有益的内容。我推荐大家读读以下这些链接：
- 数据保管库的简要历史
- Data Vault 2.0简介
- 定义数据湖
- Data Lake第2部分：参考数据架构
- 定义数据湖第3部分：着陆区
- 定义数据湖：第4部分数据仓库与数据湖
- 定义数据湖：第5部分–我们是否需要数据湖？
- 定义数据湖：第6部分– CDC和集成
希望所有这些内容对您有所帮助。是的，要吸收，消化和理解很多东西（听起来像是数据湖），但要花些时间。如果您认真考虑构建和使用成功的数据湖，则需要此信息。
5、敏捷数据湖生命周期
上面我们提到数据湖有一个生命周期。一个成功的敏捷数据湖生命周期包含了我上面描述的三个阶段，即数据存储，数据治理，数据安全，元数据管理，当然还有“业务规则”。注意，我们要做的是将“硬”业务规则（以某种方式转换物理数据）与“软”业务规则（基于适应的查询调整结果集）分离。这种分离有助于实现敏捷的生命周期。
考虑一下，如果将物理数据转换推向上游，那么当不可避免的变化发生时，对下游所有事物的影响就会减小。另一方面，当业务动态施加新标准时，在下游更改SQL'where'子句将对其提取的数据模型的影响较小。Business Vault提供了与Raw Data Vault的隔离，因为在发生重大变化时可以对其进行重构。
此外，Data Lake不是数据仓库，而是实际上将其封装为一个用例。我们不再创建“数据集市”，我们想要“信息集市”。您是否查看了我上面提到的DIKW金字塔链接。当然，应该将数据视为业务资产。然而，与此同时，数据现在已成为一种商品，它将我们带到了信息，知识和希望中：智慧。
此图详细说明了从源数据存储到目标数据存储的敏捷数据湖生命周期。我最后要说的是，要实现敏捷，数据湖必须：
■适应性强
当新的数据源出现时，数据模型应该是附加的，而不影响现有的模型
■只能插入
特别是对于大数据技术,更新和删除是昂贵的
■提供可伸缩的选项
混合基础设施可以提供广泛的能力
■允许自动化
元数据在许多方面可以驱动数据移动的自动化
■提供可审核的历史数据
数据沿袭的一个关键方面
最后，请考虑星型模式一直被设计为“信息交付机制”，这是业界多年来一直存在的一种误解。多年来，我们都使用星型模式构建数据仓库来交付报告和业务洞察力。这些工作常常导致数据仓库以严格的数据结构存储原始数据，需要进行大量的数据清理，并且在更改或添加上游系统时产生很大的影响。
资源和预算的成本是许多延迟、失败的项目和不准确的结果的主要原因。这是一种传统的心态，我相信现在是时候将我们的思维转向一种更现代的方式了。敏捷数据湖是一种新的思维方式。星型模式不会消失，但是它们的角色已经转移到了下游。
五、写在最后
这仅仅是开始，但是我希望这篇文章能使您考虑所有可能性。
作为一种通用技术，再加上完善的体系结构，灵活的数据模型，强大的方法论，周到的工作设计模式和最佳实践，不仅可以创建一个敏捷数据湖，而且还可以避免数据沼泽！
