pb 单击事件(pb杠a是哪个事件)

关于显示IP属地的背后，涉及到哪些利益？又揭露了哪些不为人知的秘密？“显示IP属地”的话题在公众舆论中引起广泛关注，无疑是对一些现象的深入揭示和讨论。对此，我想谈谈我们的Uber日志分析平台的转型故事。这是一个致力于处理大规模数据、为工程师提供快速可靠日志分析的平台。它不仅为我们的产品改进提供了有力的数据支持，更是一个展示如何应对挑战、实现技术革新的实例。以下是我们的经历和挑战：在Uber，我们一直在努力构建一个集中化、可靠且交互式的日志分析平台。这个平台不仅能帮助工程师们快速完成大规模日志分析，而且让数据呈现出异常或有趣的模式，为产品改进提供宝贵的数据支撑。近几年随着业务的飞速发展，我们的日志流量呈指数级增长，原有的ELK平台已无法满足日益增长的需求。面对这一挑战，我们决定深入研究并构建下一代日志分析平台。在这个过程中，我们遇到了四大挑战：首先是日志模式的挑战。我们的日志是半结构化的，这使得自动推导模式变得复杂。不同的工程师可能会使用相同的字段名但赋予不同的数据类型，导致Elasticsearch出现类型冲突错误。这不仅降低了开发人员的生产力，也增加了维护成本。理想情况下，平台应该能够处理多种类型的字段并自动管理日志模式的变化。接下来是运营成本问题。大量的查询和映射爆炸对集群性能造成严重影响，导致我们必须运行多个Elasticsearch集群以限制其影响。这不仅增加了硬件成本，也增加了运营难度和人工干预的频率。再者是硬件成本问题。索引字段的成本很高，需要大量的处理能力来维持索引的正常运行，这使得扩展成本高昂。聚合查询的低效问题影响了用户体验。我们发现大部分的查询都是聚合查询，而Elasticsearch在跨大规模数据集进行快速聚合方面的表现并不理想，导致关键仪表盘的加载速度缓慢甚至超时。为了解决上述问题并实现我们的目标——收集Uber内部的所有日志以较低的平台成本进行存储和服务，并确保用户和运营商的愉快体验——我们决定开发一种新的日志分析平台。这个平台旨在解决现有平台的所有问题并实现技术革新。它将具有更高的可靠性、可扩展性和性能，同时降低运营成本和硬件成本。未来我们将继续优化和完善这个平台以满足日益增长的业务需求并推动产品的发展和创新。“显示IP属地”的背后涉及到的是技术进步、用户体验和运营效率等多方面的利益和挑战。“显示IP属地”只是冰山一角它让我们看到了技术革新的必要性和潜力同时也提醒我们在面对挑战时要保持开放和透明的沟通以实现更好的产品和服务体验。我们设计了一款全新的日志分析平台，充分考虑到了一系列关键需求，包括提升开发人员的工作效率、保持模式无关性、高效支持聚合查询、多区域和跨租户查询、保证查询效率与维护的便捷性，以及支持多租户整合部署等。我们的目标是在降低成本的处理规模达十倍的问题，提高系统的可靠性，并简化操作，实现从ELK平台的无缝迁移，让用户可以继续使用Kibana进行交互式的日志分析。

在深入研究多种日志产品和存储解决方案后，我们决定采用开源的分布式面向列的DBMSClickHouse作为底层日志存储技术，并在其之上构建了一个抽象层，以支持模式无关的数据模型。

模式无关的数据模型

我们的原始日志被结构化地存储为JSON格式，且其模式可以灵活变化。在发布日志消息时，开发人员可以使用键值对来标记它们，以提供丰富的上下文。这些日志消息和标签在输出日志中被编码为字段。这些字段可以是原始类型，如数字和字符串，也可以是复杂类型，如数组或对象。对于像Uber这样的公司，日志平均包含40多个字段，我们的平台能够一视同仁地处理这些字段，提供全面的上下文信息。

为了支持模式的原生演化，我们在摄取过程中跟踪了日志模式中所有字段的类型。这种模式被持久化，并在查询执行过程中使用。每种字段类型都带有一个时间戳标记，表示该类型被观察到的时刻，可以用来清除模式中的过时信息。

ClickHouse表模式

在初期阶段，我们尝试了两种表模式来保存ClickHouse中的日志。第一种模式只将json格式的原始日志保存在_source列中。查询时需要通过ClickHouse的json解组函数来访问日志字段，但这种方式由于json解组的开销导致查询速度较慢。

第二种模式不仅保留了原始日志以便快速检索，而且将所有字段扁平化到专门的列中，并注明字段名和类型以解决类型冲突。这样可以直接从列中查询字段值，查询速度比第一种模式快50倍。这种模式也存在扩展性问题：随着表列数的增加，磁盘文件的数量线性增长，导致ClickHouse对写和读的响应降低，后台合并任务负担过重。

