让我们从数据湖的标准定义开始：
数据湖是一个存储库，它以原生格式保存大量原始数据，包括结构化，半结构化和非结构化数据。 在需要数据之前，不会定义数据结构和要求。
你为什么要关心？
革新
在大型企业中，数据湖最强大的影响可能是创新的实现 。 我们已经看到许多数十亿美元的组织正在努力建立数据驱动的洞察力和创新文化。 它们被孤立于部门或分区划分的数据存储的结构孤岛所困扰，并且这些结构孤立于围绕数据所有者的大规模组织政治。 企业数据湖虽然远非微不足道，但它提供了从根本上清除企业级数据访问问题的必要基础。 以前无法进行探索性分析和数据挖掘的大门打开了，实现了全新的可能性。
速度
在当今动态的业务环境中，新的数据消费需求和用例非常迅速地出现。 在准备需求文档以反映对数据存储或模式的请求更改时，用户经常转向不同甚至相互矛盾的模式更改集。 相比之下，数据湖的整个理念围绕着为未知用例做好准备。 当源数据位于一个中心湖中时，其中没有嵌入单一控制结构或模式，支持新的附加用例可以更加简单。
自助服务
对报表的IT请求与最终在组织中发布健壮的工作报表之间的平均时间是多少？ 在太多的情况下，答案是在几周甚至几个月内测量的。 通过设计合理的数据湖和训练有素的商业社区，人们可以真正实现自助式商业智能。 允许业务人员访问他们需要的所有数据，让他们使用各种工具开发他们想要的报表。 IT成为云上基础架构和数据的保管人，而业务则负责探索和挖掘云。
图1：Data Lake存储层
设计物理存储
任何数据湖设计和实现的基础都是物理存储。 核心存储层用于主要数据资产。 通常，它将包含原始和/或轻度处理的数据。 评估基于云的数据湖存储技术时的关键考虑因素是以下原则和要求：
出色的可扩展性
由于企业数据湖通常旨在成为整个部门或整个公司的集中式数据存储，因此它必须能够进行大规模扩展，而不会遇到固定的任意容量限制。
高耐用性
作为关键企业数据的主要存储库，核心存储层的高耐用性可实现出色的数据稳健性，而无需采用极高的可用性设计。
支持非结构化，半结构化和结构化数据
数据湖的主要设计考虑因素之一是能够将所有类型的数据存储在单个存储库中。
独立于固定架构
只有在底层核心存储层没有规定固定模式时，才能根据每个消费目的的需要在读取时应用模式。
与计算资源分离
与Hadoop上的“遗留”大数据存储相比，基于云的数据湖最重要的哲学和实践优势是能够将存储与计算分离，从而实现每个存储的独立扩展。
鉴于这些要求，基于对象的商店已成为核心数据湖存储的事实上的选择。 AWS，Google和Azure都提供对象存储技术。核心存储的重点是集中所有类型的数据，几乎没有强加于它的模式结构。 但是，数据湖通常在核心存储之上具有额外的“层”。 这允许保留原始数据本质上是不可变的，而附加层通常会添加一些结构，以便有助于有效的数据消耗，例如报告和分析。 图1表示在原始存储层顶部添加的附加层。
这个的一个具体例子是添加由Hive Metastore定义的层。 在诸如此类的层中，对象存储器中的文件被划分为“目录”，并且由Hive聚类的文件被安排在其中以增强图2中所示的访问模式。
关于这个例子，可以写得更多; 可以说，可以根据所需的消费模式实施许多附加的分层方法。
图2：使用Hive群集的分区对象存储
选择文件格式
介绍
来自传统RDBMS世界的人们常常对我们作为数据湖的架构师对于如何存储数据的超常控制感到惊讶。 与RDBMS存储引擎相反，我们可以确定一系列元素，例如文件大小，存储类型（行与列），压缩程度，索引，模式和块大小。 这些与面向Hadoop的工具生态系统有关，这些工具通常用于访问湖中的数据。
文件大小
一个小文件是一个明显小于Hadoop文件系统（HDFS）默认块大小的文件，即128 MB。 如果我们存储小文件，考虑到数据湖的大量数据，我们最终会得到大量文件。根据经验，每个文件都表示为群集名称节点内存中的一个对象，每个文件占用150个字节。 因此，每个使用一个块的1亿个文件将使用大约30千兆字节的内存。 需要注意的是，Hadoop生态系统工具并未针对有效访问小文件进行优化。 它们主要用于大文件，通常是块大小的偶数倍。
Apache ORC
ORC是为Hadoop工作负载设计的突出的列式文件格式。 通过列式文件格式化，可以只读取，解压缩和处理当前查询所需的值。 虽然有多种可用的列式格式，但许多大型Hadoop用户都采用了ORC。 例如，Facebook使用ORC在其数据仓库中节省数十PB。他们还证明了ORC明显快于RC File或Parquet。 雅虎还使用ORC存储他们的生产数据，并同样发布了一些基准测试结果。
相同数据，多种格式
很可能一种类型的存储结构和文件格式针对特定工作负载进行了优化，但不太适合另一种工作负载。 在这样的情况下，鉴于存储成本低，实际上非常适合使用不同的底层存储结构（分区，文件夹）和文件格式（例如ORC vs Parquet）创建相同数据集的多个副本。
设计安全
与每个基于云的部署一样，企业数据湖的安全性是关键优先事项，必须从一开始就设计好。 此外，只有在企业的整体安全基础架构和控制框架内部署和管理数据湖的安全性，才能取得成功。 从广义上讲，有三个与数据湖部署相关的主要安全域：
- 加密
- 网络级安全性
- 访问控制
加密
实际上，每个企业级组织都要求对存储数据进行加密，如果不是普遍的话，至少对于除公开数据之外的大多数数据分类。 默认情况下，所有领先的云提供商都支持对其主要对象存储技术（例如AWS S3）进行加密。 同样，用于其他存储层的技术（例如用于消费的衍生数据存储）通常也提供加密。
加密密钥管理也是一个重要的考虑因素，其要求通常由企业的整体安全控制决定。 选项包括由云提供商创建和管理的密钥，由云提供商管理的客户生成密钥，以及由内部客户完全创建和管理的密钥。
最后的相关考虑因素是加密传输。 这包括在设备和服务之间通过网络传输的数据。 在大多数情况下，可以使用每个服务的内置选项或使用带有相关证书的标准TLS / SSL轻松配置。
网络级安全性
另一个重要的安全层位于网络级别。 诸如安全组之类的云原生构造以及包括网络ACL和CIDR块限制在内的传统方法都在实施强大的“纵深防御”战略中发挥作用，通过阻挡大量不适当的访问路径。网络层面。 此实现还应与企业的整体安全框架保持一致。
访问控制
这侧重于身份验证（你是谁？）和授权（你可以做什么？）。 事实上，每个企业都将拥有标准的身份验证和用户目录技术; 例如，Active Directory。 每个领先的云提供商都支持将企业身份基础架构映射到云提供商的资源和服务的权限基础架构的方法。 虽然涉及的管道可能很复杂，但是与云提供商的访问管理基础架构（例如AWS上的IAM）相关联的角色可由经过身份验证的用户使用，从而实现对授权操作的细粒度权限控制。 对于在云中运行的第三方产品（例如报告和BI工具），通常也是如此。 通常支持LDAP和/或Active Directory进行身份验证，并且工具的内部授权和角色可以与经过身份验证的用户身份相关联并由其驱动。
建立治理
通常，数据治理是指对企业中使用的数据的可用性，可用性，完整性和安全性的整体管理。 它依赖于业务策略和技术实践。 与任何云部署的其他描述方面类似，企业数据湖的数据治理需要由整个组织的总体实践和策略驱动并与之一致。
在传统的数据仓库基础架构中，对数据库内容的控制通常与业务数据保持一致，并按业务单位或系统功能分为孤岛。 但是，为了获得集中组织数据的好处，它相应地需要集中查看数据治理。
即使企业的数据治理实践还不完全成熟，至少要实施一套最小控制措施至关重要，这样在没有定义重要元数据（“数据数据”）的情况下，数据无法进入湖泊和捕获。 虽然这部分取决于早期“设计物理存储”部分中描述的元数据基础架构的技术实现，但数据治理还意味着业务流程确定了所需的关键元数据。 同样，与完整性，准确性，一致性和标准化等概念相关的数据质量要求实质上是必须首先制定的业务政策决策，然后才将这些决策的结果烘焙到实际执行这些要求的技术系统和流程中。
用于在数据湖实施中实施数据治理策略的技术通常不是单独的产品或服务。 更好的方法是期望将遵守数据治理要求的需要嵌入到整个数据湖基础架构和工具中。
启用元数据编目和搜索
主要考虑因素
任何数据湖泊设计都应该包含元数据存储策略，以使业务用户能够搜索，定位和了解湖中可用的数据集。 传统数据仓库在关系存储层中存储固定和静态的一组有意义的数据定义和特征，而数据湖存储旨在灵活地支持在读取时应用模式。 但是，这意味着需要一个单独的存储层来存放代表技术和业务含义的编目元数据。 虽然组织有时只是在没有元数据层的数据湖中累积内容，但这肯定会创建一个难以管理的数据沼泽，而不是一个有用的数据湖。 有许多方法和解决方案可确保创建和维护适当的元数据。 以下是一些要记住的重要原则和模式。
实施元数据要求
确保创建适当元数据的最佳方法是强制创建。 确保数据到达核心数据湖层的所有方法都强制执行元数据创建要求，并且任何新的数据提取例程都必须指定如何强制执行元数据创建要求。
自动化元数据创建
与云中的几乎所有内容一样，自动化是一致性和准确性的关键。 尽可能设计从源材料中提取的自动元数据创建。
优先考虑云原生解决方案
尽可能使用云原生自动化框架来捕获，存储和访问数据湖中的元数据。 图3中列出了通常为数据源编目的核心属性。
图3：用于Data Lake元数据存储的AWS建议架构
基于AWS的解决方案理念
AWS建议使用简单解决方案的示例，其中包括在S3上创建数据对象时触发AWS Lambda函数，并将数据属性存储到DynamoDB数据库中。 生成的基于DynamoDB的数据目录可以由Elasticsearch编制索引，允许业务用户执行全文搜索。
AWS Glue提供了一组自动化工具来支持数据源编目功能。 AWS Glue可以使用针对许多常用源格式和数据类型的预构建分类器来抓取数据源并构建数据目录，包括JSON，CSV，Parquet等。 因此，这为企业实施提供了潜在的希望。
我们建议客户将数据编目作为数据湖实施的核心要求。 
图4：数据湖层和消费模式
进入并挖掘湖泊
Schema on Read
'架构上的架构'是在数据存储在“结构化”关系数据库之前，经过仔细检查的模式，用于清理，转换和添加逻辑架构。 但是，如前所述，数据湖建立在完全不同的“读取模式”模式上，可防止主数据存储被锁定到预定模式中。 数据以原始或仅温和处理的格式存储，并且每个分析工具可以在数据集上施加适合于分析上下文的业务含义。 这种方法有许多好处，包括使各种工具能够出于各种目的访问数据。
数据处理
在湖中拥有不可变数据的原始层后，您将需要创建多层处理数据以在组织中启用各种用例。 这些是前面描述的结构化存储的示例。 创建这些结构化数据存储所需的典型操作包括：
- 组合不同的数据集
- 非规范化
- 清洁，重复数据删除，持有房屋
- 导出计算数据字段
Apache Spark已成为处理原始数据层以创建各种增值结构化数据层的首选工具。
数据仓库
对于某些特殊用例（想想高性能数据仓库），您可能需要对数PB的数据运行SQL查询并非常快速地返回复杂的分析结果。 在这些情况下，您可能需要将湖中的部分数据摄取到列存储平台中。 完成此任务的工具示例包括Google BigQuery，Amazon Redshift或Azure SQL数据仓库。
交互式查询和报告
仍有大量用例需要支持常规SQL查询工具来分析这些海量数据存储。 Apache Hive ，Apache Presto，Amazon Athena和Impala都是专门开发的，通过在原始数据之上创建或使用SQL友好模式来支持这些用例。
数据探索和机器学习
最后，作为数据湖最大受益者的一类用户是您的数据科学家，他们现在可以访问企业范围的数据，不受各种模式的限制，然后可以探索和挖掘数据以获得高价值商业见解。 许多数据科学家工具要么基于Hadoop，要么可以与基于Hadoop的平台一起工作，这些平台可以访问数据湖。
结论
在设计和构建良好时，数据湖可以消除数据孤岛，并开启灵活的企业级探索和结果挖掘。 数据湖是收集企业大数据作为核心资产，从数据中提取基于模型的洞察力以及培养数据驱动决策文化所需的最重要元素之一。