将数据仓库迁移至 BigQuery:数据治理

本文档是系列文章中的一篇,该系列讨论了如何将本地数据仓库迁移到 BigQuery。本文档可帮助您了解所需的数据治理和控制。

该系列文章包含以下部分:

简介

数据治理是在数据生命周期(从获取、使用到处置)内对其进行管理的原则性方法。您的数据治理计划明确展示了围绕数据活动的政策、过程、职责和控制。该计划有助于确保以满足组织数据完整性和安全性需求的方式收集、维护、使用和传播信息,同时还有助于员工发现和使用数据,从而发挥信息的最大潜力。

对于任何组织来说,从数据可以被提取到可以用于有价值的数据洞见和信息的时候,就应将数据的管理和治理视为至关重要的事项。

我们建议您围绕三个关键组件构建数据治理的做法:

  • 一个框架,使人们能够定义、同意和实施数据政策。
  • 对本地系统、Cloud Storage 和数据仓库平台上的所有数据资源进行控制、监督和管理的有效流程
  • 用于监督和管理数据政策合规性的正确工具和技术

接下来的部分介绍基于 Gartner 数据湖参考架构中的数据治理中的数据治理框架,以及支持其实施的工具和技术。如需了解有关治理实现的业务需求以及实施数据治理所涉及的流程的讨论,请参阅云中的数据治理原则和最佳做法白皮书。

数据访问管理

按照传统,公司依靠边界安全来保护其内部资源。边界安全,也称为蛋壳安全或城堡和护城河安全,其假设威胁只存在于边界外部,并且边界内的任何内容都是可信的。这种假设被证明是错误的,给不少公司造成代价高昂的后果,因为当攻击者获得对内部网络的访问权限时,就可以几乎不受阻碍地转移到其他系统并寻求有价值的数据资源。

攻击者可以通过漏洞、员工安装的恶意软件、社交媒体引擎和其他方式访问内部网络。然而,在边界安全模型中创建漏洞的恶意外部代理并不是唯一的威胁。当内部网络中的资源未得到正确保护时,受信任的员工可能会有意或无意地修改、删除或泄露数据。

最后但也很重要的一点是,随着企业网络的发展,边界安全性变得越来越复杂。例如,在以下情况下难以执行边界安全保护:

  • 员工必须通过不受信任的网络远程工作,例如在客户站点、机场或家中。
  • 供应商、合作伙伴和承包商需要更直接地访问您的数据资源。
  • 一些公司系统现存在于云中。

鉴于您要从现有的本地企业数据仓库进行迁移,您当前允许用户访问以进行数据查询或查看的方法可能要么不够深入,要么维护复杂且成本高昂,或两者兼而有之。迁移到像 BigQuery 这种可以为您提供深入的安全性的云数据仓库可以实现较低的维护成本,因为安全框架是代管式服务产品的一部分。

本章的其余部分介绍并详细说明了如何在 Google Cloud 和 BigQuery 上实现数据访问权限管理。目的是概括介绍迁移企业数据仓库时从此安全框架中获得的益处。

资源管理

将您的工作负载迁移到 Google Cloud 需要遵守管理 Google Cloud 中所有资源的结构以及每个产品的具体准则。

Google Cloud 中的所有资源都是按层次结构组织的。在最低级层,您可以使用基本组件,如 BigQuery 数据集、Cloud Storage 存储分区、Compute Engine 虚拟机等。这些低级层资源统称为项目的逻辑容器。项目构成了使用所有 Google Cloud 服务、管理结算以及为项目资源分配角色和权限的基础。项目又被分组到可以对应于公司内不同部门或团队的文件夹中。层次结构的顶部是组织节点,该节点代表其所属的公司并包含多个文件夹。如需了解详情,请参阅资源层次结构文档

从 Google Cloud 的角度来看,BigQuery 数据集位于资源层次结构的最低级层。但是从 BigQuery 数据集本身的角度来看,它们是用于组织和控制对表和视图的访问的顶层容器。原则上,它们类似于传统 OLTP 和 OLAP 环境中的数据库或命名空间。在创建数据集时,您可以选择数据集的位置。由于查询只能引用同一位置的数据集,因此在首次创建数据集和设计查询时考虑该位置非常重要。

安全框架

Google 的 BeyondCorp 计划建立了以零信任为基础的安全框架。在此框架中,动态访问权限控制的原则定义了任何想要访问资源的用户或设备:

  1. 必须使用凭据进行身份验证。
  2. 必须经过授权才能访问所述资源。
  3. 必须使用加密的通信模式。

无论用户或设备网络位置如何,即无论是使用公司内网,还是使用公共 WiFi 或在飞机上等,都必须满足这些要求才能访问所需的资源。

本文后面的部分将探讨管理数据资源访问的概念和最佳做法,包括 BeyondCorp 中列出的原则。本文还解释了如何实施作为防止数据渗漏保护措施的边界安全覆盖

身份验证和授权

身份验证是确定和验证与 BigQuery 交互的客户端身份的过程。授权是指确定经过身份验证的客户端与 BigQuery 及其数据集交互的权限的过程。简而言之,身份验证识别您是谁,而授权规定您可以做些什么。

身份

在 Google Cloud 上,Cloud Identity 是内置的身份提供商。从本地数据仓库迁移时,请考虑将现有身份提供商(如 Microsoft Active Directory)与 Cloud Identity 联合。然后,您可以继续使用现有的身份提供商来处理以下任务:

  • 预配和管理用户和组。
  • 设置单点登录。
  • 配置多重身份验证。

BigQuery 的用户可能是人类,但也可能是使用 BigQuery 客户端库REST API 进行通信的非人类应用。这些应用应使用服务帐号进行自我身份识别。服务帐号是代表非人类用户的一种特殊类型 Google 身份。

Cloud Identity 是一个名为 Identity and Access Management (IAM) 的大型产品的前半部分。

用户通过身份验证后,您仍需确定用户是否具有与 BigQuery 及其数据集进行交互的必要权限。

访问权限管理

除了身份验证之外,IAM 还为您提供集中控制,以授权具有 BigQuery 及其数据集的特定权限的身份。IAM 管理整个组织中 BigQuery 的安全政策,使您能够以更精细的级层(低于项目级层访问权限)授予对 BigQuery 资源的访问权限。

在 IAM 中,权限确定允许对资源进行的操作,但您无法将这些权限直接分配给 Google 身份(用户、服务帐号、Google 群组、Google Workspace 或 Cloud Identity 网域)。您应将角色(权限集合)分配给 Google 身份,并使用(在 JSON 或 YAML 文件中声明的)政策,在以下任何 Google Cloud 资源级层执行这些绑定:

  • 组织
  • 文件夹
  • 项目
  • 资源级层(BigQuery 数据集)

BigQuery 角色可以绑定到任何先前列出的资源级层上,例如:

  • 在项目级层,用户可以具有 adminmetadataViewerjobUser 角色。
  • 在 BigQuery 数据集资源级层,用户(或视图)可以具有 dataEditordataOwnerdataViewer 角色。

授权视图允许您与特定用户共享查询结果,而无需向他们授予对于底层表的访问权限。您可以使用授权视图将访问权限限制在较低的资源级层(如表、列单元格)。

IAM 允许您根据身份管理身份验证和授权。它还允许您围绕具有公共端点(如 BigQuery)的服务创建安全边界。如需详细了解访问权限控制的方法,请参阅有关网络安全的部分。

实施方法

您的迁移工作通常需要您将本地应用连接到 BigQuery。需要此访问权限的示例实施包括:

  • 将数据加载到 BigQuery 的本地数据流水线。
  • 从 BigQuery 查询或提取数据的本地报告、分析或其他业务应用

为通过 BigQuery 访问数据,应用必须通过 API 请求获取并发送凭据。您可以使用短期或长期凭据与本地应用或其他公共云中的 BigQuery API 进行交互。

BigQuery 客户端必须通过服务帐号或用户凭据进行身份验证。在对客户端进行身份验证后,必须将访问令牌或密钥传递给 BigQuery API。然后检查这些凭据是否有适当的授权,以确保客户端对其与 BigQuery 的任何交互具有足够的 IAM 权限。

短期凭据

短期凭据会在一段短暂的时间后自动到期,该期间在创建短期凭据时指定(OAuth2.0OpenID 的最长生命周期为 1 小时,JWT 的最长生命周期为 12 小时)。如果您希望避免管理服务帐号的密钥,或者如果要向 Google Cloud 服务颁发过期的授权,您可以使用短期凭据。

以下类型的凭据可以请求作为短期凭据:

  • OAuth 2.0 访问令牌
  • OpenID Connect ID 令牌
  • 自签名 JSON 网络令牌 (JWT)
  • 自签名二进制对象 (Blob)

短期凭据允许无 Google Cloud 身份的本地服务与 BigQuery 通信。虽然使用 Google Cloud 身份进行的通信必须获取短期凭据,但使用令牌的应用或服务不需要 Google Cloud 身份。

长期凭据

用户可以使用长期凭据(例如,服务帐号私钥或带有刷新令牌的 OAuth 2.0 访问令牌)获准访问 BigQuery,直到长期凭据被删除或撤消。服务帐号私钥一旦创建就会保留,而无需刷新。OAuth 2.0 访问令牌有过期期限,但可以通过附带的刷新令牌而长期使用。只要刷新令牌保持活跃状态,就可以让您请求新的访问令牌(无需重新进行身份验证)。此过程在 Google 的 OAuth 2.0 Playground 中有所说明。

考虑到其较长的生命周期,您应该在远程客户端计算机或工作器节点上谨慎管理长期凭据。我们建议您将凭据存储在一个安全的位置,仅供经过授权的用户访问。请不要将凭据存储在代码库中:这可能会使有权访问代码的用户同时有权访问您的密钥(亦即您的数据)。在发生凭据泄露时,您可以使用服务边界来缓解不应发生的外部访问造成的风险。

我们推荐您采用如下策略存储长期凭据:

  • 带或不带密钥管理服务 (KMS) 的 Cloud Storage
  • 安全的本地存储
  • 第三方密钥管理解决方案

服务帐号私钥是属于单个服务帐号的经过加密签名的 JWT。签名的 JWT 直接用作不记名令牌,因此不需要向 Google 授权服务器发出网络请求。由于密钥不会自动过期或在泄露时撤消访问权限,因此定期轮替密钥是最安全的做法。此过程需要生成新密钥,确保所有授权用户和服务都可以访问新密钥,并删除旧密钥。密钥轮替确保在密钥被泄露的情况下,即使没有检测到泄露,被破解的密钥对 BigQuery 的访问权限也将自动撤消。

非匿名 BigQuery 请求

私有服务帐号密钥和刷新令牌都支持使用服务帐号进行身份验证。多个用户和应用可能有权访问同一服务帐号。因为无法识别用户或应用,因此这些请求是匿名的。但是,许多企业客户要求访问 Google Cloud 资源(如 BigQuery)必须归因于发起请求的个人用户。在这种情况下,您可以使用 Google Cloud 令牌代理或三足式 OAuth 2.0 (3LO) 流代表最终用户而非服务帐号进行身份验证。

Google Cloud 令牌代理为 Hadoop 工作负载提供端到端 Kerberos 安全性和 IAM 集成。在本地部署环境中,所有身份都使用 Kerberos 和本地密钥分发中心 (KDC) 进行身份验证。KDC 将其身份或“主帐号”与真实来源(例如 Active Directory 或 Open LDAP)同步。Google Cloud 令牌代理将 Kerberos 身份映射到 Google Cloud Identity 身份,允许完成身份验证的 Kerberos 主帐号访问 BigQuery 等 Google Cloud 资源。如果授权了 Kerberos 主帐号,则 Google Cloud 令牌代理使用长期刷新令牌生成访问令牌,该令牌将以加密的方式传递到客户端。之后,客户端可以使用访问令牌来发出可归因于 Kerberos 主帐号的 API 请求。

使用带有 Kerberos 的 Google Cloud 令牌代理具有以下优点:

  • 对 Google Cloud 的所有请求均归因于发起请求的单个用户。
  • 客户端机器或工作器节点上不存储长期凭据。
  • 需要对现有的本地部署安全系统和用户工作流程进行的更改有限。

非匿名 API 请求的另一个选项是三足式 OAuth 2.0 用户验证场景。在二足式验证流程中,应用直接保存服务帐号的凭据,并代表该服务帐号调用 BigQuery API。但是,在三足式验证流程中,资源所有者允许客户端访问 BigQuery 资源,而无需直接共享其凭据;由于请求是代表用户发出的,有时需要获得用户的同意。用户进行身份验证后,可以使用访问令牌和刷新令牌交换授权代码。

网络安全

Virtual Private Cloud 网络类似于物理网络,但在 Google Cloud 中进行了虚拟化。您可以在网络级层定义防火墙规则,以控制进出虚拟机实例的流量。但是,您无法为基于 API 的服务(如 BigQuery 或 Cloud Storage)定义防火墙规则。对于这些类型的服务,您可以使用 Google Virtual Private Cloud (VPC) Service Controls 来限制流量。

VPC 定义了基于 Google API 服务的服务边界,这些服务具有公共端点,例如 BigQuery 或 Cloud Storage。服务边界通过限制边界内外资源之间的数据出口和入口来减轻数据渗漏的风险。正确实施这些控制后,未经授权的网络无法访问数据和服务,并且无法将数据复制到未授权的 Google Cloud 项目中。在边界内部仍然可以进行自由的通信,但是与边界外部的通信将被限制。

我们建议您将 VPC Service Controls 与 IAM 访问权限控制结合使用。在 IAM 提供基于身份的精细访问权限控制的情况下,VPC Service Controls 可实现更广泛的基于情境的边界安全性。

情境感知访问权限控制

边界的访问权限级层决定了是否允许或拒绝来自公共互联网的 API 请求访问服务边界内的资源。根据客户端情境对请求进行分类,例如 IP 范围和用户/服务帐号身份标识。例如,如果 BigQuery API 请求来自有效凭据但不受信任的网络,则可以拒绝该请求访问 VPC 网络和服务边界,如下图所示。

凭据有效但来自不受信任的网络的 BigQuery API 请求,可能会被拒绝访问 VPC 网络和服务边界。

服务边界

VPC 服务边界是在 Google Cloud 组织级层配置的,因此您可以集中管理安全政策。该组织和服务中的多个项目(例如,BigQuery API)可以分配给每个边界。只要所有这些操作都在边界内部进行,您就可以灵活地处理、转换和复制同一服务边界内的项目和数据。下图展示了如何使用服务边界。

在同一服务边界处理、转换和复制数据。

如果不同服务边界内的 Google Cloud 资源需要进行通信(例如,一个项目和服务边界内的 BigQuery 与另一个项目和服务边界内的 Compute Engine),则可以在组织级层创建边界网桥。边界网桥可允许跨多个服务边界的 Google Cloud 资源之间进行通信。虽然一个 Google Cloud 项目只能分配到一个服务边界内,但它可以作为多个边界网桥的一部分。

混合环境中的数据访问权限

对于混合的本地环境和云环境,您可以配置本地网络的专用 Google 访问通道以允许服务边界和本地环境之间进行私密通信。这可以允许本地环境访问 BigQuery 数据集。这些请求必须通过与 Google Cloud 的专用连接发送,包括基于路由的 VPN 或 Cloud Interconnect 连接;请求不会遍历公共互联网。

此配置将服务边界从本地网络扩展到存储在 Google Cloud 服务中的数据,从而确保敏感数据的私密性。您只能将此私密通信配置用于 restricted.googleapis.com API。下图展示了此配置的示例。

将服务边界从本地网络扩展到存储在 Google Cloud 服务中的数据。

加密

在检查数据在 Google Cloud 和 BigQuery 上的存储和传输方式时,与本地企业数据仓库相比,重新考虑安全框架是有用的。

BeyondCorp 的动态访问权限控制原则指出,所有访问都必须进行加密。因此,您必须将加密作为一种数据保护方法,以确保即使在不太可能发生数据泄露的情况下,静态数据和传输中的数据也无法被读取。这样一来,加密为数据保护增加了一层防御。

静态加密

默认情况下,Google Cloud 对静态存储的数据进行加密,无需您采取任何额外操作。根据美国国家标准与技术研究院的建议,Google 使用高级加密标准 (AES) 算法对静态数据进行加密。

在将数据写入磁盘之前,BigQuery 数据集中的数据会被分为几个区块。每个区块都使用唯一的数据加密密钥 (DEK) 进行加密。通过使用不同的密钥,在 DEK 被破解(不太可能发生)的情况下,数据泄露仅对该数据区块产生影响。这些密钥本身使用唯一密钥加密密钥 (KEK) 进行加密。虽然加密的 DEK 存储在其关联数据附近,但 KEK 集中存储在 Cloud Key Management Service (KMS) 中。这种用于密钥管理的分层方法称为信封加密。如需了解详情,请参阅静态加密文章的密钥管理部分

下图展示了静态加密的工作原理。

静态加密

默认情况下,所有密钥都由 Google 管理。但是,您可以选择自行管理密钥。此技术称为客户管理的加密密钥 (CMEK)。使用此技术,您可以使用 Cloud KMS 创建、轮替、自动轮替和销毁对称加密密钥。如需详细了解如何将 CMEK 与 BigQuery 结合使用,请参阅使用 Cloud KMS 密钥保护数据

传输加密

如果数据迁移到 Google 控制或 Google 代表方控制的物理边界之外,Google Cloud 会对所有传输中的数据进行加密和身份验证。在这些边界内,传输中的数据通常已经过身份验证,但不一定已加密。

在建立连接并进行身份验证后,传输加密通过以下方式保护您的数据免受潜在攻击:

  • 无需信任通常由第三方提供的较低层网络。
  • 在通信被拦截时,阻止攻击者访问数据。

