5

优步分享基于Apache Kafka的Presto使用经验

 2 years ago
source link: https://www.jdon.com/61141
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

优步分享基于Apache Kafka的Presto使用经验
Presto和 Apache Kafka  在 Uber 的大数据堆栈中发挥着关键作用。
Presto 是查询联合的事实标准,已用于交互式查询、近实时数据分析和大规模数据分析。
Kafka 是支持许多用例的数据流的骨干,例如发布/订阅、流处理等。

通过Presto on Kafka,可以编写一个简单的 SQL 查询SELECT FROM kafka.cluster.order WHERE uuid = '0e43a4-5213-11ec'并且可以在几秒钟内返回结果。 
越来越多的用户正在采用 Presto on Kafka 进行临时探索。每天有 6,000 个查询,我们还从 Presto 用户那里得到了很好的反馈,他们说 Presto on Kafka 使他们的数据分析变得更加容易。

为什么要使用Presto?
运营团队正在调查为什么有几条消息没有被关键服务处理,这将对最终客户产生直接影响。
然后运维团队收集了报告问题的几个UUID,并要求检查它们是否存在于服务的输入/输出 Kafka 流中:
“Is the order with UUID X missing in the Kafka topic T.” 

这样的问题通常通过大数据中的实时分析来解决。在该领域可用的各种技术中,我们专注于 2 类开源解决方案,即:流处理实时 OLAP 数据存储

Apache FlinkApache Storm ksql等流处理引擎连续处理流并输出处理后的流或增量维护可更新视图。这种流处理不适合上述问题,因为用户希望对过去的事件执行点实现查找或运行分析查询。

另一方面,Apache Pinot、Apache Druid 和Clickhouse 等实时OLAP数据存储则更适合。这些OLAP存储配备了先进的索引技术,因此它们能够对Kafka数据流进行索引,以提供低延迟的查询。
事实上,Uber几年前就采用了Apache Pinot,如今Pinot是Uber数据平台内部的一项关键技术,为多个关键任务的实时分析应用提供动力。
然而,实时OLAP需要一个非同寻常的onboarding过程,以创建一个从Kafka流中摄取的表,并调整该表以获得最佳性能。

这个问题促使Kafka和Presto团队共同探索一个轻量级的解决方案,并考虑到以下因素。

  • 它重用了现有的Presto部署,这是一项成熟的技术,已经在Uber经过了多年的实战检验。
  • 它不需要onboarding,Kafka主题可以被发现,并且在创建后可以立即被查询。
  • Presto以其强大的跨数据源的查询联合能力而闻名,因此它允许Kafka和其他数据源(如Hive/MySQL/Redis)之间的关联,以获得跨数据平台的洞察力。

然而,这种Presto方法也有其局限性。例如,它的性能不如实时OLAP存储,因为Kafka连接器没有建立索引,因此必须在一个偏移范围内扫描Kafka流。此外,为了满足Uber的可扩展性要求,在连接器上还有其他挑战需要解决,我们将在下一节详细说明。

Presto面临挑战?

Presto已经有一个支持通过 Presto 查询 Kafka的Kafka 连接器。但是,该解决方案并不完全适合我们在 Uber 拥有的大规模 Kafka 架构。有几个挑战:

  • Kafka 主题和集群发现:在我们提供 Kafka 即服务的 Uber,用户可以随时通过自助服务门户将新主题加入 Kafka。因此,我们需要 Kafka 主题发现是动态的。但是,当前 Presto Kafka 连接器中的 Kafka 主题和集群发现是静态的,每次我们加入新主题时都需要重新启动连接器。 
  • 数据模式发现:与 Kafka 主题和集群发现类似,我们将模式注册表作为服务提供并支持用户自助登录。因此,我们需要 Presto-Kafka 连接器能够按需检索最新的模式。 
  • 查询限制:限制每个查询可以从 Kafka 消费的数据数量对我们来说很重要。Uber 有许多大型 Kafka 主题,其字节速率可以高达 500 M/s。 众所周知,Presto-Kafka 查询与其他替代方案相比相对较慢,从 Kafka 拉取大量数据的查询将需要很长时间才能完成。这不利于用户体验,也不利于 Kafka 集群的健康。
  • 配额控制:作为分布式查询引擎,Presto 可以以非常高的吞吐量同时消费来自 Kafka 的消息,这可能导致 Kafka 集群的潜在集群降级。限制最大 Presto 消耗吞吐量对于 Kafka 集群的稳定性至关重要。

优步的改进
Uber 的数据生态系统为用户提供了一种编写 SQL 查询并将其提交到 Presto 集群执行的方式。每个 Presto 集群都有一个 coordinator 节点,负责解析 SQL 语句,规划查询,调度任务,让 worker 节点执行。Presto 中的 Kafka 连接器允许将 Kafka 主题用作表,其中主题中的每条消息在 Presto 中表示为一行。在收到查询时,协调器确定查询是否具有适当的过滤器。验证完成后,Kafka 连接器从 Kafka 集群管理服务获取集群和主题信息。然后它从模式服务中获取模式。然后 Presto 工作人员与 Kafka 集群并行对话以获取所需的 Kafka 消息。我们还在 Kafka 集群上为 Presto 用户设置了代理配额。

详细点击标题


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK