使用ClickHouse对每秒6百万次请求进行HTTP分析

in 互联网技术 with 0 comment  访问: 374 次

我们在Cloudflare的一个大规模数据基础架构挑战是为我们的客户提供HTTP流量分析。我们所有客户都可以通过两种方式使用HTTP分析:

在这篇博文中,我将谈谈去年Cloudflare分析管道的令人兴奋的演变。我将首先介绍旧管道以及我们遇到的挑战。然后,我将描述我们如何利用ClickHouse构建新的和改进的管道的基础。在此过程中,我将分享有关我们如何进行ClickHouse的架构设计和性能调整的详细信息。最后,我期待数据团队将来考虑提供什么。

让我们从旧数据管道开始。

老数据管道架构

之前的管道建于2014年。之前已经在使用CitusDB和更多数据扩展PostgreSQL for CloudFlare Analytics,以及来自Data团队的更多数据博客文章中提到过。 它有以下组件:
15366370515931.jpg

自从该管道最初于2014年设计以来,Cloudflare已经大幅增长。它开始以每秒1M的请求处理,并且发展到当前每秒6M请求的水平。多年来,管道为我们和我们的客户提供了很好的服务,但在接缝处开始分裂。在需求发生变化时,应在一段时间后重新设计任何系统。

原始管道的一些具体缺点是:

随着时间的推移,随着我们的请求数量的增长,操作此管道的挑战变得更加明显,我们意识到这个系统正在被推到极限。这种认识激发了我们思考哪些组件将成为替代的理想候选者,并促使我们构建新的数据管道。

我们的第一个改进分析管道设计以使用Apache Flink流处理系统为中心。我们以前曾使用Flink作为其他数据管道,所以对我们来说这是一个很自然的选择。但是,这些管道的速度远远低于我们需要为HTTP Analytics处理的每秒6M请求,并且我们很难让Flink扩展到此卷 - 它无法跟上每个分区的摄取率每秒所有6M HTTP请求。

我们的DNS团队的同事已经在ClickHouse上构建并生成了DNS分析管道。他们在Cloudflare如何分析每秒1M DNS查询博客文章中写到了这一点。所以,我们决定深入研究一下ClickHouse。

ClickHouse

“ClickHouseнетормозит。”
来自俄语的翻译:ClickHouse没有刹车(或者不慢)
©ClickHouse核心开发者

在探索替换旧管道的一些关键基础架构的其他候选者时,我们意识到使用面向列的数据库可能非常适合我们的分析工作负载。我们希望确定一个面向列的数据库,该数据库具有水平可扩展性和容错性,可以帮助我们提供良好的正常运行时间保证,并且具有极高的性能和空间效率,从而可以处理我们的规模。我们很快意识到ClickHouse可以满足这些标准,然后是一些标准。

ClickHouse是一个面向开源列的数据库管理系统,能够使用SQL查询实时生成分析数据报告。它速度快,线性可扩展,硬件高效,容错,功能丰富,高度可靠,简单易用。ClickHouse核心开发人员在解决问题,合并和维护我们的PR到ClickHouse方面提供了很大的帮助。例如,Cloudflare的工程师在上游贡献了大量代码:

15366371442736.jpg
除了提交许多错误报告外,我们还会报告我们在群集中遇到的每个问题,我们希望将来有助于改进ClickHouse。

尽管ClickHouse上的DNS分析取得了巨大成功,但我们仍然怀疑我们是否能够将ClickHouse扩展到HTTP管道的需求:

在尝试使用Flink失败后,我们对ClickHouse能够跟上高摄取率持怀疑态度。幸运的是,早期的原型显示出了良好的性能,我们决定继续进行旧的管道更换。替换旧管道的第一步是为新的ClickHouse表设计一个模式。

ClickHouse架构设计

一旦我们将ClickHouse确定为潜在候选者,我们就开始探索如何移植现有的Postgres / Citus模式以使它们与ClickHouse兼容。