在较高层级,传输加密的过程如下:在数据传输之前对数据进行加密;验证端点的身份;当数据到达目的地时,解密和验证数据。不过,使用的安全方法取决于被保护的连接类型。本部分重点介绍如何使用加密来保护与 BigQuery 之间的连接。

BigQuery 是一种 Google Cloud 服务,因此当用户或应用向其发送请求时,该请求首先会到达一个名为 Google Front End (GFE) 的全球分布式系统。GFE 终止传入 HTTP(S)、TCP 和 TLX 代理流量的流量,提供 DDoS 攻击对策,并将流量路由和负载平衡到服务本身。

您必须考虑到往返 Google Cloud 服务的流量可能需要采取额外的安全措施。这些安全措施与您迁移上游和下游的流程是相关的。例如,用户或应用与 Google Cloud 上托管的自定义应用之间的请求可以通过多种方式进行路由。通常,如果您使用的是 Cloud Load Balancing,则流量将通过 GFE,因此此路由方式属于上一类。如果您使用的是 Cloud VPN,则连接受 IPsec 保护。另一方面,如果使用外部 IP 地址、网络负载平衡器 IP 地址或通过 Cloud Dedicated Interconnect 直接连接到虚拟机,则默认情况下不会加密连接。因此,我们强烈建议您使用 TLS 等安全协议。

如需详细了解 Google Cloud 如何处理每个连接过程的传输加密,请参阅 Google Cloud 中的传输加密

密钥删除

除了 Google 默认提供的加密之外,您的应用还可以根据需要应用自己的加密,例如,当表中的特定列需要数据脱敏或需要删除密钥时。

密钥删除或密钥销毁是通过删除密钥,让使用该密钥加密的数据无法恢复的过程。由于这些数据再也无法解密,等于有效地删除了数据。

由于此方法只删除密钥而不是全部的加密数据,因此这一删除方法快速、永久,并且广泛用于以下情形:

  • 加密数据远大于密钥,例如,在加密磁盘、电话、数据库记录中。
  • 删除加密数据过于昂贵、复杂或不可行,例如,数据分散在许多代码库中,或位于不可修改的存储空间中。

BigQuery 使用 AEAD 加密概念,提供创建密钥以及加密解密查询中数据的功能。

数据发现

不同规模的组织的可用数据量、种类和速度都在增加。这种数据激增带来了多重挑战:

  • 数据变得越来越难以找到,因为它们是分散的,并非总是整齐有序,并且经常在多个数据代码库中重复存在。
  • 即使您发现了一些数据,也不清楚数据来自哪里,它是否真正代表您所寻找的内容,以及它是否足够可靠以便您做出业务决策。
  • 数据也变得难以管理。您可能不清楚数据所有者是谁、谁有权访问数据,以及访问数据的过程是怎样的。

由描述数据的特性组成的元数据可以解决上述问题。收集元数据类似于为库构建卡片目录,其中每本图书都有一张指示其作者、出版年份、版本、主题等的实体卡片。与图书一样,一段数据也可以附加一组特性,例如其所有者、来源、处理日期或质量评分。

传统上,公司尝试过使用电子表格、维基页面、内部开发的系统和第三方软件等多种方法捕获和整理元数据。常见的问题是需要手动输入、处理和维护数据,以及需要考虑系统兼容性和范围。最后一个问题是,数据发现和元数据收集通常是依赖于人与人之间传递的个人体验的有机过程,这对于不断发展的组织来说是不可扩缩的。在这种情况下,对于一位不在这一人群范围内的分析师,如何才能找到自己可以访问的数据?如何才能理解这些数据?

除了这些内部挑战之外,公司还需要应对不断增加的监管和合规要求,例如一般数据保护条例 (GDPR)、巴塞尔银行监管委员会 239 (BCBS239) 以及健康保险流通与责任法案 (HIPAA)。这些法规要求公司跟踪、保护和报告自己的数据。

Google Cloud 对这些客户需求的响应是通过 Data Catalog 实现的。Data Catalog 是一种全代管式可扩缩的元数据管理服务,可供您的组织在 Google Cloud 中发现、分类和理解您的数据。

Data Catalog 架构基于:

  • 元数据存储:基于 Cloud Spanner,一种全局分布、高度一致的数据库,用于存储所有元数据条目。
  • 实时和批处理同步器:用于自动提取技术元数据。
  • Google 搜索索引:它借助与 Gmail 和 Google Drive 相同的搜索技术,是一个可扩缩且高性能的系统,内置了访问权限控制列表 (ACL)。

Data Catalog 为您提供所有数据资源的统一视图。因此,它为构建可靠的数据治理流程奠定了基础。

下图展示了简化的架构,其中 Data Catalog 为 BigQuery、Pub/Sub 和 Cloud Storage 提供元数据搜索数据泄露防护功能。这些功能将在后面的部分进行讨论。

使用 Data Catalog 简化架构以提供元数据、搜索和数据泄露防护。

元数据

能够找到正确的数据来推动决策制定是数据发现过程的核心。如在图书馆类比中一样,如需找到一本图书,您需要有关可用图书馆图书的元数据,在大数据世界中,您还需要有关数据资源的元数据才能找到它们。

Data Catalog 可以自动从 BigQuery、Pub/Sub 和 Cloud Storage 中提取元数据。它还可以区分两种不同的元数据类型:技术和业务。

一方面,技术元数据包括诸如表名、列名、描述和创建日期之类的信息。此类型的元数据已存在于源系统中。无论这些资源是何时创建的,Data Catalog 都会自动将技术元数据提取到其索引中,而无需手动注册新的数据资源。

另一方面,数据资源附加了隐含的业务上下文,例如列是否包含个人身份信息 (PII)、数据资源的所有者是谁、是需要删除日期还是保留日期以及数据质量得分。这种类型的元数据称为业务元数据

由于不同角色的用户关注业务上下文的不同子集,业务元数据比技术元数据更为复杂。例如,数据分析师可能关注 ETL 作业的状态:它是否成功运行、处理的行数是多少、是否有任何错误或警告等等。产品经理可能关注数据分类:公共或私人数据;数据在生命周期中的位置:生产、测试、质量保证;数据完整性和质量等。

