导读：日志数据的生命周期蕴含日志采集、接入、传输、利用等各个环节。数据的稳定性对于公司报表建设、决策分析、转化策略成果都有至关重要的影响。全文旨在介绍百度日志中台以后的现状，公司外部利用推广状况。尤其在数据准确性的建设上，进行深刻的探讨。数据产生到最终业务利用中各个环节的稳定性建设，包含：数据上报时效性优化、接入长久化的思考、数据流式计算过程中的不重不丢建设等。

全文 4047 字，预计浏览工夫 12 分钟

一 简述

1.1 中台定位

日志中台是针对打点数据的一站式服务，实现打点数据的全生命周期治理，只需简略开发就能快捷实现日志数据采集、传输、治理以及查问剖析等性能，实用于产品经营剖析、研发性能剖析、运维治理等业务场景，帮忙 APP 端、服务端等客户摸索数据、开掘价值、预感将来。

1.2 接入状况

日志中台已笼罩了厂内大多数重点产品，其中包含：百度 APP 全打点、小程序、矩阵 APP 等，接入方面收益如下：

• 接入状况 ：简直笼罩了厂内已有 APP，小程序，翻新孵化 APP，以及厂外收买 APP
• 服务规模 ：日志条数 几千亿 条 / 天，顶峰 QPS 几百万 / 秒，服务稳定性 99.9995 %

1.3 名词解释

客户端：指用户能够间接应用的软件系统，通常部署在用户手机或 PC 等终端设备上。例如百度 APP、小程序等。

服务端 ：用于响应客户端发动的网络申请的服务，通常部署在云服务器上。

日志中台 ：此处特指端日志中台，包含端日志全生命周期的能力建设。包含打点 SDK / 打点 server/ 日志治理平台等外围组件。

打点 SDK：负责打点日志的采集、封装、上报等性能。依据不同的日志生产端，分为 APP 端 SDK、H5 端 SDK，依据场景辨别为通用点位 SDK、性能 SDK、小程序 SDK 等，用户依据需要能够集成不同的 SDK。

打点 server：日志接管服务端，是日志中台服务端最外围的模块。

特色 / 模型服务 ：日志中台将须要进行策略模型计算的点位信息实时转发给上游 < 策略举荐中台 >。特色 / 模型服务是 < 策略举荐中台 > 的入口模块。

1.4 服务全景图

日志服务次要包含根底层、治理平台、业务数据利用、产品撑持几个层面。围绕着各个层级，在 2021.6 月，制订 & 公布了百度客户端日志上报标准。

• 根底层 ：反对了 APP-SDK、JS-SDK，性能 SDK、通用 SDK，满足各类打点需要的疾速接入场景。依靠大数据根底服务，将打点数据散发至各个利用方。
• 平台层 ：治理平台反对数据元信息管理、保护，并管制打点生命全周期环节。在线层面反对数据的实时、离线转发、并依靠正当的流量管制、监控保障服务稳定性在 99.995%。
• 业务能力 ：日志打点数据输入至数据中心、性能平台、策略中台、增长中台等，无效助力产品决策分析、端品质监控、策略增长等畛域。
• 业务反对 ：笼罩重点 APP、新孵化矩阵 APP，横向通用组件方面。

  

![图片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/13cd319482d24e938012abb110f46b2f~tplv-k3u1fbpfcp-zoom-1.image)

二、日志中台外围指标

如前文介绍，日志中台承载着百度内所有 APP 日志打点、站在数据生产的最前沿，在保障性能笼罩全、接入疾速 & 灵便的根底上，面临的最重要外围挑战是数据的准确性。整个数据从产出、日志中台接入解决、上游利用，所有数据品质问题须要日志中台承载。而数据的准确性能够拆解为 2 局部：

• 不重：保证数据严格意义的不反复。须要避免零碎层面的各种重试、架构异样复原导致的数据反复问题；
• 不丢：保证数据严格意义的不失落。须要避免零碎层面的故障、代码层面 bug 等导致的数据失落问题。

而做到零碎层面的近乎 100% 的不重不丢，须要面临较多的难题。

2.1 日志中台架构

接入日志中台打点数据从端上生产至在线服务到最终（实时 / 离线）转发至上游，须要通过如下几个环节：

• 数据利用形式不同，有以下集中类型：
• 实时
• 准实时流（音讯队列）：供上游数据分析应用，特点：较高（min）时效性，须要严格意义的数据精确。典型利用：研发平台、trace 平台；
• 纯实时流（RPC 代理）：供上游策略利用，特点：秒级时效性，容许肯定水平的数据失落。典型利用：举荐架构。
• 离线：离线大表，所有日志选集，特点：天级 / 小时级时效性，须要严格意义的数据精确。
• 其余：须要肯定时效性和准确率

2.2 面临的问题

从下面日志中台架构来看，存在如下问题：

• 巨型模块：打点 server 承载了所有的数据处理逻辑，性能耦合重大：
• 性能多：接入 & 长久化、业务逻辑解决、各种类型转发（rpc、音讯队列、pb 落盘）；
• 扇出多：有 10+ 个业务扇出流，通过打点 server 转发。
• 间接对接音讯队列：从业务视角看，存在发送音讯队列音讯失落危险，且无奈满足业务不重不丢要求。
• 业务无等级划分：
• 外围业务与非核心业务架构部署耦合
• 互相迭代、相互影响

三、不重不丢实现

3.1 数据不丢的实践根底

3.1.1 唯 2 失落数据实践

• 端：因为挪动端的主观环境影响，如白屏、闪退、无奈常驻过程、启动周期不确定等因素，导致客户端音讯会存在肯定概率失落
• 接入层：因为服务器不可避免的存在故障（服务重启、服务器故障）的可能性，也存在肯定的数据失落概率
• 计算层：接入点之后，基于流式框架，建设须要严格意义的保证数据不重不丢。

3.1.2 日志中台架构优化方向

数据接入层面：

• 先长久化数据，后业务解决的准则
• 升高逻辑复杂度

上游转发层面：

• 实时流类：严格意义不失落
• 高时效类：保证数据时效，容许可能存在的局部失落
• 资源隔离：将不同业务的部署进行物理隔离，防止不同业务相互影响
• 辨别优先级：依照业务对不同数据诉求，辨别不同类型

3.2 架构拆解

基于日志中台现状剖析，联合日志打点服务的唯 2 实践，咱们针对日志中台对现有架构进行问题拆解和架构重构。

3.2.1 打点 server 服务拆解（优化接入层数据失落）

基于以上不重不丢的实践，日志接入层进行了如下几个方面的建设，尽可能做到数据不重不丢。

• 日志优先长久化：尽可能升高接入点因服务器故障等起因导致的数据失落问题；
• 巨型服务拆解：接入点应该秉承简略、轻量的思路建设，防止过多业务属性导致的服务稳定性问题；
• 灵便 & 易用：在不重不丢的同时，基于业务需要特点，设计正当的流式计算架构。

3.2.1.1 日志优先长久化

日志中台现有的扇出数据，须要优先进行长久化，这是日志接入层根本要求。而实时流方面，在保障业务数据转发分钟级提早的状况下，要做到数据“尽可能不丢”。

1. 长久化：接入层在真正业务解决之前，优先将数据长久化解决，“尽可能”先保证数据不失落。
2. 实时流：防止间接对接音讯队列，优先采纳落盘 +minos 转发音讯队列形式，保证数据至多分钟级提早的状况下，尽量不丢。

3.2.1.2 巨型服务拆解 & 性能下沉

为升高日志服务过多的性能迭代带来的稳定性危险，同时须要满足上游业务灵便订阅的需要，须要保障日志中台扇出的合理性。咱们将在线服务进一步拆解：

