数据遥测是记录和发送系统、应用程序和服务中行为信号和真实世界事件到中央分析平台的过程。它分为产品、基础设施、运营和安全遥测。数据遥测是产品智能、个性化、异常检测和运营效率的关键驱动力，并为人工智能驱动的分析奠定了基础。
译自：Data Telemetry Is the Lifeline of Modern Analytics and AI
作者：Tapan Manaktala, Ashok Singamaneni
想象一下打开你喜欢的购物应用程序购买一双新运动鞋。在几秒钟内，你搜索、点击几个款式、把你最喜欢的一双加入购物车并完成购买。这一切似乎都很自然，与我们日常生活中进行的各种购物非常相似。
然而，在你流畅的体验背后，成千上万个无形的信号正在触发，每一次点击、滚动和购买都被记录为一个事件，记录着你的旅程。
这个无形的神经系统被称为“数据遥测”。
简单来说，它是将系统、应用程序和服务中的行为信号和真实世界事件记录并发送到中央分析平台的过程。它记录着你的产品中发生的每一个动作，从用户观看视频到服务处理付款，并将这些数据几乎即时地发送到你的数据系统中。
如果说中心化数据是产品的引擎，那么遥测就是燃油管。没有它，即使是最复杂的分析基础设施也会耗尽。它使团队能够衡量性能、在用户发现之前检测故障、了解用户旅程并进行持续的实验，从而驱动整个组织的学习循环。
数据遥测有多种形式
- 产品遥测 通过记录每一次滚动、点击和购买来监控用户与产品的交互，以识别购买趋势并增强客户体验。这使得转化率、漏斗流失率和实验成功率等指标成为可能。
- 基础设施遥测 跟踪作业失败、空闲计算实例和延迟峰值，以监控系统健康状况和资源效率。它对于过载保护、成本优化和异常检测等用例至关重要。
- 运营和安全遥测 观察访问模式、合规性和应用程序的可靠性。这在大规模云系统中尤为重要，尤其是在医疗保健和金融科技行业。
产品数据遥测实战
让我们以一个真实世界的例子来更详细地探讨产品数据遥测，以演示它是如何直接为产品智能做出贡献的，从而使团队能够通过从实际使用模式中获得洞察来创造更好的产品并提供卓越的用户体验。
你还记得几周前在亚马逊上看中的那双运动鞋吗？让我们回顾一下购买体验，因为这是观察产品遥测实战的理想场景。
从你开始寻找一双鞋的那一刻起，直到你的订单被确认，数百个遥测事件被触发和捕获，为你的用户购买旅程提供了一个完整、可衡量的故事。
从你开始寻找一双鞋的那一刻起，直到你的订单被确认，数百个遥测事件被触发和捕获，为你的用户购买旅程提供了一个完整、可衡量的故事。漏斗的每一步都代表着用户的一个操作，并附带客户端日志信息，例如设备类型（iOS vs. Android）、用户人口统计信息和时间戳等，用于分析目的。
这就是每个用户旅程如何转化为有意义的洞察，揭示人们犹豫的地方、什么让他们满意、成功购买需要多少次点击以及什么让他们悄然离开。
在幕后，产品团队在各种工作中大量依赖这些数据信号来实时学习和适应：
- 实验 来测试想法和新功能。例如，假设亚马逊正在为老年用户（>65岁）测试一个更简单的结账界面，并希望在广泛推广之前从一部分用户那里测试该功能的性能。
- 个性化 来定制体验。行为遥测有助于训练模型以改进用户推荐引擎、排名、基于人口统计的定价等。
- 异常检测 以保持系统健康。如果
add_to_cart操作事件突然下降或payment_failed操作激增，这表明有问题，可能是 API 缓慢、网络故障或速率限制等。系统会在用户抱怨出现很久之前就发出警报。 - 运营效率 以确保整个产品生态系统平稳运行。例如，需求预测和库存规划都由数据信号提供信息，以确保商品的可用性。
产品表面上看似神奇的东西实际上是遥测在起作用，它将业务决策、机器智能和用户行为驱动到一个连续的反馈循环中。
遥测背后的数据工程骨干
遥测系统不是自建的。数据工程师位于产品、基础设施和数据科学的交叉点，将业务问题转化为可衡量的事件和可靠的管道。
强大的数据遥测文化始于数据工程师在产品规划会议中占有一席之地。他们在数据遥测的整个生命周期中发挥直接作用。
- 产品测量规划：定义测量计划——产品成功的标准。数据工程师通过映射数据准备情况，帮助优先考虑即时测量和需要新仪器才能测量的功能来指导产品经理和数据科学家。
- 遥测设计和规范：确定应记录哪些数据、分配事件优先级以及定义元数据、数据沿袭和所有权模型。这就是数据科学的需求、工程执行和产品愿景如何通过跨职能协作联系起来。
- 隐私审查：确保符合隐私标准，确保数据保留、匿名化和访问控制（ACL）尽早确定。数据工程师充当用户信任和数据效用之间的桥梁。
- 实施和赋能：与软件工程师协作，在客户端和服务器端进行日志记录。数据工程师对遥测实施的所有权各不相同：在某些组织中，他们拥有整个遥测管道；而在另一些组织中，他们则赋能平台团队进行自助服务。
- 验证和内部测试：数据工程师通过内部测试自己的产品并创建轻量级仪表板来验证遥测的完整性，以确认数据的可用性、完整性和时效性。通过在早期检测到遥测数据中的缺失或差距，可以避免数周的重新仪器化和下游报告数据问题。
通往人工智能驱动分析的桥梁
随着分析转向更多由人工智能驱动的对话式洞察，产品团队开始直接用纯英语与人工智能代理进行交流，而不是依赖静态仪表板或预先聚合的多维 OLAP 数据集。Kafka、Flink、Materialize 或 Snowflake 等系统可以为人工智能模型提供动力，使它们能够即时采取行动。
当产品经理问道：“为什么我们上周的销售额下降了？”人工智能代理会解释问题，检索相应的指标，并提供简洁、有上下文的回应。内置人工智能的分析只有在底层遥测提供一致的事件（如 users_visits、add_to_cart 和 purchase_complete）以及丰富的元数据时，才能回答这个问题，从而使产品团队能够与他们的数据进行交流，并让数据与他们对话，无需学习 SQL 或记忆仪表板。
产品团队现在可以与他们的数据进行交流，并让数据与他们对话，无需学习 SQL 或记忆仪表板。
这代表了人工智能时代洞察呈现方式的重大转变。组织已经开始认识到丰富、细粒度、事件级数据遥测流的真正价值，这些流为人工智能代理提供了分析和理解其产品实际使用方式所需的原始数据。产品团队现在可以与他们的数据进行交流，并让数据与他们对话，无需学习 SQL 或记忆仪表板。
但这都需要对数据可靠性负责。人工智能代理只有在其底层数据遥测可靠——干净、有上下文且完整——时才能返回准确的指标。大量的隐性工作旨在使对话式分析感觉简单。数据工程师是这种智能的无形赋能者，通过以下方式巧妙地协调系统：
- 定义语义层 使人工智能代理能够正确理解日常活跃用户、转化率等业务概念。
- 进行干净的遥测 捕获干净、有上下文、完整且隐私安全客户端和服务器端事件以及人口统计数据等行为遥测。
- 实施可观测性和治理，验证数据的完整性、时效性和沿袭，以便代理能够诚实地响应。
行业普遍存在的陷阱
然而，产品团队中绝大多数的遥测陷阱是文化上的，而非纯粹技术上的。真正的困难在于将人们聚集在一起，形成共同的遥测思维。这些问题包括：
- 碎片化的遥测：团队独立记录，导致数据不连贯，无法实现 360 度理解（例如，不同的团队拥有亚马逊订单与退款旅程的遥测配置）。
- 没有单一事实来源：指标从不同的上游源提取数据，导致团队之间报告冲突，并侵蚀对分析的信任。
- 可伸缩性问题：随着产品扩展新功能或子表面，未针对可伸缩性设计的遥测系统会迅速成为瓶颈。
每个组织都渴望成为数据驱动的，但很少有人意识到其基础可能多么脆弱。当遥测系统不具备可伸缩性或统一性时，对数据的信任就会开始动摇。
构建持久的遥测系统
记录的每一个遥测事件都代表着关于测量什么、如何保护它以及谁可以查看它的决策。这些小小的决策决定了你的整个数据生态系统的可靠性和地位。
首先是隐私和治理：在记录任何事件之前，考虑该信号是否真正必要非常重要。所有捕获的数据事件都需经过隐私审查，该审查还确定了在存档或删除之前的数据存储保留期限，并使用严格的访问控制实践，以确保只有授权人员才能访问数据。这些程序不仅仅是走形式；它们真正能够保护组织及其用户免受意外滥用。
然后是模式和元数据管理：最优秀的团队将事件模式（例如 add_to_cart、purchase_complete）视为代码，并应进行检查、记录和版本控制。详细的日志记录规范（又称事件目录）很快就会成为一个共享的操作手册，解释每个事件的含义、触发原因及其重要性。
接下来是质量和可观测性：在数据遥测投入生产之前，至关重要的是构建自动化检查以查找缺失、重复或过时的事件。自动化数据质量检查可以帮助你监控数据的完整性和时效性，因为一些遗漏的事件可能会歪曲产品理解。
最后是对齐：当遥测集成到产品需求文档中，而不是事后添加时，效果最佳。最成功的产品团队会进行产品需求文档评审，将数据工程师和数据科学家聚集在一起，确保正在构建的内容也能及时得到衡量。
数据遥测的未来
众所周知，遥测是人工智能模型积极学习和进化的基础。我们精心策划的每一个事件和元数据字段都成为智能系统学习、预测和适应的训练信号。
比以往任何时候都更重要的是，遥测管道现在必须确保语义一致性、准确的时间戳和无偏见的采样，因为数据漂移会扭曲下游模型的行为。数据工程师的作用在这里变得更加重要。
随着遥测变得更加丰富和实时，团队必须嵌入“隐私设计”原则，以确保每个收集到的信号都有明确的目的和受控的保留。
人工智能的成功取决于值得信赖的遥测。数据工程师将通过设计可伸缩、有上下文、合乎道德且为模型做好准备的遥测框架来塑造智能系统的未来。
