解决方案:埋点数据采集和应用生命周期

　　解决方案:埋点数据采集和应用生命周期

　　埋地数据采集

和应用程序生命周期

　　作者介绍

　　@hrd-0.618 (徐凡)

　　新网*敏*感*词*分析师。

　　专注于数据分析、埋点采集和用户行为分析、BI数据可视化。

　　“数据人类创造者联盟”成员。

　　1 背景介绍

　　产品的精细化运营、千人个性化推荐等各类业务，都依赖于标准化、高质量的嵌入式数据。但埋点数据的上传、解析、存储、分析整个过程耗时长，需要多团队协作。为了让有兴趣的读者有一个整体的了解，本节将结合工作实践和应用生命周期重点介绍H5埋点数据采集。

　　2 埋点采集内容

　　3 埋点数据流

　　3.1 向日志采集服务发送数据

　　前端+后端-->日志采集服务

　　前后端数据以类json格式实时异步发送到日志采集服务进行分析。

　　3.1.1 用户事件：user

　　{data:[{userid: 用户唯一ID, equipment: {//header, 包括浏览器、设备、网络等 equipment_os: 操作系统, equipment_os_version: 操作系统版本, equipment_brand: 品牌...}, location: {gps :{gps_lon: 经度, gps_lat: 纬度, gps_country: gps 国家, gps_province: gps 省, gps_city: gps 城市, gps_district: gps 区}, ip:{...}}}] , time: 时间, cookie: 序列号, event_type :user ,from:{ channel:channel,product:product} }

　　3.1.2 页面事件：page

　　{data:[{ page_id: 页面ID, page_name: 页面名称, page_url: 页面url, src_page_url: 源页面url }] , time: 时间, cookie: 序列号, event_type: page , from: { channel: 频道, product:产品} }

　　3.1.4 接口事件：interface

　　{data:[{ interface_id: 接口ID, interface_name: 接口名称, result: 接口调用结果, result_remarks: 接口调用描述, response_time: 接口响应时长}], start_time: 接口调用开始时间, end_time: 接口调用结束时间, cookie : 序列号, event_type: interface, from: { channel: channel, product: product} }

　　3.2 实时数仓建模

　　日志采集服务-->实时数仓（kafka）

　　

" />

　　3.2.1 基本字段处理

　　一个。分析日志采集服务采集到的四个事件的json数据，得到四个事件的基本字段，实时写入到kafka消息队列的四个主题中。

　　b. 通过Flink/StreamSQL，实时或微批量消费4条topic数据，存储在4张HBase表中。

　　3.2.2 将用户事件链接到行为事件

　　消费用户事件主题，根据序列码cookie将用户信息与行为信息相关联，构建实时用户行为宽表。

　　3.3 离线数据仓库建模

　　3.3.1 粘贴源层

　　通过 ETL 提取 4 个事件 HBase 表。

　　3.3.2 模型层

　　根据源层4个事件的序列码cookie，将用户信息与行为信息相关联，构建离线用户行为宽表。

　　4 埋点数据应用

　　4.1.1 用户行为

　　根据实时用户宽表，将数据写入Elasticsearch，或者将数据写入外部接口，可以查询到实时的用户行为记录。

　　根据线下用户宽表，将数据写入Elasticsearch，或者将数据写入外部接口，可以查询线下用户行为记录。

　　4.1.2 用户行为统计

　　根据四大事件主题数据，结合用户行为指标体系，通过聚合统计分析方法，得到不同维度的用户行为指标。

　　页面级别：

　　数据日期

　　频道名称

　　操作系统

　　日期类型：日、7日、30日、总计

　　维度类型：页面/段/频道

　　可视字段：频道名称、链接、页面名称、PV、UV、访问用户数、平均停留时间、页面跳出次数、页面跳出率

　　

" />

　　按钮级别：

　　数据日期

　　频道名称

　　操作系统

　　日期类型：日、7日、30日、总计

　　4.1.3 用户留存分析

　　方面：

　　数据日期：2021-08-02

　　频道名称：如“xxx”，无摘要

　　用户类别：摘要，新用户

　　数据类型：留存数、留存率

　　产品层级，以及留存人数的选择

　　选择保留的产品级别

　　功能层面：比如美团APP对使用“单车”功能的用户进行留存分析。

　　4.1.4 用户行为标签及客户群体筛选

　　构建用户行为标签，筛选目标客户群。

　　根据客户的实时/线下业务状态，当满足一定的行为特征时，为业务人员筛选出不同的目标客户群，通过营销平台以不同的方式触达。

　　针对产品品类较少的企业，将不同场景的客群实时推送给业务人员，并与营销平台联动，精准营销。

　　当然，对于产品品类较多的企业，比如电商相关场景，基于用户行为构建实时推荐系统是行业主流。

　　4.1.5 基于用户行为断点

　　可以结合实时和线下的用户行为和业务状态，为有行为断点的用户进行外呼或其他方式。

　　5 结论

　　本文主要结合实际工作中的一些经验做一个简单的概述。埋点采集主要是代码埋点，人工维护成本比较高。未来可以结合实际场景更好的采集

行业内的数据；用户行为分析也需要逐步完善。，欢迎大家批评指正，有兴趣的朋友可以联系我一起讨论。

　　解决方案:*敏*感*词*分布式链路分析计算在字节跳动的实践

　　一、概述

　　微服务架构的快速发展使得分布式链路跟踪系统成为观测系统中越来越重要的组成部分。经过几年的发展，字节跳动的分布式链路追踪系统已经覆盖了字节跳动的大部分在线业务，完成了数万个微服务和数百万微服务实例的在线链路追踪。在经典的指标观察分析和单请求链路跟踪的基础上，如何从浩瀚的分布式链路数据中进一步挖掘更高层次的信息，为业务架构优化、服务治理、成本等场景提供服务优化。提供更高效的数据支持，成为下一步亟待解决的问题。

　　本次分享主要介绍了我们构建海量链路数据分析计算系统的实践经验，以及一些具体的落地场景。

　　2. 可观察性和链接追踪

　　2.1 基本概念

　　为了方便读者更好地理解“链接分析”，我们先来说说什么是“可观察性”和“链接跟踪”。已经熟悉“可观察性”和“链接追踪”概念的读者可以跳过本章。

　　随着微服务架构的快速发展，软件系统正在从单一的应用发展为由大量微服务节点组成的复杂应用。为了更好地管理和控制复杂的软件系统，“可观察性”工具变得越来越重要。可观察性工具建立在可观察性数据的基础上，一般包括以下几个部分：Link Tracking Trace、Logging、Timing Metrics、Code-level Profiling、Event Event和与元数据相关的CMDB等。

　　为了帮助大家对可观察性工具有更直观的体验，这里举例说明如何基于可观察性工具解决工作中的实际问题：某服务告警通知值班人员的故障率在增加，点击Correlate到error indicator对应的Trace，在Trace中定位到错误的来源，查看源头的关键异常日志和代码栈，发现源头的报错服务正在执行变更操作，所以基本定位到这个变化很可能是导致这个失败的原因。有了高质量的可观测性数据和工具，一个对系统不是很熟悉的值班人员也可以快速完成对本次故障的排查和止损。

　　分布式链路追踪（Trace）是可观测系统的组成部分之一。Trace从狭义上讲是对单个请求的详细跟踪，记录请求在每个环节的调用关系，耗时，以及各种详细的标签和事件。同时Trace也起到了链接各种可观察性数据的作用，即同一个Request Context的数据载体。分布式请求上的各类信息（Metrics/Logs..）通过Trace可靠关联，进而可以构建各种可观察性数据的上下滚动钻取的跳转功能。

　　2.2 字节链接跟踪系统

　　经过几年的发展，字节链接跟踪系统现已覆盖公司大部分在线业务。整体开发流程如下：

　　2019年：Trace 1.0完成Trace组件能力建设。

　　2020年：Trace 2.0实现Metrics/Trace/Log的融合，升级数据协议和技术架构，开始打造一站式观测平台Argos。

　　2021年：实现与字节跳动大部分主流框架组件的默认集成，微服务在公司所有业务线的覆盖率>80%。

　　2022：构建和探索场景化、智能化的场景，比如本次分享聊天中的“链接分析”。

　　Byte Link Tracker 当前状态数据（2022 年 10 月）：

　　覆盖范围：50,000 多个微服务/FAAS，300 万多个容器实例。

　　使用：每日UV 6,000+，每日PV 40,000+。

　　吞吐量：跨度数 2000 万+/s（默认 0.1% 采样）。

　　资源配比：100+ CPU核心支持100万Span/s。

　　SDK性能：单线程40w Span/s。

　　查询性能：TraceID 枚举 P50 < 100 ms，P99 < 500 ms。

　　数据生成到可检索延迟：AVG < 1 分钟，P99 < 2 分钟。

　　存储资源：10 PB（3 个副本 TTL 15 天）。

　　字节链追踪系统从数据接入端、消费存储端、查询平台端的整体架构如下图所示。更多详情请阅读之前的分享。上次的分享比较详细地介绍了如何从零到一搭建分布式链路跟踪系统。本文主要讲链路跟踪系统中的链路聚合计算和分析部分。

　　3.链接分析技术实践

　　3.1 需求场景

　　经常使用Trace的同学可能对Trace的印象是通过TraceID或者一些Tags可以检索到一个或者一些Traces，然后从Trace数据中仔细查看详细的调用traces和各种Tags来分析一些具体的问题，比如为什么一个请求很慢，或者请求出错的原因。

　　但是我们也面临着一些更高层次的问题，比如面对一个不断变化的复杂微服务系统：

　　

" />

　　这些问题的答案很难通过人工一条一条地查看迹线来获得可靠的结果。但是，它可以从大量的Trace数据中自动计算出来，为最终的决策提供可靠的数据支持。我们称这种大量踪迹链接分析的聚合计算。

　　3.2 基本原则

　　链路分析的基本原理是聚合计算大量的迹线。一般遵循MapReduce计算模型。在这个过程中，可能会结合一些订阅规则和其他数据，得到计算结果，然后应用到具体的场景应用中。

　　3.3 技术架构

　　适用于大量链路数据的聚合计算的可选模式主要有三种，即基于在线数据流的流式计算、基于离线数据流从在线存储中查询有限踪迹后的即兴（抽样）计算。bins的离线计算。这三种计算方式的特点分析如下表所示。

　　在分析了三种聚合计算模式的特点之后，分析了链路分析场景所面临的技术需求。

　　基于以上分析，我们认为没有一种计算模型可以解决所有问题，所以我们最终选择的技术方案是流式、即兴、离线一体化的技术方案：基于统一的基础数据模型和逻辑算子，支持三种不同的计算引擎，满足不同的场景需求。

　　在实施该方案的过程中，我们总结了一些有益的实践经验：

　　Trace本身的数据结构比较复杂，其分析计算逻辑往往具有一定的复杂性。算子和引擎的分离，便于将同一个逻辑算子应用到不同的计算引擎上，可以更好的提高研发效率和代码可维护性。例如，性能瓶颈分析相关的算法既可以用于即兴计算，也可以用于离线计算。

　　Trace数据往往存在一些数据不规则性，比如超高维的接口名称，导致聚合后的数据维度远超预期，影响计算任务的稳定性。自动化的异常数据发现和封禁或降级机制可以起到更好的保护作用。

　　尽量保留聚合分析结果对应的具有代表性的原创

（极端）Trace样本，可以提高分析结果的可解释性和用户信任度。

　　大数据计算成本高，非基础功能可采用按需订阅模式提高ROI；构建任务灵活降级能力，资源紧张时优先保证高频基础功能的高可用。

　　4.链路分析实现场景

　　介绍完链接分析的底层技术架构，我们再介绍一些具体的实现场景。

　　4.1 精确链路拓扑计算

　　链路分析中使用频率最高、使用场景最广的就是链路拓扑的计算。这里所说的“链路拓扑”是指进入任意一个服务节点，获取所有流经该节点的trace的聚合路径，从而清楚地知道该服务节点的上下游依赖拓扑。

　　由于字节微服务数量众多，中端和基础服务种类繁多，调用关系相对复杂，因此我们进行拓扑计算的目标是：

　　举例说明什么是精度要求：如下图，“抖音.X”和“火山.Y”都调用“中台.Z”，但对于“抖音.X”的流量，“中台. Z" "会用到"Redis.Volcano"，而"中台.Z"会用到"Redis.Volcano"给"Volcano.Y"的流量，所以实际上没有"抖音.X"和"Redis.Volcano" ”直接依赖。那么当我们搜索“Douyin.X”时，想要的拓扑是[“Douyin.X”，“Zhongtai.Z”，“Redis.Douyin”]而不是“Redis.Volcano”。

　　举例说明什么是灵活性需求：如下图，不仅可以根据入口检索拓扑，还可以根据中间节点“Zhongtai.Z”或存储组件检索拓扑节点“Redis.抖音”；不仅可以按照服务+接口的粒度检索拓扑，还可以按照服务粒度、服务+集群粒度、服务+机房粒度等其他粒度进行检索。

　　面对这样的技术需求，我们研究了业界现有的一些拓扑计算方案：

　　结合字节场景的实际需求，权衡准确率、成本和检索速度，我们最终设计了新的方案。

　　精确的链路拓扑具有广泛的应用场景。下面是一些具体的例子：

　　4.2 全链路流量估算

　　全链路流量预估主要回答的问题是：

　　

" />

　　全链路流量估计是在精确拓扑计算的基础上实现的，因此也采用流计算来估计每条路径上的踪迹数以及踪迹对应的采样率数据。计算结果的格式如下图所示。每个拓扑中的每个边都对应于一个估计的流量和流量比。基于这样的数据，我们可以针对任何微服务接口给出上述两个问题的答案。

　　全链路流量预估的主要应用场景如下：

　　4.3 强弱依赖分析

　　强弱依赖信息是服务稳定性治理场景的重要数据支撑，也可以通过在线Trace数据自动计算。

　　强依赖：当异常发生时，影响核心业务流程和系统可用性的依赖称为强依赖。

　　弱依赖：当异常发生时，不影响核心业务流程，不影响系统可用性的依赖称为弱依赖。

　　如下图所示，当A调用B失败时，如果A仍能成功响应其Client，则B为A的弱依赖；当A调用B失败时，如果A不能成功响应它的Client，那么B就是A依赖的强依赖。

　　强弱依赖计算的技术目标包括：

　　为了尽可能满足数据的完整性和时效性要求，我们选择了流式计算方式，从数据流中选择Trace with Error来计算强弱依赖。需要注意的是，短期的实时数据样本往往是不够的，需要结合历史积累的数据进行联合判断才能下结论。

　　强弱依赖分析的主要挑战：

　　强弱依赖分析的主要应用场景包括：

　　4.4 全链路性能反模式分析

　　在实践中，我们观察到有一些非常典型的性能反模式问题，可以从Trace数据中自动发现。常见的性能反模式包括：

　　性能反模式问题的发现也有以下两个要求：

　　因此，性能反模式分析任务需要自动发现最严重的反模式问题，给出极值样本，并关联这些问题所在路径的流量和入口优先级，帮助业务优化延迟和服务成本。尽早解决与它们相关的潜在稳定性风险。

　　4.5 全链路性能瓶颈分析

　　单个请求的分布式跟踪视图清晰直接，但局限性在于观察者无法确定单个请求呈现的跟踪模式是普遍现象还是特殊现象。因此，从大量Trace数据中分析链路性能瓶颈，找出整体性能模式和worst case样本，也是链路分析的需求场景。

　　链路性能模式是从批量跟踪中聚合和计算的，满足临时模式和离线模式的要求。在即兴模式下，可满足筛选任意时间段、灵活条件（多种标签、耗时区间）的批次痕迹，快速获得分析结果。离线订阅模式可以满足更完整地分析全量Trace数据的整体性能模式，观察长期趋势的需求。因此，我们将在即兴和离线计算模式下重用链路性能分析聚合算子。

　　分析结果示例：

　　4.6 误差传播链分析

　　单个Error Trace可以观察到一条错误传播路径，但观察者无法确认一条错误传播路径是否一定代表了一个普遍问题，也无法回答错误传播的影响。因此聚合大量的Error Trace来分析整体的错误来源、传播路径、影响面也是链路分析的需求场景。

　　与链路性能分析类似，错误传播路径是从批量跟踪中聚合和计算的，这在临时模式和离线模式下都是必需的。我们还将错误传播链分析算子应用于临时和离线计算模式。Ad hoc模式可以满足任意时间段、灵活条件（各种标签）批量过滤Error Trace的需求，快速得到聚合分析结果。离线订阅模式可以满足更完整的全量Error Trace数据聚合分析需求，观察长期趋势，助力业务长期稳定优化。

　　分析结果示例：

　　五、总结与展望

　　本文主要介绍在从零到一建立链路追踪基础能力后，如何聚合分析海量链路数据，回答更高层次的场景化问题。我们分享了我们具体的技术选型过程和实施技术架构，以及一些成功的实施案例。