在 Twitter，我们实时处理大约 4000 亿个事件并每天生成 PB 级数据。Twitter 的各个团队可以通过不同的方式利用这些数据为每个人构建更好的 Twitter。
从广义上看，我们可以将一个全面而强大的大数据平台的基础设施和工具分为三类——数据处理、数据存储和数据消费。在整个行业中，我们拥有强大的基础架构来处理 PB 级数据（例如 Spark、Cloud Dataflow、Airflow）和存储海量数据，例如分布式 blobstore（GCS、S3、Hadoop、Columnar DB、BigQuery）。然而，在通过仪表板、可视化和报告从这些 EB 级数据平台收集及时、有意义和可操作的见解方面仍然存在重大挑战。
问题
行业中当前使用的数据消费产品的最大障碍之一是需要后台处理，工程师和分析师需要在消费前创建仪表板、报告等。这会带来挑战：
- 降低数据的时间价值，从而影响 Twitter 及时做出数据驱动决策的能力。
- 增加从新属性、功能和仪表板生成洞察的总成本。由于不断变化的业务需求，工程师/分析师必须投资于仪表板/报告的持续开发和维护。
- 错失良机，因为当前的工具无法根据我们的内部业务客户可能认为有用的信息来预测和主动从 EB 数据中获得洞察力。目前，问题是人为发起的，而不是人为和平台发起的。
解决方案
在过去的 20 年中，洞察产品从交叉表报告（90 年代后期）和仪表板（2000 年代）到沉浸式可视化（2010 年代）已经走过了漫长的道路。随着自然语言处理和机器学习的最新进展，有一个独特的机会来消费来自 exa-scale 平台的数据，以获得直观和及时的见解。
如果我们要满足数据库的临时用户的需求，我们必须突破目前阻碍这些用户用母语来表达他们想要什么的障碍：
我们建立了一个名为Qurious的内部产品，它允许我们的内部商业客户用他们的自然语言提出问题。然后，他们就可以实时获得洞察力，而不需要创建仪表盘。该产品包括一个网络应用程序和一个Slack聊天机器人，两者都与BigQuery和Data QnA APIs集成。
步骤：
- 用户在以下其中一个地方输入问题。
- Slack聊天机器人
- 网络应用程序 - 问题从Google Cloud Load Balancer或NgRoutes被路由到Google Kubernetes Engine。
- 问题请求被转发到Data QnA
- 数据QnA返回包含用户问题的建议SQL查询翻译的响应
- SQL查询翻译被发送到BigQuery执行。
- 出口代理（Egress Proxy）将来自查询执行的数据路由到Qurious Slack App。云负载平衡将来自查询执行的数据返回给Qurious网络应用。
- 用户的问题和返回的响应被存储在Google Cloud Storage/Cloud SQL中。此外，还启用了日志和身份管理
详细点击标题