对于我们的Zone Analytics API,我们需要为每个区域(域)和时间段(每分钟/每小时/每日/每月)生成许多不同的聚合。要深入了解聚合的具体信息,请遵循Zone Analytics API文档或此便捷电子表格

这些聚合应该适用于过去365天的任何时间范围。虽然ClickHouse是一个非常好的工具来处理非聚合数据,但我们的每秒6M请求量,我们只能负担不长时间存储非聚合数据。

为了让您了解这是多少数据,这里有一些“餐巾 - 数学”容量规划。我将使用每秒6M请求的平均插入速率和100美元作为1 TiB的成本估算来计算不同消息格式的1年存储成本:

Metric Cap'n Proto Cap'n Proto (zstd) ClickHouse
消息平均大小/记录大小 1630 B 360 B 36.74 B
存储一年 273.93 PiB 60.5 PiB 18.52 PiB (RF x3)
存储年费用 $28M $6.2M $1.9M

那就是如果我们假设每秒的请求将保持不变,但实际上它一直在快速增长。
尽管存储要求非常可怕,但我们仍在考虑将原始(非聚合)请求日志存储在ClickHouse中1个月+。请参阅下面的“数据API的未来”部分。

非聚合请求表

我们存储超过100列,收集有关通过Cloudflare传递的每个请求的大量不同类型的指标。其中一些列也可在我们的Enterprise Log Share产品中使用,但ClickHouse非聚合请求表包含更多字段。

由于存储了如此多的列和巨大的存储要求,我们决定继续使用聚合数据方法,这种方法在旧流水线之前适用于我们,这将为我们提供向后兼容性。

聚合架构设计#1
根据API文档,我们需要提供许多不同的请求细分并满足这些要求,我们决定测试以下方法:

  1. 使用ReplicatedAggregatingMergeTree引擎创建Cickhouse物化视图,该引擎指向非聚合请求表,并包含每个细分的精确聚合数据:
  1. 使用两种方法编写来自所有8个物化视图的代码收集数据:
  1. 针对常见的Zone Analytics API查询运行性能测试基准
    15366386429471.jpg
    架构设计#1效果不佳。ClickHouse JOIN语法强制编写超过300行SQL的怪异查询,多次重复所选列,因为您只能在ClickHouse中进行成对连接

至于并行分别查询每个物化视图,基准显示了显着但温和的结果 - 查询吞吐量比使用基于Citus的旧管道架构要好一点。

聚合架构设计#2

在模式设计的第二次迭代中,我们努力保持与现有Citus表类似的结构。为此,我们尝试使用SummingMergeTree引擎,该引擎由优秀的ClickHouse文档详细描述:

此外,表可以具有以特殊方式处理的嵌套数据结构。如果嵌套表的名称以“Map”结尾,并且它包含至少两列符合以下条件的列...则此嵌套表将被解释为key =>(values ...)的映射,以及合并时它的行,两个数据集的元素由'key'合并为相应的(值...)的总和。

我们很高兴找到这个功能,因为与我们的初始方法相比,SummingMergeTree引擎允许我们显着减少所需的表数。同时,它允许我们匹配现有Citus表的结构。原因是以'Map'结尾的ClickHouse嵌套结构类似于Postgres hstore数据类型,我们在旧管道中广泛使用它。

但是,ClickHouse地图存在两个问题:

要解决问题#1,我们必须创建一个新的聚合函数sumMap。幸运的是,ClickHouse源代码具有卓越的品质,其核心开发人员非常有助于审查和合并所请求的更改。

对于问题#2,我们必须将uniques放入单独的物化视图中,该视图使用ReplicatedAggregatingMergeTree Engine并支持对具有相同主键的记录合并AggregateFunction状态。我们正在考虑将相同的功能添加到SummingMergeTree中,因此它将进一步简化我们的架构。

