【数据湖架构】Azure Data Lake数据湖指南(上)

简介: 【数据湖架构】Azure Data Lake数据湖指南
  • 数据湖漫游指南
  • 文件大小和文件数
  • 文件格式
  • 分区方案
  • 使用查询加速
  • 我如何管理对我的数据的访问?
  • 我选择什么数据格式?
  • 如何管理我的数据湖成本?
  • 如何监控我的数据湖?
  • ADLS Gen2 何时是您数据湖的正确选择?
  • 设计数据湖的关键考虑因素
  • 术语
  • 组织和管理数据湖中的数据
  • 我想要集中式还是联合式数据湖实施?
  • 如何组织我的数据?
  • 优化数据湖以获得更好的规模和性能
  • 推荐阅读
  • 问题、意见或反馈?

Azure Data Lake Storage Gen2 (ADLS Gen2) 是用于大数据分析的高度可扩展且经济高效的数据湖解决方案。随着我们继续与客户合作,利用 ADLS Gen2 从他们的数据中发掘关键洞察,我们已经确定了一些关键模式和注意事项,可帮助他们在大规模大数据平台架构中有效利用 ADLS Gen2。

本文档记录了我们在与客户合作的基础上学到的这些注意事项和最佳实践。就本文档而言,我们将重点介绍我们的大型企业客户在 Azure 上大量使用的现代数据仓库模式,包括我们的解决方案,例如 Azure Synapse Analytics。

我们将改进此文档以在未来的迭代中包含更多分析模式。

重要提示:请将此文档的内容视为指导和最佳实践,以帮助您做出架构和实施决策。这不是官方的 HOW-TO 文档。

ADLS Gen2 何时是您数据湖的正确选择?#

企业数据湖旨在成为大数据平台中使用的非结构化、半结构化和结构化数据的中央存储库。企业数据湖的目标是消除数据孤岛(数据只能由组织的一部分访问)并促进单一存储层,以适应组织的各种数据需求有关选择正确的更多信息存储解决方案,请访问在 Azure 中选择大数据存储技术一文。

出现的一个常见问题是何时使用数据仓库与数据湖。我们敦促您将数据湖和数据仓库视为互补的解决方案,它们可以协同工作,帮助您从数据中获得关键见解。数据湖是存储来自各种来源的所有类型数据的存储库。自然形式的数据存储为原始数据,并在此原始数据上应用模式和转换,以根据业务试图回答的关键问题获得有价值的业务洞察力。数据仓库是高度结构化的模式化数据的存储,这些数据通常被组织和处理以获得非常具体的见解。例如。零售客户可以将过去 5 年的销售数据存储在数据湖中,此外,他们可以处理来自社交媒体的数据,从零售分析解决方案中提取消费和情报的新趋势,并利用所有这些作为输入一起生成一个数据集,可用于预测明年的销售目标。然后,他们可以将高度结构化的数据存储在数据仓库中,BI 分析师可以在其中构建目标销售预测。此外,他们可以使用数据湖中相同的销售数据和社交媒体趋势来构建智能机器学习模型,以在其网站上进行个性化推荐。

ADLS Gen2 是适用于大数据分析工作负载的企业级超大规模数据存储库。ADLS Gen2 通过分层命名空间提供更快的性能和 Hadoop 兼容访问,通过细粒度访问控制和本机 AAD 集成降低成本和安全性。这适合作为专注于大数据分析场景的企业数据湖的选择——使用转换从非结构化数据中提取高价值的结构化数据、使用机器学习的高级分析或实时数据摄取和分析以获得快速洞察力。值得注意的是,我们已经看到客户对超大规模的定义有不同的定义——这取决于存储的数据、交易数量和交易吞吐量。当我们说超大规模时,我们通常指的是数 PB 的数据和数百 Gbps 的吞吐量——这种分析所涉及的挑战与吞吐量中的数百 GB 数据和几 Gbps 的事务非常不同。

设计数据湖的关键考虑因素#

当您在 ADLS Gen2 上构建企业数据湖时,了解您对关键用例的需求很重要,包括

  1. 我在数据湖中存储了什么?
  2. 我在数据湖中存储了多少数据?
  3. 您在数据的哪一部分上运行分析工作负载?
  4. 谁需要访问我的数据湖的哪些部分?
  5. 我将在我的数据湖上运行哪些各种分析工作负载?
  6. 分析工作负载有哪些不同的事务模式?
  7. 我的工作预算是多少?

