在Cloudflare，我们的大型数据基础架构挑战之一是为客户提供HTTP流量分析。HTTP分析可通过两个选项提供给我们的所有客户：Cloudflare仪表板中的"分析"选项卡带2个终结点的区域分析API仪表板终结点同一地点端点（仅限企业计划）在这篇博客文章中，我将讨论Cloudflare analytics管道在过去一年中令人兴奋的发展。我将首先描述旧管道以及我们在使用它时遇到的挑战。然后，我将描述我们如何利用ClickHouse来构建一个新的和改进的管道的基础。在此过程中，我将详细介绍我们如何为ClickHouse进行模式设计和性能调整。最后，我将期待数据团队在未来提供什么。让我们从旧的数据管道开始。旧数据管道上一条管道建于2014年。以前在使用citudb扩展PostgreSQL for CloudFlare Analytics中已经提到过这个问题，更多数据来自数据团队的blog帖子。它有以下组成部分：日志转发器-从边缘收集Cap'n Proto格式的日志，特别是DNS和Nginx日志，并将它们发送到Cloudflare中央数据中心的Kafka。Kafka集群-由106个代理组成，具有x3复制因子，106个分区，以平均每秒6百万个日志的速度摄取Cap'n原型格式的日志。Kafka消费者——106个分区中的每个分区都有专门的Go消费者（又称Zoneagg consumer），它每分钟读取日志并为每个分区生成聚合，然后将其写入Postgres。Postgres数据库-单实例PostgreSQL数据库（又称RollupDB），接受来自Zoneagg使用者的聚合，并每分钟将其写入每个分区的临时表中。然后，它使用aggregation cron将聚合聚合聚合成进一步的聚合。更具体地说：聚合每个分区，分钟，区域→聚合每分钟的数据，区域每分钟聚合，区域→每小时聚合数据，区域每小时聚合，区域→每天聚合数据，区域每天聚合，区域→每月聚合数据，区域Citus Cluster-由Citus main和11个Citus worker组成，具有x2复制因子（又称Zoneagg Citus Cluster）、存储在区域分析API和我们的BI内部工具。它有replication cron，它将表从Postgres实例远程复制到Citus worker shard。区域分析API-来自内部PHP API的服务查询。它由5个在Go和查询Citus集群中编写的API实例组成，外部用户看不到。PHPAPI-代理API的3个实例，它将公共API查询转发到内部区域分析API，并具有关于区域计划、错误消息等的一些业务逻辑。负载平衡器-nginx代理，将查询转发到PHP API/Zone Analytics API。自2014年开始设计这条管道以来，Cloudflare的发展非常迅速。它开始时每秒处理的请求数不到100万个，现在已发展到每秒6百万个请求的水平。这些年来，这条输油管道为我们和我们的客户提供了很好的服务，但开始出现裂痕。当需求发生变化时，任何系统都应该在一段时间后重新设计。原始管道的一些具体缺点是：PostgresSPOF-单个PostgreSQL实例是一个SPOF（单点故障），因为它没有副本或备份，如果我们失去这个节点，整个分析管道可能会瘫痪，并且不会为区域分析API生成新的聚合。Citus main SPOF-Citus main是所有Zone Analytics API查询的入口点，如果发生故障，我们所有客户的Analytics API查询都将返回错误。复杂的代码库—数千行用于聚合的bash和SQL，以及数千行Go for API和Kafka用户，使得管道难以维护和调试。许多依赖关系-管道由许多组件组成，任何单个组件的故障都可能导致整个管道停止。高维护成本-由于其复杂的体系结构和代码库，经常发生事故，有时需要数据团队和其他团队的工程师花费数小时来缓解。随着时间的推移，随着我们的请求量的增长，运营这条管道的挑战变得越来越明显，我们意识到这个系统正被推向极限。这种认识启发了我们思考哪些组件是理想的替代品，并引导我们构建了新的数据管道。我们的第一个改进的分析管道的设计围绕着Apache Flink流处理系统的使用。我们以前在其他数据管道中使用了Flink，所以它是我们的自然选择。然而，这些管道的速度远远低于我们处理HTTP分析所需的每秒6百万个请求的速率，我们努力让Flink扩展到这个数量—它只是无法跟上每秒所有6百万个HTTP请求的每个分区的接收速率。我们DNS团队的同事已经在ClickHouse上建立并生产了电离DNS分析管道。他们在"Cloudflare如何分析每秒1M个DNS查询"的博客文章中对此进行了描述。所以，我们决定深入研究一下ClickHouse。ClickHouse公司"单击房子"俄语翻译：ClickHouse没有刹车（或者不慢）©ClickHouse核心开发者在探索替代旧管道的一些关键基础设施的其他候选方案时，我们意识到使用面向列的数据库可能非常适合我们的分析工作负载。我们想确定一个面向列的数据库，它具有水平可伸缩性和容错性，以帮助我们提供良好的正常运行时间保证，并且具有极高的性能和空间效率，以便它能够处理我们的规模。我们很快意识到ClickHouse可以满足这些标准，然后一些。ClickHouse是一个开源的面向列的数据库管理系统，能够使用SQL查询实时生成分析数据报表。它具有速度快、线性可扩展、硬件高效、容错、功能丰富、可靠性高、简单方便等特点。ClickHouse核心开发者在解决问题、合并和维护pr到ClickHouse中提供了很大的帮助。例如，Cloudflare的工程师在上游贡献了大量代码：Marek Vavruša的聚合函数topKMarek Vavruša编写的IP前缀词典Marek Vavruša总结MergeTree引擎优化卡夫卡表引擎由马雷克瓦夫鲁沙。我们正在考虑用这个引擎取代卡夫卡的消费者，当它足够稳定，并从卡夫卡直接摄取到点击屋。聚合函数sumMap作者：Alex Bocharov。没有这个功能，就不可能建立我们的新区域分析API。Alex Bocharov的标记缓存修复uniqHLL12函数修复大基数由alexbocharov。对这个问题的描述及其解决办法应该是一本有趣的读物。除了提交许多bug报告外，我们还报告了集群中遇到的每一个问题，我们希望这将有助于将来改进ClickHouse。尽管对ClickHouse的DNS分析取得了巨大成功，但我们仍然怀疑是否能够将ClickHouse扩展到HTTP管道的需要：Kafka DNS主题平均每秒有150万条消息，而HTTP请求主题的平均每秒消息数为6百万条。Kafka DNS主题的平均未压缩消息大小为130B，而HTTP请求主题的平均未压缩消息大小为1630B。DNS查询ClickHouse记录由40列组成，而HTTP请求ClickHouse记录则由104列组成。在Flink的尝试失败后，我们对ClickHouse能否跟上高摄取率持怀疑态度。幸运的是，早期的原型显示出了很好的性能，我们决定继续替换旧的管道。替换旧管道的第一步是为新的ClickHouse表设计一个模式。ClickHouse模式设计一旦我们确定ClickHouse是一个潜在的候选方案，我们就开始探索如何将现有的Postgres/Citus模式移植到ClickHouse中。对于我们的区域分析API，我们需要为每个区域（域）和时间段（分钟/小时/每日/每月）生成许多不同的聚合。要深入了解聚合的细节，请遵循Zone Analytics API文档或此便利的电子表格。这些聚合应在过去365天的任何时间范围内可用。虽然ClickHouse是处理非聚合数据的一个非常好的工具，但是我们每秒有600万个请求，我们实在无法承受如此长的时间来存储非聚合数据。为了让你知道有多少数据，这里有一些"餐巾纸数学"的容量规划。我将使用每秒600万个请求的平均插入率和100美元的成本估算值1 TiB来计算不同消息格式下1年的存储成本：公制原船长Cap'n原型（zstd）ClickHouse公司平均消息/记录大小1630年B360磅36.74亿1年储存要求273.93卢比60.5像素18.52像素（射频x3）1年储存成本2800万美元620万美元190万美元如果我们假设每秒的请求保持不变，但实际上它一直在快速增长。尽管存储需求相当可怕，但我们仍在考虑将原始（非聚合）请求日志存储在ClickHouse中1个月以上。请参阅下面的"数据API的未来"一节。非聚合请求表我们存储了100多个列，收集了关于通过Cloudflare传递的每个请求的大量不同类型的度量。我们的企业日志共享产品中也提供了其中一些列，但是ClickHouse非聚合请求表有更多字段。由于要存储的列太多，存储需求巨大，我们决定继续使用聚合数据方法，这种方法以前在旧的管道中对我们很有效，它将为我们提供向后兼容性。聚合模式设计1A