为了解决这些问题，我们设计了一种新的表模式（为简洁起见已作简化）。这种表模式提供良好的查询性能，避免了无限增长的磁盘文件数量。基本上，每条日志都被扁平化为一组键值对，按值类型分组，如Strg、Number或StrgArray。在表中，我们使用数组来存储这些键值对。为了更快地检索，常用的元数据字段都保存在专门的列中。特别是_namespace列，使我们能够有效地支持多租户。值得注意的是，我们始终保存原始日志在_source列中，以避免在运行时重新生成全部日志，这对嵌套结构来说是复杂且成本高昂的。尽管我们只存储了两次日志，但由于有效的压缩技术，使用磁盘的次数并没有显著增加。在实际流量测试中，采用这种表模式的压缩比高达3倍（在某些情况下可达30倍），与Elasticsearch相当甚至更佳。

在查询过程中，我们利用ClickHouse的数组函数来访问字段值。虽然从数组列中提取字段值的速度比从专用列慢，但由于大多数过滤器都是基于字段进行评估的，我们建议在频繁访问的字段上使用ClickHouse的物化列功能来加速查询，即自适应地索引字段。

这种表模式不仅提高了查询性能与灵活性，而且优化了日志摄取的效率。实验表明，一个ClickHouse节点每秒可以摄取300K日志，是Elasticsearch节点的十倍。在现代数据处理领域，快速摄取并查询日志数据至关重要。我们的解决方案旨在消除模式限制，实现日志数据的无模式摄取和高效查询。

一、无模式摄取

日志对于故障调试至关重要，我们致力于打造一个快速、完整的日志分析平台。我们的日志摄取流程由两大组件构成：摄取器和批处理器。摄取器从Kafka中吸取日志，将JSON格式的日志扁平化为键值对，并通过m3msg发送到下游。这个过程保证了日志数据至少被提交一次。当下游处理速度降低时，利用Kafka的缓冲机制，实现背压，确保系统的稳定性。

我们选择了ClickHouse作为数据存储引擎，因为它在大批量写入时表现出最佳性能。为了确保摄取延迟最小化，我们将多个租户的日志适当打包到表中。在摄取过程中，日志模式会从当前的批处理中提取并持久化到元数据中。这意味着我们的平台可以适应日志模式的演化，即使出现错误更新模式，我们也能继续摄取数据。这种设计使得我们的平台对映射爆炸问题具有强大的免疫力。

二、类型识别查询

为了让用户轻松检索日志数据，我们提供了一组高级查询接口。这些接口包括RawQuery、AggregationQuery和BucketQuery等。它们提供了一种简洁的方式来过滤、分组和计算日志数据。所有查询都可以从一个命名空间列表（即租户）的日志中进行。

三、SQL生成与查询服务

我们的查询服务负责从请求生成ClickHouse SQL。这个过程分为逻辑阶段和物理阶段。在逻辑阶段，服务会根据查询请求收集字段类型约束，并与日志模式中的字段类型进行比较，确定字段的实际类型。当需要从字段中访问多种类型的值时，可能需要进行类型转换。我们遵循一定的规则进行转换，以确保SQL表达式的正确性。

我们的解决方案具有显著的优势。通过无模式摄取，我们消除了对日志模式的依赖，使得数据摄取更加快速和完整。通过高级查询接口和自动生成SQL的查询服务，我们为用户提供了一个熟悉而愉快的使用体验。我们的平台具有很强的适应性，可以应对日志模式的演化以及映射爆炸问题。

我们的目标是构建一个高效、灵活的日志分析平台，为用户提供快速摄取和查询日志数据的能力。通过无模式摄取、高级查询接口和自动生成SQL的查询服务，我们为用户带来了便捷的数据分析体验。本文将介绍基于 ELK 平台的日志处理新方案，解决类型冲突问题并优化查询效率。

在 ELK 平台中，类型冲突问题曾是困扰开发者的一大难题。但在新的日志平台中，我们将这一问题规范化处理。当字段类型确定后，逻辑阶段的结束将伴随表列访问表达式的生成。例如，对于“bar”字段，我们获得的 SQL 表达式能清晰地展示如何访问其值。

在物理阶段，查询请求中的各类表达式被转化为最终 SQL。在这一阶段结束时，将决定查询设置，控制 ClickHouse 执行查询的方式。我们的平台将字段类型的解析延迟到查询阶段，这大大简化了摄取逻辑，提高了数据完整性。由于写路径的错误预算相对查询路径要少，我们能更快地迭代查询服务，甚至在检索日志时进行复杂转换。

我们引入了自适应索引机制。通过对生产查询的分析，我们发现只有少部分索引字段被使用，这意味着大量索引成本被浪费。我们的平台设计旨在摄取所有日志，同时避免预先支付不必要的索引成本。我们选择性地对查询频率高的字段进行索引，并为其创建物化列。ClickHouse 会在后台异步地将字段值回填到这些物化列，同时不影响正在进行的读写操作。当查询物化列时，可以使用预填充值功能，提高查询效率。

