Google BigQuery 如何实现数据分析民主化。 第2部分

你好，哈布尔！ OTUS 新课程现已开放报名 数据工程师。 在课程开始之前，我们将继续与您分享有用的材料。

阅读第一部分

数据管理

强大的数据治理是 Twitter 工程的核心宗旨。 当我们在平台中实施 BigQuery 时，我们专注于数据发现、访问控制、安全和隐私。

为了发现和管理数据，我们将数据访问层扩展到 DAL）为本地和 Google Cloud 数据提供工具，为我们的用户提供单一界面和 API。 正如谷歌 资料目录 正朝着普遍可用性的方向发展，我们将把它包含在我们的项目中，为用户提供列搜索等功能。

BigQuery 使共享和访问数据变得容易，但我们需要对此进行一些控制以防止数据泄露。 在其他工具中，我们选择了两个功能：

• 域限制共享：测试版功能可防止用户与 Twitter 之外的用户共享 BigQuery 数据集。
• VPC 服务控制：防止数据泄露并要求用户从已知 IP 地址范围访问 BigQuery 的控件。

我们已实施身份验证、授权和审核 (AAA) 安全要求，如下所示：

• 身份验证：我们使用 GCP 用户帐户来处理临时请求，使用服务帐户来处理生产请求。
• 授权：我们要求每个数据集都有一个所有者服务帐户和一个读者组。
• 审核：我们将包含详细查询执行信息的 BigQuery stackdriver 日志导出到 BigQuery 数据集中，以便于分析。

为了确保 Twitter 用户的个人数据得到正确处理，我们必须注册所有 BigQuery 数据集、注释个人数据、维护适当的存储以及删除（抓取）用户已删除的数据。

我们查看了谷歌 云数据丢失防护 API，它使用机器学习来分类和编辑敏感数据，但由于准确性而决定支持手动注释数据集。 我们计划使用数据丢失防护 API 来增强自定义注释。

在 Twitter，我们为 BigQuery 中的数据集创建了四个隐私类别，此处按敏感度降序列出：

• 根据最小权限原则按需提供高度敏感的数据集。 每个数据集都有一个单独的读者组，我们将跟踪各个帐户的使用情况。
• 中等敏感度数据集（使用加盐哈希的单向假名）不包含个人身份信息 (PII)，可供更多员工访问。 这是隐私问题和数据有用性之间的良好平衡。 这使得员工可以执行分析任务，例如计算使用某个功能的用户数量，而无需知道真正的用户是谁。
• 包含所有用户识别信息的低敏感度数据集。 从隐私角度来看，这是一个很好的方法，但不能用于用户级分析。
• 公共数据集（在 Twitter 外部发布）可供所有 Twitter 员工使用。

至于日志记录，我们使用计划任务来枚举 BigQuery 数据集并将它们注册到数据访问层（DAL），Twitter 元数据存储库。 用户将使用隐私信息注释数据集，并指定保留期限。 至于清洁，我们评估了两种选择的性能和成本： 1. 使用 Scalding 等工具清理 GCS 中的数据集并将其加载到 BigQuery 中； 2. 使用 BigQuery DML 语句。 我们可能会结合使用这两种方法来满足不同群体和数据的要求。

系统功能

由于 BigQuery 是一项托管服务，因此无需让 Twitter 的 SRE 团队参与系统管理或办公室职责。 为存储和计算提供更多容量很容易。 我们可以通过在 Google 支持下创建票证来更改时段预订。 我们确定了可以改进的领域，例如自助服务时段分配和用于监控的仪表板改进，并向 Google 提交了这些请求。

成本

我们的初步分析表明 BigQuery 和 Presto 的查询成本处于同一水平。 我们购买了插槽 固定 价格有稳定的每月费用而不是付款 在需求 每 TB 处理的数据。 这一决定也是基于用户的反馈，他们不想在提出每个请求之前考虑成本。

除了 GCS 成本之外，在 BigQuery 中存储数据还带来了成本。 像 Scalding 这样的工具需要 GCS 中的数据集，要访问 BigQuery，我们必须将相同的数据集加载为 BigQuery 格式 电容器。 我们正在研究与 BigQuery 数据集的 Scalding 连接，这将消除在 GCS 和 BigQuery 中存储数据集的需要。

对于需要数十 PB 的不频繁查询的极少数情况，我们认为将数据集存储在 BigQuery 中并不划算，因此使用 Presto 直接访问 GCS 中的数据集。 为此，我们正在研究 BigQuery 外部数据源。

下一步

自 Alpha 版本发布以来，我们看到了人们对 BigQuery 的浓厚兴趣。 我们正在向 BigQuery 添加更多数据集和更多命令。 我们为 Scalding 等数据分析工具开发连接器，以读取和写入 BigQuery 存储。 我们正在研究 Looker 和 Apache Zeppelin 等工具，用于使用 BigQuery 数据集创建企业质量报告和注释。

我们与 Google 的合作非常富有成效，我们很高兴继续并发展这种合作伙伴关系。 我们与 Google 合作实施我们自己的 合作伙伴问题跟踪器直接向 Google 发送查询。 其中一些，例如 BigQuery Parquet 加载器，已经由 Google 实现。

以下是我们向 Google 提出的一些高优先级功能请求：

• 用于方便数据接收并支持 LZO-Thrift 格式的工具。
• 按小时细分
• 访问控制改进，例如表级、行级和列级权限。
• BigQuery的 外部数据源 与 Hive Metastore 集成并支持 LZO-Thrift 格式。
• 改进了 BigQuery 用户界面中的数据目录集成
• 时段分配和监控的自助服务。

结论

以安全的方式实现数据分析、可视化和机器学习的大众化是数据平台团队的首要任务。 我们将 Google BigQuery 和 Data Studio 确定为可以帮助实现这一目标的工具，并于去年在全公司范围内发布了 BigQuery Alpha。

我们发现 BigQuery 中的查询既简单又高效。 我们使用 Google 工具来提取和转换简单管道的数据，但对于复杂的管道，我们必须构建自己的 Airflow 框架。 在数据管理领域，BigQuery 的身份验证、授权和审计服务满足了我们的需求。 为了管理元数据和维护隐私，我们需要更大的灵活性，并且必须构建自己的系统。 BigQuery 作为一项托管服务，很容易使用。 查询成本与现有工具类似。 除了 GCS 成本之外，在 BigQuery 中存储数据还会产生成本。

总体而言，BigQuery 非常适合常规 SQL 分析。 我们看到人们对 BigQuery 很感兴趣，我们正在努力迁移更多数据集，引入更多团队，并使用 BigQuery 构建更多管道。 Twitter 使用各种数据，需要结合使用 Scalding、Spark、Presto 和 Druid 等工具。 我们打算继续加强我们的数据分析工具，并就如何最好地使用我们的产品向我们的用户提供明确的指导。

感恩的话语

我要感谢我的合著者和队友 Anju Jha 和 Will Pascucci 在这个项目上的出色合作和辛勤工作。 我还要感谢 Twitter 和 Google 多个团队的工程师和经理为我们提供的帮助，以及 Twitter 上提供宝贵反馈的 BigQuery 用户。

如果您有兴趣解决这些问题，请查看我们的 职位空缺 在数据平台团队中。

DWH 中的数据质量 - 数据仓库一致性

来源： habr.com