• 实时流类业务 ：打点音讯流转通过接入层→ 扇出层→ 业务层→ 业务。
• 接入层：性能繁多，设计指标为数据尽可能不丢，保证数据第一工夫长久化；
• 扇出层：保障上游灵便的订阅形式，进行数据拆分 & 重组（目前基于打点 id 维度扇出）；
• 业务层：组合订阅扇出层数据，实现业务自有的需要实现，负责将打点数据生产并转发至上游；
• 高时效类业务：
• 策略实时举荐类的业务，独自抽离服务，撑持 rpc 类的数据转发，保障超高时效并保证数据转发 SLA 达到 99.95% 以上；
• 其余类业务：
• 数据监控、vip、灰度等业务，对时效、失落率要求进一步升高，可将这部分业务抽离至独自服务；
• 技术选型 ：针对数据流式计算特点，咱们选用了 streamcompute 架构，保证数据在通过接入层之后，全流程的“不重不丢”。

因而，将日志服务进一步拆解，如下图所示：

3.2.1.3 流式计算思考

为了保障严格数据流稳定性，须要依赖流式计算架构，在解决数据在业务计算过程中齐全的不重不丢同时，满足业务不同场景获取数据的诉求。针对日志中台特点，咱们对流式计算解决架构进入如下设计：

• 打点 server：将实时流通过音讯队列，独自扇出至流式框架（分流 flow 入口）
• 分流 flow：将不同点位信息，基于流量大小，进行拆分输入至不同音讯队列。这样做的益处是兼顾了数据灵便扇出要求，上游能够灵便订阅；
• QPS 小于某些阈值 or 横向点位等：独自音讯队列输入，达到灵便扇出；
• QPS 较小点位，进行聚合输入至聚合队列，以便节俭资源；
• 业务 flow：如果业务有本人的数据流式解决需要，能够独自部署作业，以便各个作业资源隔离。
• 输出：组合订阅分流 flow 的不同扇出数据，进行数据计算；
• 输入：数据混合计算后，输入至业务音讯队列，业务方自行订阅解决；
• 业务 filter：作为发送至业务层的终极算子，负责各个数据流在端到端层面。（打点 server、端的零碎重试数据）的不重。打点 server 将每一条打点数据生成惟一标识（相似一条数据 md5），业务 flow filter 算子进行全局的去重。

3.2.2 打点 SDK 数据上报优化（解决端上报数据失落）

客户端打点，因端所处的环境问题，会存在肯定的数据失落危险。尤其当打点调用并发较高时候，数据不可能第一工夫全副发送到服务端。因而，客户端须要将业务打点数据暂存本地的数据库，而后异步进行音讯发送至服务端，以达到异步发送、优先本地长久化不丢的保障。然而，APP 能够在任何状况下退出、卸载，那数据在本地停留越久，对业务数据价值越小，更容易失落，所以咱们须要针对数据上报进行如下方向的优化：

• 减少上报机会：独自定时工作轮询、业务打点时触发携带缓存数据、缓存音讯达到阈值触发（试验取得）等伎俩，进步缓存数据的上报的机会，尽量升高音讯在本地缓存工夫。
• 减少上报音讯个数：在保证数据上报大小、条数（试验比照失去阈值），将上报音讯的条数进行调整，获得正当上报个数，达到音讯第一工夫达到服务端的最大收益。

通过客户端发送逻辑一直优化，在时效性上也获得了微小收益。收敛率双端晋升 2%+。

四、瞻望

前文介绍了日志中台服务在打点数据准确性保障方面，做的一些致力。当然，前面咱们还会持续深挖零碎的危险点，如：

• 磁盘故障导致数据失落：接入层后续针对磁盘故障，基于公司的数据长久化能力，建设数据的严格不失落根底

心愿，日志中台继续一直优化，为业务精确应用打点数据做出奉献。

举荐浏览 ：

视觉 Transformer 中的输出可视化办法

深刻了解 WKWebView (渲染篇) —— DOM 树的构建

深刻了解 WKWebView（入门篇）—— WebKit 源码调试与剖析

GDP Streaming RPC 设计

百度 APP 视频播放中的解码优