对于我们一直从客户那里听到的一些关键设计/架构问题,我们希望将本文档的其余部分固定在以下结构中。

  • 有优缺点的可用选项
  • 选择适合您的选项时要考虑的因素
  • 适用时推荐的模式
  • 您想要避免的反模式

为了最好地利用本文档,请确定您的关键场景和要求,并根据您的要求权衡我们的选项以决定您的方法。如果您无法选择完全适合您的场景的选项,我们建议您使用一些选项进行概念验证 (PoC),让数据指导您的决策。

术语#

在我们讨论构建数据湖的最佳实践之前,熟悉我们将在使用 ADLS Gen2 构建数据湖的上下文中使用的各种术语非常重要。本文档假设您在 Azure 中有一个帐户。

  • 资源:可通过 Azure 获得的可管理项目。虚拟机、存储帐户、VNET 是资源的示例。
  • 订阅:Azure 订阅是一个逻辑实体,用于分离 Azure 资源的管理和财务(计费)逻辑。订阅与 Azure 资源的限制和配额相关联,您可以在此处阅读有关它们的信息。
  • 资源组:用于容纳 Azure 解决方案所需资源的逻辑容器可以作为一个组一起管理。您可以在此处阅读有关资源组的更多信息。
  • 存储帐户:包含所有 Azure 存储数据对象的 Azure 资源:blob、文件、队列、表和磁盘。您可以在此处阅读有关存储帐户的更多信息。就本文档而言,我们将重点介绍 ADLS Gen2 存储帐户——它本质上是一个启用了分层命名空间的 Azure Blob 存储帐户,您可以在此处阅读更多相关信息。
  • 容器(也称为非 HNS 启用帐户的容器):一个容器组织一组对象(或文件)。一个存储帐户对容器的数量没有限制,容器可以存储无限数量的文件夹和文件。有些属性可以应用于容器级别,例如 RBAC 和 SAS 键。
  • 文件夹/目录:文件夹(也称为目录)组织一组对象(其他文件夹或文件)。一个文件夹下可以创建多少个文件夹或文件没有限制。文件夹还具有与之关联的访问控制列表 (ACL),有两种类型的 ACL 与文件夹关联——访问 ACL 和默认 ACL,您可以在此处阅读有关它们的更多信息。
  • 对象/文件:文件是保存可以读/写的数据的实体。一个文件有一个与之关联的访问控制列表。文件只有访问 ACL,没有默认 ACL。

组织和管理数据湖中的数据#

随着我们的企业客户制定他们的数据湖战略,ADLS Gen2 的关键价值主张之一是作为其所有分析场景的单一数据存储。请记住,这个单一数据存储是一个逻辑实体,根据设计考虑,它可以表现为单个 ADLS Gen2 帐户或多个帐户。一些客户拥有分析管道组件的端到端所有权,而其他客户则拥有一个中央团队/组织来管理数据湖的基础架构、运营和治理,同时为多个客户提供服务——无论是他们企业中的其他组织还是外部的其他客户到他们的企业。

在本节中,我们针对客户在设计企业数据湖时听到的一系列常见问题提出了我们的想法和建议。作为说明,我们将以大型零售客户 Contoso.com 为例,构建他们的数据湖策略以帮助处理各种预测分析场景。

我想要集中式还是联合式数据湖实施?#

作为企业数据湖,您有两种可用的选择——要么将所有数据管理集中在一个组织内以满足您的分析需求,要么拥有一个联合模型,您的客户管理他们自己的数据湖,而集中式数据团队提供指导并管理数据湖的几个关键方面,例如安全性和数据治理。重要的是要记住,集中式和联合数据湖策略都可以使用一个存储帐户或多个存储帐户来实施。

客户问我们的一个常见问题是,他们是否可以在单个存储帐户中构建数据湖,或者他们是否需要多个存储帐户。虽然从技术上讲,单个 ADLS Gen2 可以解决您的业务需求,但客户选择多个存储帐户的原因有多种,包括但不限于本节其余部分中的以下场景。

关键考虑#

在决定要创建的存储帐户数时,以下注意事项有助于决定要预配的存储帐户数。

  • 单个存储帐户使您能够管理一组控制平面管理操作,例如存储帐户中所有数据的 RBAC、防火墙设置、数据生命周期管理策略,同时允许您使用容器、文件和存储帐户上的文件夹。如果您想优化以简化管理,特别是如果您采用集中式数据湖策略,这将是一个值得考虑的好模型。
  • 多个存储帐户使您能够在不同帐户之间隔离数据,以便可以对它们应用不同的管理策略或单独管理它们的计费/成本逻辑。如果您正在考虑采用联合数据湖策略,每个组织或业务部门都有自己的一组可管理性要求,那么此模型可能最适合您。

让我们将这些方面放在一些场景的上下文中。

覆盖全球的企业数据湖#

在全球市场和/或地理分布的组织的推动下,有些情况下,企业的分析场景将多个地理区域考虑在内。数据本身可以分为两大类。

  • 可以在所有地区全球共享的数据——例如Contoso 正在尝试规划下一个财政年度的销售目标,并希望从各个地区获取销售数据。
  • 需要隔离到一个区域的数据——例如Contoso 希望根据买家的个人资料和购买模式提供个性化的买家体验。鉴于这是客户数据,需要满足主权要求,因此数据不能离开该区域。

在这种情况下,客户将提供特定于区域的存储帐户来存储特定区域的数据并允许与其他区域共享特定数据。这里仍然有一个集中的逻辑数据湖,其中包含一组由多个存储帐户组成的中央基础设施管理、数据治理和其他操作。


客户或数据特定隔离#

存在企业数据湖服务于多个客户(内部/外部)场景的场景,这些场景可能会受到不同的要求——不同的查询模式和不同的访问要求。让我们以我们的 Contoso.com 为例,他们有分析方案来管理公司运营。在这种情况下,他们拥有各种数据源——员工数据、客户/活动数据和财务数据,这些数据受不同治理和访问规则的约束,也可能由公司内的不同组织管理。在这种情况下,他们可以选择为各种数据源创建不同的数据湖。

在另一种情况下,作为为多个客户提供服务的多租户分析平台的企业最终可能会为不同订阅中的客户提供单独的数据湖,以帮助确保客户数据及其相关的分析工作负载与其他客户隔离,以帮助管理他们的成本和计费模式。


建议#

 

  • 为您的开发和生产环境创建不同的存储帐户(最好在不同的订阅中)。除了确保需要不同 SLA 的开发和生产环境之间有足够的隔离之外,这还有助于您有效地跟踪和优化管理和计费策略。
  • 确定数据的不同逻辑集,并考虑以统一或隔离的方式管理它们的需求——这将有助于确定您的帐户边界。
  • 从一个存储帐户开始您的设计方法,并考虑为什么需要多个存储帐户(隔离、基于区域的要求等)而不是相反的原因。
  • 其他资源(例如 VM 核心、ADF 实例)也有订阅限制和配额——在设计数据湖时要考虑这些因素。

反模式#

谨防多重数据湖管理#

当您决定 ADLS Gen2 存储帐户的数量时,请确保针对您的消费模式进行优化。如果您不需要隔离并且您没有充分利用您的存储帐户的功能,您将承担管理多个帐户的开销,而没有有意义的投资回报。

来回复制数据#

当您拥有多个数据湖时,您需要谨慎对待的一件事是您是否以及如何跨多个帐户复制数据。这会产生一个管理问题,即真相的来源是什么以及它需要有多新鲜,并且还会消耗涉及来回复制数据的事务。如果您有一个合法的方案来复制您的数据,我们的路线图中有一些功能可以使此工作流程更容易。

可扩展性注释#

我们的客户问的一个常见问题是,单个存储帐户是否可以无限地继续扩展以满足他们的数据、事务和吞吐量需求。我们在 ADLS Gen2 中的目标是满足客户所需的极限。当您遇到需要真正存储大量数据(数 PB)并需要帐户支持真正大的事务和吞吐量模式(数万 TPS 和数百 Gbps 吞吐量)的场景时,我们确实要求),通常通过 Databricks 或 HDInsight 进行分析处理需要 1000 个计算能力核心,请联系我们的产品组,以便我们可以计划适当地支持您的要求。

如何组织我的数据?#

ADLS Gen2 帐户中的数据组织可以在容器、文件夹和文件的层次结构中按顺序完成,如我们上面所见。当我们与客户合作制定他们的数据湖策略时,一个非常常见的讨论点是他们如何最好地组织他们的数据。有多种方法可以在数据湖中组织数据,本节记录了许多构建数据平台的客户采用的通用方法。

该组织跟踪数据的生命周期,因为它通过源系统一直流向最终消费者——BI 分析师或数据科学家。例如,让我们跟随销售数据通过 Contoso.com 的数据分析平台的旅程。

