精心设计的数据湖建筑的商业案例

 

让咱们从数据湖的标准定义开始：

数据湖是一个存储库，它以原生格式保存大量原始数据，包括结构化，半结构化和非结构化数据。 在须要数据以前，不会定义数据结构和要求。

你为何要关心？

革新

在大型企业中，数据湖最强大的影响多是创新的实现 。 咱们已经看到许多数十亿美圆的组织正在努力创建数据驱动的洞察力和创新文化。 它们被孤立于部门或分区划分的数据存储的结构孤岛所困扰，而且这些结构孤立于围绕数据全部者的大规模组织政治。 企业数据湖虽然远非微不足道，但它提供了从根本上清除企业级数据访问问题的必要基础。 之前没法进行探索性分析和数据挖掘的大门打开了，实现了全新的可能性。

速度

在当今动态的业务环境中，新的数据消费需求和用例很是迅速地出现。 在准备需求文档以反映对数据存储或模式的请求更改时，用户常常转向不一样甚至相互矛盾的模式更改集。 相比之下，数据湖的整个理念围绕着为未知用例作好准备。 当源数据位于一个中心湖中时，其中没有嵌入单一控制结构或模式，支持新的附加用例能够更加简单。

自助服务

对报表的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的平台一块儿工做，这些平台能够访问数据湖。

结论

在设计和构建良好时，数据湖能够消除数据孤岛，并开启灵活的企业级探索和结果挖掘。 数据湖是收集企业大数据做为核心资产，从数据中提取基于模型的洞察力以及培养数据驱动决策文化所需的最重要元素之一。