为了处理这种复杂性,Data Catalog 支持您将业务元数据按模板进行分组。 模板是一组称为特性的元数据键值对。拥有一组模板就如同拥有元数据的数据库架构。

元数据标记是模板的实例,可以应用于表和列。当这些标记应用于列时,用户可以确定数据上下文,例如,特定列是否包含 PII、是否已被弃用,甚至还可以确定用来计算特定数量的公式。从本质上讲,业务元数据为您提供了以有意义的方式使用数据的必要上下文。

下图展示了一个示例客户表 (cust_tbl) 以及附加到该表及其列的多个业务元数据标记。

示例客户表格。

除了直观的用户界面,Data Catalog 还为技术用户提供了用于批量注释或检索元数据的 API。该 API 支持的语言是 Python、Java 和 NodeJS。该 API 不仅可以扩缩元数据任务,还可以以编程方式与 Data Catalog 集成,从而使构建使用 Data Catalog 作为后端一部分的自定义企业应用成为可能。

向数据资源添加元数据是数据发现的基础,但它只是整个过程的一部分。过程的另一部分是通过强大的搜索功能发现资源的能力,该功能使用技术和业务元数据来返回相关结果。

Data Catalog 从其来源索引所有元数据,并通过用户友好的界面和用于以编程形式集成的 API 提供元数据。它通过使用与元数据匹配的关键字以 Google 搜索的方式运行。此外,它还为高级用户提供分面搜索。凭借其直观的过滤器和限定谓词,分面搜索允许用户缩小搜索范围,例如,只搜索表格、数据集或文件;或仅在项目、组织或特定 Google Cloud 产品中进行搜索。

Data Catalog 还在其界面中显示了经常被搜索的 BigQuery 表格的列表。此功能可以方便您快捷地访问表格的详细信息、架构和 BigQuery 控制台。

访问权限控制

通过让用户搜索元数据并发现数据资源,您可以提高他们的工作效率、独立性和参与度。但是,并非每个人都应该可以访问每个元数据。当正确的人员可以访问正确的数据时,员工得以专注于与其角色相关的数据资源子集,并有助于防止元数据或数据渗漏。

Data Catalog 与 IAM 集成可以让您控制哪些用户能够在搜索中查找选定的数据资源,或者为资源创建业务元数据。

对于技术元数据,为了简化访问权限管理,自动提取功能对被标记数据授予的元数据使用同一组权限。如果用户有权访问数据,他们也有权访问提取的技术元数据,并能够通过 Data Catalog 搜索找到数据资源。此方法提供合理的默认值,无需人工干预,无需等待注册数据资源和授予一组单独的权限。

对于业务元数据,您可以定义哪些用户或用户组可以访问元数据。其中一些用户可以同时访问元数据和数据、只能访问其中一个、或两者都不可以访问。

  • 如果他们无权访问元数据,他们将无法在 Data Catalog 搜索中找到数据资源。
  • 如果他们可以访问元数据而不可以访问数据,他们将能够找到数据资源,但无法读取数据。此功能允许用户在不暴露底层数据的情况下发现有用的数据集,从而在不影响安全性的情况下提高组织数据资源的易用性。然后,用户可以向数据所有者提出访问请求,该访问请求可能会被批准或拒绝,具体取决于业务用例、数据敏感性和其他因素。

本部分内容介绍了 Data Catalog 如何与 IAM 集成以实施对元数据的访问权限控制。此外,您可以通过向用户授予 Data Catalog 角色来控制谁有权访问 Data Catalog 产品。如需控制对数据资源的访问权限,请结合使用 IAMVPC Service Controls。如需了解详情,请参阅 Data Catalog IAM 文档。

沿袭

在数据仓库情境中,沿袭指的是数据资源从其来源到其目的地的路径。数据资源可以来自外部源(例如由第三方提供的市场数据)或内部源(例如存储客户交易的关系型数据库)。数据资源的目的地可以是作为 API 公开的信息中心、报表或数据 Feed。

在所有这些情况下,重要的是要知道在目的地呈现的数据准确地反映了应用于原始数据的转换。数据使用者能够信任他们所接收的数据、监管机构可以验证和理解所报告的数据、以及内部利益相关者可以识别业务流程中的差距以及数据处理流水线中的相互关系是非常重要的。

需要捕获的数据取决于商业案例的范围。需要捕获的数据可以包括元数据,例如原始数据源、数据所有者、转换数据资源的业务流程或转换期间涉及的应用和服务。

手动捕获此信息容易出错且在非常重要的商业案例中无法进行扩缩。因此,我们建议您从编程角度处理数据沿袭:

  • 确定要捕获的元数据特性集,以满足您的业务或法规需求。
  • 创建模板以捕获此业务的元数据。Data Catalog 支持五种数据类型,您可以将这些数据类型组合在一起以创建复合式标记:doublestringbooleandatetimeenum。最后一种数据类型可以使用一组自定义值来描述数据转换中的阶段或类似的枚举值。
  • 使用 Data Catalog API 在数据流水线的每个相关步骤上记录相关的沿袭元数据。

您可以使用 Google 的 CDAP 托管版 Cloud Data Fusion 来作为 Data Catalog 的替代方案实现数据转换。Cloud Data Fusion 可以将数据处理环境封装在单一受控的环境中,允许在数据集和字段级层自动记录沿袭。如需了解详情,请参阅开源的沿袭的 CDAP 文档

数据分类和管理

在企业数据仓库中,提取的数据量、速度和类型可能会给数据分类和管理带来挑战。

数据分类是按照数据的不同特征将数据分类到不同类型、表单或类别的过程。对于将适当的治理政策应用于不同类型的数据,有效地对数据进行分类至关重要。

例如,根据业务文档的内容,您可以根据其敏感度级层进行分类,例如不安全或机密。然后,您可以对这些类型中的每一种文档使用特定的治理政策,例如:机密文档仅允许特定用户组访问,并且必须保留 7 年。