我们还为Colo端点创建了一个单独的物化视图,因为它的使用率较低(Colo端点查询为5%,Zone仪表板查询为95%),因此其更分散的主键不会影响Zone仪表板查询的性能。 一旦架构设计可以接受,我们就进行了性能测试。
15366390783063.jpg

ClickHouse性能调整

我们在ClickHouse中探索了许多提高性能的途径。这些包括调整索引粒度,并改善SummingMergeTree引擎的合并性能。

默认情况下,ClickHouse建议使用8192索引粒度。有一篇很好的文章深入解释了ClickHouse主键和索引粒度。

虽然默认索引粒度可能是大多数用例的绝佳选择,但在我们的例子中,我们决定选择以下索引粒度:

与性能无关,但我们还禁用了min_execution_speed设置,因此扫描几行的查询不会返回异常,因为每秒扫描行的速度“慢”。

在聚合/合并方面,我们也进行了一些ClickHouse优化,比如将SummingMergeTree地图的合并速度提高了x7倍,我们将其贡献回ClickHouse以获得每个人的利益。

一旦我们完成了ClickHouse的性能调优,我们就可以将它们整合到一个新的数据管道中。接下来,我们将介绍基于ClickHouse的新数据管道的体系结构。

新数据管道架构

新的管道架构重新使用旧管道中的一些组件,但它取代了其最弱的组件。 新组件包括:
15366519855627.jpg

正如您所看到的,新管道的体系结构更加简单且容错。它为我们所有7M +客户的域提供分析,每月独立访问量超过25亿,每月页面浏览量超过1.5万亿。

平均而言,我们每秒处理6M HTTP请求,峰值高达每秒8M请求。
15366522223289.jpg

Cap'n Proto格式的 平均日志消息大小曾经是~1630B,但由于我们的平台运营团队对Kafka压缩的惊人工作,它显着下降。请参阅“压缩firehose:从Kafka压缩中获取最多”博客文章,深入了解这些优化。

新管道的好处

最近,我们通过更好的硬件进一步提高了新流水线的吞吐量和延迟。我将在下面提供有关此群集的详细信息。

我们的ClickHouse集群

我们总共有36个ClickHouse节点,我们做过一次新硬件大升级。

我们的平台运营团队注意到,ClickHouse还不能很好地运行异构集群,因此我们需要逐步用新硬件替换现有集群中的所有节点,全部36个。这个过程非常简单,与替换失败的节点没什么不同。问题是ClickHouse没有限制恢复

以下是有关我们群集的更多信息:

历史数据传输
由于我们有1年的存储要求,我们不得不从旧的Citus集群到ClickHouse进行一次性ETL(提取转移负载)。

在Cloudflare,我们喜欢Go及其goroutines,因此编写一个简单的ETL工作非常简单,其中:

整个过程耗时数天,成功传输了超过60亿行数据,并进行了一致性检查。这个过程的完成最终导致了旧管道的关闭。但是,我们的工作并没有就此结束,我们不断展望未来。在下一节中,我将分享一些有关我们计划的细节。

数据API的未来

日志推送

我们目前正在研究一种名为“Log Push”的东西。日志推送允许您指定所需的数据端点,并定期自动发送HTTP请求日志。目前,它处于私人测试状态,并支持将日志发送到:

预计很快就会推出,但如果您对这款新产品感兴趣并希望试用,请联系我们的客户支持团队。

记录SQL API

我们还在评估构建名为Logs SQL API的新产品的可能性。我们的想法是通过灵活的API为客户提供对日志的访问,该API支持标准SQL语法和JSON / CSV / TSV / XML格式响应。

查询可以提取:

Google BigQuery提供类似的SQL API,亚马逊也提供产品调用Kinesis数据分析,并支持SQL API。

我们正在探索的另一个选项是提供类似于带有过滤器和维度的DNS Analytics API的语法。

我们很高兴听到您的反馈并了解有关您的分析用例的更多信息。它可以帮助我们构建新产品!

原文:http://suo.im/4wkLf8

WeZan
Responses