例如,将原始数据视为自然状态下有水的湖泊/池塘,数据按原样摄取和存储,未经转换,丰富的数据是水库中的水,经过清洗并以可预测的状态存储(以我们的数据为例),策划的数据就像准备消费的瓶装水。工作区数据就像一个实验室,科学家可以在其中携带自己的数据进行测试。值得注意的是,虽然所有这些数据层都存在于单个逻辑数据湖中,但它们可能分布在不同的物理存储帐户中。在这些情况下,拥有 Metastore 有助于发现。

  • 原始数据:这是来自源系统的数据。此数据按原样存储在数据湖中,并由分析引擎(例如 Spark)使用以执行清理和充实操作以生成精选数据。原始区域中的数据有时也存储为聚合数据集,例如在流场景的情况下,数据通过消息总线(如事件中心)摄取,然后通过实时处理引擎(如 Azure Stream 分析或 Spark Streaming)聚合,然后存储在数据湖中。根据您的业务需求,您可以选择保持数据原样(例如来自服务器的日志消息)或聚合它(例如实时流数据)。这一层数据由中央数据工程团队高度控制,很少被其他消费者访问。根据您企业的保留策略,此数据要么在保留策略要求的期限内按原样存储,要么在您认为数据不再使用时将其删除。例如。这将是从在其本地系统中运行的 Contoso 的销售管理工具中提取的原始销售数据。
  • 丰富的数据:这一层数据是原始数据(按原样或聚合)具有定义模式的版本,并且数据经过清理、丰富(与其他来源),可供分析引擎使用以提取高价值数据。数据工程师生成这些数据集,并继续从这些数据集中提取高价值/精选数据。例如。这将是丰富的销售数据 - 确保销售数据被模式化,丰富了其他产品或库存信息,并为 Contoso 内部的不同业务部门分成多个数据集。
  • 精选数据:这一层数据包含提供给数据消费者(BI 分析师和数据科学家)的高价值信息。该数据具有结构,可以按原样(例如数据科学笔记本)或通过数据仓库提供给消费者。该层中的数据资产通常受到高度管理和良好记录。例如。业务部门的高质量销售数据(即与其他需求预测信号(如社交媒体趋势模式)相关的丰富数据区域中的数据),用于预测分析以确定下一财政年度的销售预测。
  • 工作区数据:除了数据工程团队从源头摄取的数据之外,数据的消费者还可以选择带来其他可能有价值的数据集。在这种情况下,数据平台可以为这些消费者分配工作空间,以便他们可以使用精选数据以及他们带来的其他数据集来生成有价值的见解。例如。数据科学团队正在尝试确定新地区的产品放置策略,他们可以带来其他数据集,例如客户人口统计数据和该地区其他类似产品的使用数据,并使用高价值的销售洞察数据来分析产品市场契合度和发行策略。
  • 存档数据:这是您组织的数据“保险库” - 存储的数据主要符合保留策略,并且具有非常严格的用途,例如支持审计。您可以使用 ADLS Gen2 中的 Cool 和 Archive 层来存储此数据。您可以阅读有关我们的数据生命周期管理政策的更多信息,以确定适合您的计划。

关键考虑#

在决定数据结构时,请考虑数据本身的语义以及访问数据的消费者,以确定适合您的数据组织策略。

建议#

 

  • 为不同的数据区域创建不同的文件夹或容器(更多关于文件夹与容器之间的注意事项) - 原始数据集、丰富数据集、策划数据集和工作区数据集。
  • 在一个区域内,选择根据逻辑分隔在文件夹中组织数据,例如日期时间或业务单位或两者兼而有之。您可以在我们的最佳实践文档中找到有关目录布局的更多示例和场景。
  • 在设计文件夹结构时考虑分析使用模式。例如。如果您有一个 Spark 作业读取过去 3 个月内来自特定地区的产品的所有销售数据,那么理想的文件夹结构是 /enriched/product/region/timestamp。
  • 在决定文件夹结构时,请考虑您希望遵循的访问控制模型。
  • 下表提供了一个框架,供您考虑数据的不同区域以及具有常见模式的区域的相关管理。
考虑 原始数据 丰富的数据 策划的数据 工作空间数据
消费者 数据工程团队 数据工程团队,由数据科学家/BI分析师提供临时访问模式 数据工程师、BI分析师、数据科学家 数据科学家/BI分析师
访问控制 数据工程团队已锁定访问权限 完全控制数据工程团队,并对BI分析师/数据科学家具有读取权限 完全控制数据工程团队,对BI分析师/数据科学家具有读写权限 完全控制数据工程师、数据科学家/BI 分析师
数据生命周期管理 一旦生成了丰富的数据,就可以将其移动到较冷的存储层以管理成本。 较旧的数据可以移动到较冷的层。 较旧的数据可以移动到较冷的层。 虽然最终消费者可以控制这个工作区,但要确保有清理不必要数据的流程和策略——例如,使用基于策略的 DLM,数据可以很容易地建立起来。
文件夹结构和层次结构 文件夹结构以反映摄入模式。 文件夹结构反映组织,例如业务部门。 文件夹结构反映组织,例如业务部门。 文件夹结构反映了工作区所使用的团队。
实例 /raw/sensordata /raw/lobappdata /raw/userclickdata