在数据管理中,您需要考虑以下几个方面:

  • 管理数据更改:控制数据维度更改时的影响。尽管数据维度不经常更改,但修改可能会产生连锁反应,因为事实表中的数据可能不再适用于更新的维度。
  • 管理参考数据:确保组织中的所有系统都能准确一致地查看参考数据。
  • 保留和删除:如何防止用户修改或删除数据,以及如何自动使数据过期。

迁移到 BigQuery 时,请使用 Cloud Data Loss Prevention (DLP) 等数据分类的自动化功能。以下部分介绍了可帮助您在 Google Cloud 中应对数据分类和管理挑战的功能和技术。

数据泄露防护

许多组织拥有数千个包含数百个列的表格。其中一些包含 PII 的表格甚至连列名都不正确或者缺乏描述(例如 Column_5)。这使得识别 PII 并随后对数据应用政策难以着手。

Cloud DLP 让您可以使用一个强大的数据检查、分类和去识别化平台。DLP API 自动扫描数据并创建 Data Catalog 标记以识别敏感数据。它可以与您现有的 BigQuery 表格、Cloud Storage 存储分区或数据流结合使用。

Cloud DLP 可以扫描您的数据并识别 PII,例如电子邮件、信用卡号和社会保障号,并以置信度(例如 99%)报告这些信息,从而方便您自动处理大量数据。如需简化 ETL/ELT 流水线中的 PII 识别,您可以执行以下操作:

  • 将数据提取到隔离的存储分区中。
  • 运行 Cloud DLP 以识别 PII。识别可以通过扫描整个数据集或通过采样数据来完成。DLP API 可以在流水线的转换步骤或独立脚本(如 Cloud Functions)进行调用。本文介绍了使用独立脚本调用 DLP API 的示例。
  • 将数据迁移到仓库。

Cloud DLP 带有 100 多个预定义检测器来识别模式、格式和校验和。它还提供一组工具,对数据进行去标识化处理,包括置换、令牌化、假名化、日期偏移等。此外,Cloud DLP 还可让您使用字典或正则表达式创建自定义检测器。您可以添加“热词”规则来提高结果的准确性,并设置排除规则来减少假正例的数量。

使用 Cloud DLP 可以帮助您对数据进行分类,并为合适的人员提供适当的访问权限,进而改善数据治理。

主数据管理

主数据(也称为参考数据)是在整个组织中使用的数据。主数据资源的常见示例包括客户、产品、供应商、位置和帐号。主数据管理 (MDM) 是一组过程,可确保主数据在整个组织内准确一致。

如需使不同的系统和部门正常地运行和交互,数据的准确性和一致性至关重要。否则,组织的不同部门可能对同一实体具有不同的记录,这可能引发代价高昂的错误。例如,当客户在公司网站上更新了其地址,但结算部门从其他客户端代码库读取客户地址,则未来的帐单可能无法送达此客户。

在 MDM 中,权威系统是特定主数据资源的真实来源。理想情况下,组织中的其他系统使用来自该资源的权威系统的主数据。但是,这并非总是可行,如以下场景所述。

与权威系统直接通信

在这种情况下,系统直接与负责给定主数据资源的权威系统进行通信。权威系统创建和更新主数据,而组织中的其他系统始终使用从相应的权威系统中获取的主数据。

产品信息管理 (PIM) 系统用作整个公司产品的权威系统。

例如,在图中,产品信息管理 (PIM) 系统是整个公司产品的权威系统。当另一个系统(如客户关系管理 (CRM) 系统)需要使用产品主数据时,它会从 PIM 中检索数据。CRM 系统本身可以是不同数据资源(如公司客户)的权威系统。

这种情况是非常理想的,因为它将主数据资源保存在各自的权威系统中,而无需复杂的转换流水线。如果使用方系统仅需要主数据的某个子集或需要与提供的数据格式不同的数据,则该系统有责任对数据进行过滤或转换。

单个来源的黄金副本

在这种情况下,使用方系统无法直接与权威系统通信。造成这些限制的原因可能有所不同,例如:

  • 权威系统可能没有足够的容量或可用性来处理来自整个组织的请求。
  • 系统之间的通信可能受到安全政策的限制,或者由于基础架构的限制而不可行。

如需克服这些限制,您可以通过数据仓库让使用方系统能够使用主数据。迁移到云端时,BigQuery 已经为您提供了一个可用性高的代码库,该代码库可以处理高级别的并发,并且可以按照 IAM 规则在组织内进行广泛访问。因此,BigQuery 是托管您的黄金副本的主要候选者。

我们建议您创建一个 ELT 数据流水线,以从权威系统读取主数据,将其加载到数据仓库中,然后将其分发给使用者。我们更喜欢 ETL 流水线上的 ELT 流水线,因为不同的使用者可能对同一主数据资源有不同的需求,这种实现方式可以将资源不变地加载到数据仓库中,并为使用者创建专门的转换。在 Google Cloud 中,您可以使用 Dataflow 创建可以原生连接到 BigQuery 的流水线。然后,您可以使用 Cloud Composer 来编排这些流水线。

权威系统仍然是数据资源的真实来源,而复制到数据仓库中的主数据称为黄金副本。您的数据仓库不会成为权威系统。

权威系统是数据资源的真实来源。

例如,在图中,CRM 系统不能直接从 PIM 系统请求产品数据。您可以创建一个 ETL 流水线,从 PIM 系统中提取数据,将其复制到数据仓库,执行转换,并将其分发到其他系统,而其中一个系统是 CRM 系统。

如果您的系统批量检索主数据或使用主数据用于分析,BigQuery 是您的黄金副本的理想选择。但是,如果对主数据的大多数访问来自进行单行查询的系统,那么您可能会考虑使用针对这种情况进行了优化的不同代码库,例如 Cloud Bigtable。您还可以同时使用两个代码库来取得平衡。拥有最多流量的那个代码库作为黄金副本系统。我们建议您始终从黄金副本系统中提取数据并将其同步到其他代码库。您可以使用数据流水线来实现此目的。

多个来源的黄金副本