在架构设计上，我们注重可靠性、可扩展性、多区域和多租户的应用。为了增强系统的可靠性，我们采用了 ClickHouse 的 ReplicatedMergeTable 引擎，并设置 RF=2 以提高冗余性。复制是异步的，日志可以写到任何可用的副本中，查询也可以访问任何副本的日志。这增强了系统的可用性，即使节点临时丢失也不会影响数据持久性。为了扩展系统，我们使用了 ClickHouse 的表分片支持功能，使得整个 ClickHouse 集群的表都可以进行分片。我们增强了 ClickHouse 的集群管理支持功能，提供了一个状态驱动的集群管理框架。通过这个框架，我们可以自动执行各种操作，如登录租户、扩展集群、替换节点等。

为了方便对所有分片的日志进行查询，我们使用了分布式表功能。分布式表不存储物理数据，但能对集群的所有分片进行扇形查询并正确汇总结果。为了应对跨区域的数百个节点，我们将节点分为查询和数据两种角色。只有查询节点需要集群拓扑信息来为分布式查询提供服务，这降低了信息传播的复杂性。角色分离使得查询节点和数据节点可以独立扩展，查询节点几乎无状态，易于扩展。

我们的日志处理新方案通过规范化处理类型冲突问题、引入自适应索引机制以及优化架构设计，提高了系统的可靠性、可扩展性和查询效率。通过增设更多的CH节点，我们的集群架构得以线性扩展，以更好地适应不断增长的需求。为了确保多租户环境的安全与稳定，我们在日志摄取和查询过程中实施了严格的隔离措施。针对摄取器，我们为每个租户设定了明确的速率限制。而在查询服务层面，我们则控制了每个租户的最大访问次数，并为每个查询合理分配资源，如查询线程，以确保并行查询和访问负载得到妥善处理。

成本与性能考量

与ELK技术相比，我们的新一代日志服务在应对更多生产流量时，硬件成本降低了超过一半。在运营开销方面，我们实现了统一的日志摄取管道，所有常用操作均通过管理服务自动完成，极大地简化了运维工作。我们的平台不受类型冲突错误的影响，这一错误在过去是主要的运维挑战之一。

在性能方面，我们的服务实现了极低的吸收延迟，上限为1分钟。跨多个区域的日志查询、检索和汇总通常在几秒内完成，尤其是当查询窗口小于一天时。ClickHouse的内存缓存机制使得随后的查询（如从刷新仪表盘中进行的查询）更加迅速。由于ClickHouse提供了适当的资源隔离支持，我们的平台能够在高查询负载下依然保持性能稳定。

ELK的透明迁移策略

除了直接调用ES端点检索日志的服务外，Uber工程师每月还会保存约1000个Kibana仪表盘以进行日志分析。为实现透明的迁移过程，我们构建了QueryBridge服务，无需客户端修改指示盘或代码，即可将ES查询转换为新的查询接口，并返回响应。通过对查询结果进行验证，我们逐步迁移用户，确保平滑过渡。

我们的目标不是支持完整的ES查询语法，而是聚焦在产品中实际使用的语法。尽管如此，转换逻辑相当复杂。例如，Lucene查询可以通过query_strg操作符嵌入ES查询中。我们将这些查询转换为代表整个ES查询的AST（抽象语法树）的子树。聚合查询中的过滤条件，如过滤器聚合，被转化为查询请求中的特定筛选器的计算。对于ES内部的特殊字段，如@timestamp和_source，需要单独处理，因为它们不是日志主体数据的一部分。我们必须对关键字和文本字段的过滤器进行特定的转换操作。

未来展望

日志数据的高分辨率洞察力对于理解生产环境至关重要，尤其是当数据被标记为请求ID、地理位置或IP地址等高基数字段时。近实时地分析这些日志数据可以高效地调试联机系统，识别有趣的模式，从而提高产品质量。基于当前的用户反馈，我们相信这一平台能够满足Uber广泛的日志分析需求，ClickHouse的分析引擎展现了强大的潜力。

展望未来，我们计划在以下几个领域继续深耕：改善查询服务的SQL查询支持，通过精细调整索引粒度、探索跳过索引以及根据收集的统计数据微调查询设置来减少查询延迟的差异性；探索分层存储，以提高数据保留率并降低成本；以及构建下一代UI/UX，取代Kibana，更好地与后台整合，使日志的发现和分析更加便捷，通过交叉检查日志、指标和痕迹，方便事件调查。

如果你对加入Uber的可靠性平台团队、打造下一代可观测性体验感兴趣，我们诚挚地欢迎你加入我们的团队！

关于作者：Chao Wang作为Uber的软件工程师，在可观测性领域拥有5年的经验，目前负责领导团队构建新一代的日志基础设施。Xiaobg Li是Uber日志团队的前软件工程师，他领导的日志查询服务项目重点在于从ELK的透明迁移。想了解更多关于日志技术的细节和团队的工作内容，请访问我们的原文链接：[