你好，哈布尔！ OTUS 新课程现已开放报名 。 在课程开始之前，我们按照惯例为您准备了有趣材料的翻译。
每天都有超过一亿人访问 Twitter，了解世界上正在发生的事情并进行讨论。 每条推文和每个其他用户操作都会生成一个事件，可用于 Twitter 的内部数据分析。 数百名员工对这些数据进行分析和可视化，改善他们的体验是 Twitter 数据平台团队的首要任务。
我们相信，具有广泛技术技能的用户应该能够发现数据并能够访问性能良好的基于 SQL 的分析和可视化工具。 这将使一群技术含量较低的全新用户（包括数据分析师和产品经理）能够从数据中提取见解，从而更好地理解和使用 Twitter 的功能。 这就是我们在 Twitter 上实现数据分析民主化的方式。
随着我们的工具和内部数据分析能力的改进，我们看到了 Twitter 的进步。 然而，仍有改进的空间。 目前的工具（例如 Scalding）需要编程经验。 Presto 和 Vertica 等基于 SQL 的分析工具存在大规模性能问题。 我们还面临跨多个系统分发数据而无法持续访问数据的问题。
去年我们宣布 ，其中我们转移了我们的部分 在谷歌云平台（GCP）上。 我们得出的结论是 Google Cloud 工具 可以帮助我们在 Twitter 上实现分析、可视化和机器学习民主化的举措：
- ：基于SQL引擎的企业数据仓库 ，以其速度、简单性和应对 .
- 大数据可视化工具，具有类似 Google Docs 的协作功能。
在本文中，您将了解我们使用这些工具的经验：我们做了什么、学到了什么以及下一步将做什么。 我们现在将重点关注批量和交互式分析。 我们将在下一篇文章中讨论实时分析。
Twitter 数据存储的历史
在深入探讨 BigQuery 之前，有必要简要回顾一下 Twitter 数据仓库的历史。 2011年，Twitter数据分析是在Vertica和Hadoop中进行的。 我们使用 Pig 创建 MapReduce Hadoop 作业。 2012 年，我们用 Scalding 取代了 Pig，Scalding 具有 Scala API，具有创建复杂管道的能力和易于测试等优点。 然而，对于许多更喜欢使用 SQL 的数据分析师和产品经理来说，这是一个相当陡峭的学习曲线。 2016 年左右，我们开始使用 Presto 作为 Hadoop 数据的 SQL 接口。 Spark 提供了 Python 接口，这使其成为临时数据科学和机器学习的不错选择。
自2018年以来，我们使用了以下工具进行数据分析和可视化：
- 生产输送机烫金
- 用于临时数据分析和机器学习的 Scalding 和 Spark
- Vertica 和 Presto 用于即席和交互式 SQL 分析
- Druid 用于低交互、探索性和低延迟地访问时间序列指标
- 用于数据可视化的 Tableau、Zeppelin 和 Pivot
我们发现，虽然这些工具提供了非常强大的功能，但我们很难将这些功能提供给 Twitter 上更广泛的受众。 通过使用 Google Cloud 扩展我们的平台，我们致力于简化所有 Twitter 的分析工具。
Google 的 BigQuery 数据仓库
Twitter 的几个团队已经将 BigQuery 纳入他们的一些生产管道中。 利用他们的专业知识，我们开始评估 BigQuery 针对所有 Twitter 使用案例的功能。 我们的目标是向整个公司提供 BigQuery，并在数据平台工具集中对其进行标准化和支持。 由于多种原因，这很困难。 我们需要开发一个基础设施来可靠地获取大量数据、支持公司范围内的数据管理、确保适当的访问控制并确保客户隐私。 我们还必须创建资源分配、监控和退款系统，以便团队可以有效地使用 BigQuery。
2018 年 250 月，我们发布了 BigQuery 和 Data Studio 的全公司 alpha 版本。 我们为 Twitter 员工提供了一些最常用的电子表格，其中包含经过清理的个人数据。 BigQuery 已被来自工程、财务和营销等各个团队的 8 多名用户使用。 最近，他们运行了大约 100k 个请求，每月处理大约 XNUMX PB，不包括计划的请求。 在收到非常积极的反馈后，我们决定继续提供 BigQuery 作为与 Twitter 上的数据交互的主要资源。
这是我们的 Google BigQuery 数据仓库架构的高级图表。
我们使用内部 Cloud Replicator 工具将数据从本地 Hadoop 集群复制到 Google Cloud Storage (GCS)。 然后，我们使用 Apache Airflow 创建使用“的管道”» 将数据从 GCS 加载到 BigQuery 中。 我们使用 Presto 查询 GCS 中的 Parquet 或 Thrift-LZO 数据集。 BQ Blaster 是一个内部 Scalding 工具，用于将 HDFS Vertica 和 Thrift-LZO 数据集加载到 BigQuery 中。
在以下部分中，我们将讨论我们在易用性、性能、数据管理、系统运行状况和成本方面的方法和专业知识。
易于使用
我们发现，用户很容易开始使用 BigQuery，因为它不需要安装软件，并且用户可以通过直观的网络界面进行访问。 但是，用户需要熟悉 GCP 的一些功能和概念，包括项目、数据集和表格等资源。 我们开发了教育材料和教程来帮助用户入门。 通过获得基本的了解，用户发现可以轻松地在 Data Studio 中导航数据集、查看架构和表数据、运行简单查询以及可视化结果。
我们将数据输入 BigQuery 的目标是一键无缝加载 HDFS 或 GCS 数据集。 我们考虑过 （由 Airflow 管理），但由于我们的域限制共享安全模型而无法使用它（更多信息请参见下面的数据管理部分）。 我们尝试使用 Google 数据传输服务 (DTS) 来编排 BigQuery 工作负载。 虽然 DTS 的设置速度很快，但它在构建具有依赖关系的管道时并不灵活。 对于我们的 alpha 版本，我们在 GCE 中构建了自己的 Apache Airflow 框架，并准备将其在生产中运行，并能够支持更多数据源，例如 Vertica。
要将数据转换为 BigQuery，用户可以使用计划查询创建简单的 SQL 数据管道。 对于具有依赖关系的复杂多级管道，我们计划使用我们自己的 Airflow 框架或 Cloud Composer 以及 .
Производительность
BigQuery 专为处理大量数据的通用 SQL 查询而设计。 它不适用于事务数据库所需的低延迟、高吞吐量查询，也不适用于实施的低延迟时间序列分析 。 对于交互式分析查询，我们的用户期望响应时间少于一分钟。 我们必须设计 BigQuery 的使用来满足这些期望。 为了为用户提供可预测的性能，我们利用了 BigQuery 功能，该功能以固定费用向客户提供，允许项目所有者为其查询保留最少的槽位。 BigQuery 是执行 SQL 查询所需的计算能力单位。
我们分析了 800 多个查询，每个查询处理大约 1 TB 的数据，发现平均执行时间为 30 秒。 我们还了解到，性能很大程度上取决于我们在不同项目和任务中的槽位使用情况。 我们必须清楚地划分我们的生产和临时槽储备，以维持生产用例和在线分析的性能。 这极大地影响了我们对插槽预留和项目层次结构的设计。
我们将在接下来的几天翻译的第二部分中讨论系统的数据管理、功能和成本，但现在我们邀请大家 ，在此期间您将能够详细了解该课程，并向我们的专家 Egor Mateshuk（MaximaTelecom 高级数据工程师）提问。
阅读更多：
来源： habr.com