之前的方案使用单个权威系统来处理给定的主数据资源。但是,实际上,组织中的几个系统可能用于保持同一资源的不同特征。例如,PIM 系统可以作为技术和物流产品信息(如尺寸、重量和来源)的真实数据来源。但是,产品目录管理系统可以作为销售相关产品信息(如颜色、销售渠道、价格和季节性)的真实数据来源。对于同一资源,不同系统可能会有重叠的特性,例如,来自先前不属于 MDM 的系统,或通过收购和合并整合入组织的系统。

在这些情况下,需要更复杂的流水线将来自多个源的主数据合并到存储在数据仓库中的单个黄金副本,如下图所示。然后以与前一部分中介绍的类似的方式将数据分发到使用者系统。在这种情况中,您的数据仓库仍然不是权威系统,而只是主数据黄金副本的代码库。

将来自多个源的主数据合并到存储在数据仓库中的单个黄金副本的更复杂的流水线。

在 Google Cloud 中,Dataflow 可以很好地定位为由有向无环图 (DAG) 表示的用于构建复杂流水线的工具。这些流水线从多个源读取数据,并将合并的结果写入 BigQuery。另一种选择是使用可视化工具(如 Cloud Data Fusion)来创建流水线。Cloud Data Fusion 还为数据源和接收器提供了许多插件。

缓慢变化维度

星型雪花型架构的维度表中的特性应该永远不会或极少更改。这种永不变更的特性称为原始特性,例如出生日期和原始信用评分。如果某个特性极少更改,则它所属的维称为缓慢变化维度 (SCD)。当 SCD 更改时,事实表中已有的数据必须引用先前版本的 SCD。因此,您需要一种保留 SCD 的历史记录的方法。

迁移数据仓库时,请考虑整合 SCD 处理方法或改进现有处理方法的机会:

  • 架构和数据传输阶段演变架构时,确保考虑到 SCD。
  • 流水线迁移阶段,确保保留了 SCD 的历史记录并以可重现的方式使用这些记录,例如重新计算回填的输出、由于逻辑更改而进行的重新处理以及跟踪沿袭。

传统的 SCD 处理方法

处理 SCD 变化的传统方法被称为 SCD 类型 0 到 6。最常用的方法是 SCD 类型 2,这种方法通过在维度表中创建额外的列来跟踪历史数据。添加的列包含代理键和以下之一:版本、有效期的开始/结束日期或当前日期加上一个用于指示当前行的标志。如需详细了解如何在 BigQuery 中应用此技术和其他技术,请参阅处理更改

功能数据工程

Apache Airflow 的创建者 Maxime Beauchemin 在 Functional Data Engineering(功能数据工程)这篇文章中提出了另一种处理 SCD 的方法。 本文提出了一种范式,其中数据流水线由在 DAG 中组织的确定性和幂等性任务的集合组成,以反映它们的方向性的相互依存关系。

当一个任务的输出仅依赖于它的输入而不依赖于任何局部或全局状态时,该任务就是确定性的,因此遵循函数式编程的概念。当一个任务可以使用相同的输入参数执行多次并且仍然产生相同的输出时,该任务就是幂等的;换句话说,它不会导致其它的副作用。(这种计算方式的一个示例是 REST PUT 操作。)任务执行被称为任务的实例。具有不同输入的任务实例将数据写入同一输出表格的不同分区。

由于任务的输入之一是维度,因此 Beauchemin 主张在每次触发 ETL 运行时创建维度快照。维度快照复制 ETL 运行所需的所有维度行以及时间戳。维度表成为不同时间点捕获的快照的集合。这些快照维护 SCD 中的更改历史的记录,并允许重新运行任何任务实例,并获得一致的可重现输出。

这种方法与传统的 SCD 处理方法(如 SCD 类型 2)不同。这种方法避免了管理代理键和附加列的复杂性,减少了工程时间,代价是相对比较便宜的存储。本文同意这两种方法可以共存。

在 BigQuery 中处理 SCD

BigQuery 支持星型和雪花型架构,包括其维度表。因此,前两种方法中的任何一种都是适用的。

更进一步的,BigQuery 通过嵌套和重复字段的原生支持来促进架构反规范化。如果事件发生时的特性很重要,可以在事实表中使用这些字段。这些字段也可以在维度表中使用,使用类型 2 或快照方法记录历史值,因此仅需更改特性而不更改整个维度行。

数据保留和删除

在特定情况下,您可能希望阻止用户在 BigQuery 中修改或删除数据。若想执行此限制,您可以将相关用户从具有这些操作权限的角色中移除。这些角色包括 bigquery.dataOwnerbigquery.dataEditorbigquery.admin。 另一个方式是创建不包含特定修改和删除权限的自定义 IAM 角色

如果您需要遵照电子记录保留法规进行操作,我们建议将数据导出到 Cloud Storage 并使用其存储分区锁定功能,如此可助您满足特定记录保留规定。

在其他情况下,您可能需要在给定时间段后自动删除数据。BigQuery 可配置的失效日期功能可以满足此需求。您可以将失效日期应用于数据集表格或特定表分区。 将不需要的数据失效是衡量成本控制和存储优化的标准。 如需了解详情,请参阅 BigQuery 最佳做法。如需详细了解 Google Cloud 上的数据删除,请参阅此文档页面

如果 Google Cloud 客户确定某项法规适用于他们,他们应在自己的法律顾问和相应监管机构的监督下,针对具体要求完成自己的合规性评估。

数据质量管理

数据质量管理流程包括以下内容:

  • 创建用于验证的控制。
  • 启用质量监控和报告。
  • 支持分类过程以评估事件的严重程度。
  • 启用根本原因分析并针对数据问题提出补救建议。
  • 跟踪数据事件。

不同的数据使用者可能具有不同的数据质量要求,因此记录数据质量的预期以及支持数据验证和监控过程的技术和工具非常重要。建立良好的数据质量管理流程有助于为分析提供更值得信赖的数据。

质量元数据

数据仓库为您的决策者提供访问大量精选数据的权限。但是,并非数据仓库中的所有数据都应该以相同的方式进行处理:

  • 在决策制定情境中,高质量的数据应该对您的决策产生更大的影响,而低质量的数据产生的影响应该较小。
  • 在数据质量监控情境中,甚至在数据到达数据仓库之前,也可以使用低质量数据触发自动或手动警报来验证生成它的过程。

