导读：实时或者准实时的海量数据分析对于很多应用来说都是很难做到的，一方面是数据量太大，另一方面是分析条件多变。本文是Cloudflare在处理DNS查询分析的时候，作出的技术选型和踩过的坑。
上周五，我们宣布了所有Cloudflare DNS分析工具。 由于我们的规模很大（当你读完这篇文章的时候，Cloudflare DNS将处理数以百万计的DNS查询） 我们必须非常有创意的解决该问题。 在本文中，我们将介绍DNS分析工具的组件，这些组件帮助我们每月处理数以万亿计的日志。
Cloudflare已经有一个用于HTTP日志的数据管道。我们希望DNS分析工具可以利用该功能。每当边缘服务处理一个HTTP请求时，它就会以Cap'n Proto格式生成一个结构化的日志消息，并将其发送到本地多路复用服务。考虑到数据量，我们只记录部分DNS消息数据，只包含我们感兴趣的数据，例如响应码，大小或query name，这使得我们每个消息平均只保留约150字节数据。然后将其与元数据处理（例如在查询处理期间触发的定时信息和异常）融合。在边缘融合数据和元数据的好处是，我们可以将计算成本分散到成千上万的边缘服务器，并且只记录我们需要的信息。
拥有结构化日志队列使我们能够追溯性地查问题，而不需要访问生产节点。 在项目的早期阶段，我们会跳过队列并找到我们所需的粗略时间段的偏移量，然后将数据以Parquet格式提取到HDFS中，以供离线分析。
关于聚合
HTTP分析服务是围绕生成聚合的流处理器构建的，因此我们计划利用Apache Spark将日志自动传输到HDFS。由于Parquet本身不支持索引以避免全表扫描，因此在线分析或通过API提供报告是不切实际的。虽然有像parquet-index这样的扩展可以在数据上创建索引，但也不能实时运行。鉴于此，最初的设计是仅向客户显示汇总报告，并保留原始数据用以内部故障排除。
由于这些原因，我们首先在zone层次上汇总日志，这对于趋势分析来说已经足够，但是对于具体原因分析来说则太过粗糙。例如，我们正在调查其中一个数据中心的流量短暂爆发。具有未聚合的数据使我们能够将问题缩小到特定DNS查询，然后将查询与错误配置的防火墙规则相关联。像这样的情况下，只有汇总日志就有问题，因为它只聚合一小部分请求。
ClickHouse
ClickHouse的系统设计更加简单，集群中的所有节点具有相同的功能，使用ZooKeeper进行协调。我们建立了一个由几个节点组成的集群，发现性能相当可观，所以我们继续构建了一个概念验证。我们遇到的第一个障碍是缺少工具和社区规模的规模太小，所以我们钻研了ClickHouse设计，以了解它是如何工作的。
基础设施和数据整合
我们使用12个6TB磁盘做RAID-10，但在一次磁盘故障之后重新进行了评估。在第二次迭代中，我们迁移到了RAID-0，原因有两个。首先，不能热插拔有故障的磁盘，其次阵列重建花费了数十个小时，这降低了I/O性能。更换故障节点并使用内部复制通过网络（2x10GbE）填充数据比等待阵列完成重建要快得多。为了弥补节点故障的可能性较高，我们切换到3路复制，并将每个分片的副本分配到不同的机架，并开始规划复制到单独的数据仓库。
数据可视化
当时我们只依靠Pandas和ClickHouse的HTTP接口进行临时分析，但是我们希望使分析和监控更容易。 因为我们知道Caravel（现在更名为Superset ），我们就把它和ClickHouse进行了整合。
Superset是一个直观的数据可视化平台，它允许分析人员在不写一行SQL的情况下交互地切片和切分数据。 它最初是由AirBnB为Druid构建和开源的，但是随着时间的推移，它已经通过使用SQLAlchemy（一种抽象和ORM）为数十种不同的数据库方言提供了基于SQL的后端的支持。 所以我们编写并开源了一个ClickHouse方言，并集成到Superset。
它使我们能够用新的分析数据无缝地扩展我们现有的监测仪表板。 我们非常喜欢这个功能，因此我们希望能够为用户提供同样的能力来查看分析数据。 因此，我们构建了一个Grafana应用程序，以便可视化来自Cloudflare DNS Analytics的数据。 最后，我们在您的Cloudflare仪表板分析中提供了它。 随着时间的推移，我们将添加新的数据源，维度和其他有用的方法来显示Cloudflare中的数据。
推荐阅读
高可用架构
改变互联网的构建方式
长按二维码 关注「高可用架构」公众号
5509
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