/enriched/sales /enriched/

manufacturing

/curated/sales /curated/

manufacturing

/workspace/salesBI /workspace/

manufacturin

datascience

  • 我们的客户询问何时使用容器以及何时使用文件夹来组织数据的另一个常见问题。虽然在更高级别,它们都用于数据的逻辑组织,但它们有一些关键区别。
考虑 容器 文件夹
等级 容器可以包含文件夹或文件。 文件夹可以包含其他文件夹或文件。
使用AAD的访问控制 在容器级别,可以使用RBAC设置粗粒度的访问控制。这些RBAC适用于容器内的所有数据。 在文件夹级别,可以使用ACL设置细粒度的访问控制。ACL仅适用于该文件夹(除非使用默认ACL,在这种情况下,在该文件夹下创建新文件/文件夹时会对其进行快照)。
非AAD访问控制 在容器级别,可以启用匿名访问(通过共享密钥)或设置特定于容器的SAS密钥。 文件夹不支持非AAD访问控制。

反模式#

不相关数据无限增长#

虽然 ADLS Gen2 存储不是很昂贵,并且允许您在存储帐户中存储大量数据,但即使您不需要整个数据语料库,生命周期管理策略的缺失也可能最终导致存储中数据的增长非常快为您的方案。我们看到这种数据增长的两种常见模式是:-

  • 使用较新版本的数据刷新数据——客户通常会保留一些较旧版本的数据以供分析,当同一数据有一段时间刷新时,例如当上个月的客户参与数据在 30 天的滚动窗口中每天刷新时,您每天都会获得 30 天的参与数据,如果您没有适当的清理流程,您的数据可能会呈指数级增长。
  • 工作区数据积累——在工作区数据区,您的数据平台的客户,即 BI 分析师或数据科学家可以带来他们自己的数据集 通常,我们已经看到,当未使用的数据是留在存储空间周围。
相关实践学习
简单用户画像分析
本场景主要介绍基于海量日志数据进行简单用户画像分析为背景,如何通过使用DataWorks完成数据采集 、加工数据、配置数据质量监控和数据可视化展现等任务。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
2月前
|
存储 数据采集 大数据
Data Lake架构揭秘
Data Lake架构揭秘
36 0
|
2月前
|
存储 SQL 机器学习/深度学习
通用数据湖仓一体架构正当时
通用数据湖仓一体架构正当时
73 2
|
11月前
|
存储 数据采集 分布式计算
数据湖架构的优势与挑战:数据存储和分析策略
随着大数据时代的到来,数据湖架构逐渐成为许多企业进行数据存储和分析的首选方案。数据湖是一种用于存储大量原始和结构化数据的中心化存储库。在本文中,我们将深入探讨数据湖架构的优势和挑战,并介绍一些常见的数据存储和分析策略。
342 0
|
12月前
|
存储 分布式计算 数据挖掘
【数据湖仓架构】数据湖和仓库:Databricks 和 Snowflake
【数据湖仓架构】数据湖和仓库:Databricks 和 Snowflake
|
12月前
|
SQL 存储 分布式计算
【数据湖仓架构】数据湖和仓库:Azure Synapse 视角
【数据湖仓架构】数据湖和仓库:Azure Synapse 视角
|
12月前
|
存储 SQL 数据挖掘
【数据湖仓架构】数据湖和仓库:范式简介
【数据湖仓架构】数据湖和仓库:范式简介
|
12月前
|
存储 传感器 SQL
【数据湖架构】Azure Data Lake数据湖指南(下)
【数据湖架构】Azure Data Lake数据湖指南
|
2月前
|
SQL 分布式计算 数据处理
Uber基于Apache Hudi增量 ETL 构建大规模数据湖
Uber基于Apache Hudi增量 ETL 构建大规模数据湖
56 2
|
2月前
|
存储 SQL 分布式计算
基于Apache Hudi + MinIO 构建流式数据湖
基于Apache Hudi + MinIO 构建流式数据湖
104 1
|
8月前
|
存储 人工智能 数据库
企业级数据湖的构建之道(一)
企业级数据湖的构建之道(一)
91 1