此外,组织的不同部分可能设置不同的数据质量阈值。例如,低质量数据可能完全可用于开发和测试,但可能无法用于财务或合规性。

本部分将元数据作为一种机制,为您的决策者和流程提供必要的上下文,以评估呈现给他们的数据。

结构和格式

元数据是附加到一条数据以对该数据进行限定的结构化信息。在数据质量情境中,元数据允许您收集相关特性,如准确性、新鲜度和完整性。

在数据质量元数据 (DQM) 中捕获的语义和特定特性取决于它们限定的业务上下文。我们强烈建议在整个企业中采用一个标准的特性集,以促进沟通和管理。您选择的特性集可以源自行业标准,例如 ISO/IEC 25012:2008 数据质量模型

存储 DQM 并将其呈现给决策者的格式也是一个重要的考虑因素。不同的格式适用于不同的决策任务。例如,Moges 等人编译并呈现了以下 DQM 格式的列表:

  • N 级序数:一组有限值,如优秀、良好和平均。
  • 范围:具有下限和上限的数值量表,例如表示质量级层的 0-100。范围比序数具有更大的灵活性。
  • 概率:0-1 的数据质量量表,表示数据正确的概率。
  • 图形:视觉队列(如颜色),表示质量级。

云端的质量元数据

传统上,公司没有维护一致的 DQM 代码库,而是依赖于共享知识。这些知识有时会存在于互不相交的代码库中,例如电子表格、内网页面和临时数据库表。发现、搜索、理解和维护这些不同的 DQM 源所需的努力妨碍协作,并且可能大于它们为决策支持带来的价值。

Data Catalog 为您提供了一种集中管理元数据的方式:

  • 自定义元数据标记(也称为业务元数据)支持您选择作为标准定义一部分的任何数据质量特性,并将这些特性分组为可针对每个业务情境自定义的逻辑模板
  • Data Catalog 支持自定义枚举类型(用于表示序数特性),以及双精度和字符串类型(用于表示可在不同图形呈现项目中使用的范围、概率和数值)。您可以通过 Data Catalog 界面或通过其 API 和客户端库访问这些元数据值,为决策者构建自定义应用。
  • 您可以在上游流程中使用 Data Catalog API。 当给定源的数据质量低于阈值时,该过程会标记低质量数据,并在它到达 BigQuery 之前触发提醒。数据本身可以发送到 Cloud Storage 中的隔离的存储分区进行验证,并可能进行补救和重新处理。

DQM 注意事项

您可能认为,如果没有 DQM,决策者更有可能使用低质量数据并做出糟糕的决策。实际上,添加 DQM 可能会使决策者不堪重负,因为他们需要了解大量信息来生成替代方案,这可能会对决策的时效和质量产生负面影响。

因此,对决策者进行 DQM 语义和最佳做法方面的培训至关重要。Moges 等人建议,针对那些使用低质量数据会导致严重后果的关键任务提供 DQM 和培训。但是,对于要求高效率的任务,或者没有经过适当培训的人员,DQM 可能会适得其反。

审核

组织必须能够审核他们的系统,以确保系统按照设计工作。监控、审核和跟踪可帮助安全团队收集数据、识别威胁,并应对威胁,以避免这些威胁造成业务破坏或损失。执行定期审核是非常重要的,因为这些审核可以检查控制的有效性,以便快速缓解威胁并评估整体安全运行状况。审核还可以证明对外部审核人员的监管合规性。

确保健康的数据访问权限控制的第一步是定期审核与您的 Google Cloud 项目和各个 BigQuery 数据集关联的用户和组。审核的内容包括,这些用户是否需要作为所有者或管理员,或者更具限制性的角色是否足以履行其工作职责?审核有能力更改您项目中的 IAM 政策的人员也很重要。

分析日志的第二步是回答“哪些用户何时在何处使用 BigQuery 数据和元数据执行了什么操作”的疑问。

  • 对于您的数据,BigQuery 默认会在 Cloud Logging 中包含两个不可变更的日志流:管理员活动审核日志和数据访问审核日志。
  • 对于元数据,Data Catalog 还支持审核两种日志记录流,但与 BigQuery 不同,您必须手动启用数据访问日志记录。

管理员活动日志包含日志调用或其他用于修改资源配置或元数据的管理操作对应的日志条目。例如,创建新服务帐号或更改 IAM 权限(如授予新用户读取 BigQuery 数据集的权限)将记录在管理员活动日志中。

数据访问日志可记录创建、修改或读取用户提供的数据的通过用户身份验证的 API 调用。例如,如果用户查询 BigQuery 数据集或请求查询结果,则数据访问日志会记录相关信息。将查询归因于用户而不是服务帐号有助于审核数据访问。

对于这两种类型的日志,您可以创建在指定的特定条件下触发的 Cloud Monitoring 提醒。触发后,这些提醒可以通过多种渠道发送通知,包括电子邮件、短信、第三方服务甚至是自定义网址的网络钩子。

请注意,审核日志可能包含敏感信息,因此您可能希望限制对日志的访问。您可以使用 IAM 角色来限制对审核日志的访问权限

您还应该考虑从 Cloud Logging 将 BigQuery 审核日志导出到 BigQuery 数据集,原因如下:

  • Cloud Logging 将仅在有限的日志保留期限内保留审核日志。将审核日志导出到另一个安全的存储位置(如 BigQuery 或 Cloud Storage)可以使您拥有更长期的保留期限。
  • 在 BigQuery 中,您可以在日志中运行 SQL 查询,从而实现复杂的过滤以进行分析。
  • 此外,您还可以使用 Google 数据洞察等可视化工具创建信息中心

如需了解详情,请参阅此“使用 Google Cloud 审核日志的最佳做法”博文

后续步骤

  • 继续阅读本系列文章的后续篇:数据流水线
  • 探索有关 Google Cloud 的参考架构、图表、教程和最佳做法。查看我们的云架构中心