每天，有超过一亿人访问Twitter，以查找并讨论世界上正在发生的事情。每个推文和每个其他用户操作都会生成一个事件，可用于Twitter上的内部数据分析。数以百计的员工正在分析和可视化这些数据，并且改善他们的体验是Twitter数据平台团队的当务之急。
我们认为，具有广泛技术技能的用户应该能够找到数据，并能够使用性能良好的基于SQL的分析和可视化工具。这样一来，全新的用户群体（包括数据分析师和产品经理）就可以从技术中减少技术偏见，从而从数据中提取信息，从而使他们能够更好地理解和使用Twitter的功能。这就是我们使Twitter数据分析民主化的方式。
随着我们用于内部数据分析的工具和功能的改进，我们看到了Twitter服务的改进。但是，仍有改进的空间。当前的工具（例如缩放）需要编程经验。 Presto和Vertica等基于SQL的分析工具在很大程度上存在性能问题。我们还有一个问题，就是在不间断地访问数据的情况下，将数据分布在多个系统上。
去年，我们宣布了与Google的新合作伙伴关系，即将部分数据基础架构引入Google Cloud Platform（GCP）。我们已经得出结论，Google Cloud大数据工具 可以帮助我们采取主动行动，使Twitter上的分析，可视化和机器学习民主化：
- BigQuery：具有Dremel的SQL引擎的企业数据仓库，以其速度，简便性和机器学习而著称。
- Data Studio：具有协作功能（例如Google Docs）的大数据可视化工具。
在本文中，您将了解我们在这些工具上的经验：我们做了什么，我们学到了什么以及下一步将做什么。现在，我们将专注于批处理和交互式分析。我们将在下一篇文章中讨论实时分析。
Twitter数据存储历史
在开始使用BigQuery之前，值得简要回顾一下Twitter数据存储的历史。2011年，Twitter数据分析在Vertica和Hadoop中进行。为了创建MapReduce Hadoop作业，我们使用了Pig。在2012年，我们用Scalding取代了Pig，后者具有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纳入了一些生产流程。利用他们的经验，我们开始评估所有Twitter用例的BigQuery功能。我们的目标是向整个公司提供BigQuery，并在数据平台工具箱中对其进行标准化和支持。由于许多原因，这很困难。我们需要设计基础架构，以可靠地接收大量数据，支持整个公司的数据管理，确保适当的访问控制，并确保客户隐私。我们还必须构建用于资源分配，监控和退款的系统，以便团队可以有效地使用BigQuery。
2018年11月，我们为整个公司发布了BigQuery和Data Studio的Alpha版本。我们为Twitter员工提供了一些我们最常用的个人数据清除电子表格。 BigQuery已被来自工程，财务和营销等各个团队的250多个用户使用。最近，他们运行了大约8,000个请求，每月处理大约100 PB，不包括计划的请求。在收到非常积极的反馈后，我们决定继续前进，并提供BigQuery作为我们与Twitter上的数据进行交互的主要资源。
这是Google BigQuery数据仓库的高层架构图。
我们使用内部Cloud Replicator工具将数据从本地Hadoop集群复制到Google Cloud Storage（GCS）。然后，我们使用Apache Airflow创建使用“ bq_load ”的管道，以将数据从GCS加载到BigQuery中。我们使用Presto在GCS中查询Parquet或Thrift-LZO数据集。BQ Blaster是一种内部缩放工具，用于将Vertica和Thrift-LZO HDFS数据集上载到BigQuery。
在以下各节中，我们将讨论易用性，性能，数据管理，系统运行状况和成本方面的方法和知识。
使用方便
我们发现，由于BigQuery不需要安装软件，并且可以通过直观的Web界面进行访问，因此用户可以轻松上手。但是，用户需要熟悉GCP的某些功能及其概念，包括项目，数据集和表格等资源。我们已经开发了教程和教程来帮助用户入门。有了基本了解，用户可以轻松地导航数据集，查看架构和表数据，运行简单查询以及在Data Studio中可视化结果。
就将数据输入BigQuery而言，我们的目标是确保一键式平稳加载HDFS或GCS数据集。我们考虑过Cloud Composer（由Airflow管理），但由于我们的域受限共享安全模型而无法使用（有关更多信息，请参见下面的“数据管理”部分）。我们尝试使用Google数据传输服务（DTS）来组织BigQuery加载任务。尽管DTS可以快速设置，但对于构建依赖关系管道而言并不灵活。对于Alpha，我们已经在GCE中创建了自己的Apache Airflow环境，并正在准备将其投入生产并能够支持Vertica等更多数据源。
要将数据转换为BigQuery，用户可以使用计划的查询创建简单的SQL数据管道。对于复杂的多阶段依赖关系管道，我们计划将自己的Airflow框架或Cloud Composer与Cloud Dataflow一起使用。
性能
BigQuery设计用于处理大量数据的通用SQL查询。它不适用于事务数据库所需的低延迟，高吞吐量查询，也不适用于Apache Druid实现的低延迟时间序列分析。对于交互式分析查询，我们的用户期望响应时间少于一分钟。我们必须设计BigQuery用法以满足这些期望。为了确保我们的用户具有可预测的性能，我们使用了BigQuery这一功能，该功能可统一提供给客户，使项目所有者可以为其查询保留最少的广告位。插槽BigQuery是执行SQL查询所需的计算能力的单位。
我们分析了800多个查询，每个查询处理大约1 TB数据，发现平均执行时间为30秒。我们还了解到，性能在很大程度上取决于我们在各种项目和任务中对广告位的使用。我们必须清楚地区分我们的生产和临时插槽储备，以保持生产用例和交互式分析的性能。这极大地影响了我们的广告位预定和项目层次设计。
我们将在翻译的第二部分中讨论未来几天的数据管理，系统功能和成本，现在，我们邀请所有人参加免费的在线研讨会, , — (Senior Data Engineer, MaximaTelecom).