没有合适的资源?快使用搜索试试~ 我知道了~
首页使用ClickHouse对每秒6百万次请求进行HTTP分析.pdf
使用ClickHouse对每秒6百万次请求进行HTTP分析.pdf
需积分: 50 750 浏览量
更新于2023-05-26
评论 1
收藏 2.82MB PDF 举报
Clickhouse是一个用于联机分析处理(OLAP)的列式数据库管理系统(columnar DBMS)。 传统数据库在数据大小比较小,索引大小适合内存,数据缓存命中率足够高的情形下能正常提供服务。但残酷的是,这种理想情形最终会随着业务的增长走到尽头,查询会变得越来越慢。你可能通过增加更多的内存,订购更快的磁盘等等来解决问题(纵向扩展),但这只是拖延解决本质问题。如果你的需求是解决怎样快速查询出结果,那么ClickHouse也许可以解决你的问题。
资源详情
资源评论
资源推荐

使用ClickHouse对每秒6百万次请求进行HTTP
分析
http://fashengba.com/post/http-analytics-for-6m-requests-per-second-using-clickhouse.html
PublishedonSep14,2018in互联网技术with0comment访问:2,523次
译文ClickHouse
我们在Cloudflare的一个大规模数据基础架构挑战是为我们的客户提供HTTP流量分析。我
们所有客户都可以通过两种方式使用HTTP分析:
在这篇博文中,我将谈谈去年Cloudflare分析管道的令人兴奋的演变。我将首先介绍旧管道
以及我们遇到的挑战。然后,我将描述我们如何利用ClickHouse构建新的和改进的管道的
基础。在此过程中,我将分享有关我们如何进行ClickHouse的架构设计和性能调整的详细
信息。最后,我期待数据团队将来考虑提供什么。
让我们从旧数据管道开始。
老数据管道架构
之前的管道建于2014年。之前已经在使用CitusDB和更多数据扩展PostgreSQLfor
CloudFlareAnalytics,以及来自Data团队的更多数据博客文章中提到过。它有以下组
件:
日志转发器:从边缘收集Cap'nProto格式化日志,特别是DNS和Nginx日志,
并将它们发送到Cloudflare中央数据中心的Kafka。
Kafka集群:由106个具有x3复制因子的代理组成,106个分区,以平均每秒
6M日志的速度摄取Cap'nProto格式化日志。
Kafka消费者:106个分区中的每个分区都有专门的Go消费者(又名Zoneagg
消费者),每个区域每分钟读取日志并生成聚合,然后将它们写入Postgres。
Postgres数据库:单实例PostgreSQL数据库(又名RollupDB),接受来自
Zoneagg使用者的聚合,并按分区每分钟将它们写入临时表。然后,它使用聚合
cron将聚合汇总到更多聚合中。进一步来说:
每个分区,分钟,区域的聚合→每分钟聚合数据,区域
每分钟聚合,区域→每小时聚合数据,区域

每小时聚合,区域→每天聚合数据,区域
每天聚合,区域→每月聚合数据,区域
CitusCluster:由Citusmaster和11位Citus工作者组成,具有x2复制因子(又
名ZoneaggCitus集群),ZoneAnalyticsAPI背后的存储以及我们的BI内部工具。
它有复制cron,它将表格从Postgres实例远程复制到Citus工作分片。
ZoneAnalyticsAPI:来自内部PHPAPI的服务查询。它由5个用Go和查询的
Citus集群编写的API实例组成,对外部用户不可见。
PHPAPI:3个代理API实例,它将公共API查询转发到内部ZoneAnalytics
API,并在区域计划,错误消息等方面具有一些业务逻辑。
LoadBalancer:nginx代理,将查询转发到PHPAPI/ZoneAnalyticsAPI。
自从该管道最初于2014年设计以来,Cloudflare已经大幅增长。它开始以每秒1M的请求处
理,并且发展到当前每秒6M请求的水平。多年来,管道为我们和我们的客户提供了很好的
服务,但在接缝处开始分裂。在需求发生变化时,应在一段时间后重新设计任何系统。
原始管道的一些具体缺点是:
PostgresSPOF:单个PostgreSQL实例是一个SPOF(单点故障),因为它没
有副本或备份,如果我们丢失了这个节点,整个分析管道可能会瘫痪并且不会为
ZoneAnalyticsAPI产生新的聚合。
CitusmasterSPOF:Citusmaster是所有ZoneAnalyticsAPI查询的入口点,
如果它发生故障,我们所有客户的AnalyticsAPI查询都会返回错误。
复杂的代码库:用于聚合的数千行bash和SQL,以及数千行Go和API和Kafka消
费者使得管道难以维护和调试。
许多依赖项:由许多组件组成的管道,以及任何单个组件中的故障都可能导致整
个管道停止。
高昂的维护成本:由于其复杂的架构和代码库,经常发生事故,有时需要数据团
队和其他团队的工程师花费数小时来缓解。
随着时间的推移,随着我们的请求数量的增长,操作此管道的挑战变得更加明显,我们意识
到这个系统正在被推到极限。这种认识激发了我们思考哪些组件将成为替代的理想候选者,
并促使我们构建新的数据管道。
我们的第一个改进分析管道设计以使用ApacheFlink流处理系统为中心。我们以前曾使用
Flink作为其他数据管道,所以对我们来说这是一个很自然的选择。但是,这些管道的速度
远远低于我们需要为HTTPAnalytics处理的每秒6M请求,并且我们很难让Flink扩展到此卷
-它无法跟上每个分区的摄取率每秒所有6MHTTP请求。
我们的DNS团队的同事已经在ClickHouse上构建并生成了DNS分析管道。他们在
Cloudflare如何分析每秒1MDNS查询博客文章中写到了这一点。所以,我们决定深入研究
一下ClickHouse。

ClickHouse
“ClickHouseнетормозит。”
来自俄语的翻译:ClickHouse没有刹车(或者不慢)
©ClickHouse核心开发者
在探索替换旧管道的一些关键基础架构的其他候选者时,我们意识到使用面向列的数据库可
能非常适合我们的分析工作负载。我们希望确定一个面向列的数据库,该数据库具有水平可
扩展性和容错性,可以帮助我们提供良好的正常运行时间保证,并且具有极高的性能和空间
效率,从而可以处理我们的规模。我们很快意识到ClickHouse可以满足这些标准,然后是
一些标准。
ClickHouse是一个面向开源列的数据库管理系统,能够使用SQL查询实时生成分析数据报
告。它速度快,线性可扩展,硬件高效,容错,功能丰富,高度可靠,简单易用。
ClickHouse核心开发人员在解决问题,合并和维护我们的PR到ClickHouse方面提供了很大
的帮助。例如,Cloudflare的工程师在上游贡献了大量代码:
MarekVavruša的聚合函数topK
MarekVavruša的IP前缀字典
MarekVavruša对SummingMergeTree引擎进行了优化
KafkaMarekVavruša表引擎。我们想用这个引擎取代KafkaGo的消费者,因
为它足够稳定,可以直接从Kafka摄取到ClickHouse。
聚合函数sumMap由AlexBocharov。如果没有此功能,则无法构建新的Zone
AnalyticsAPI。
由AlexBocharov标记缓存修复
uniqHLL12功能修复AlexBocharov的大基数。问题的描述及其修复应该是一
个有趣的阅读。
剩余11页未读,继续阅读













安全验证
文档复制为VIP权益,开通VIP直接复制

评论0