二、日志中台核心目标

如前文介绍，日志中台承载着百度内所有APP日志打点、站在数据生产的最前沿，在保证功能覆盖全、接入快速&灵活的基础上，面临的最重要核心挑战是数据的准确性。整个数据从产出、日志中台接入处理、下游应用，一切数据质量问题需要日志中台承载。而数据的准确性可以拆解为2部分：

• 不重：保证数据严格意义的不重复。需要防止系统层面的各种重试、架构异常恢复导致的数据重复问题；

• 不丢：保证数据严格意义的不丢失。需要防止系统层面的故障、代码层面bug等导致的数据丢失问题。

而做到系统层面的近乎100%的不重不丢，需要面临较多的难题。

2.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.3 流式计算思考

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

• 打点server：将实时流通过消息队列，单独扇出至流式框架（分流flow入口）

• 分流flow：将不同点位信息，基于流量大小，进行拆分输出至不同消息队列。这样做的好处是兼顾了数据灵活扇出要求，下游可以灵活订阅；

• QPS小于某些阈值 or 横向点位等：单独消息队列输出，达到灵活扇出；

• QPS较小点位，进行聚合输出至聚合队列，以便节省资源；

• 业务flow：如果业务有自己的数据流式处理需求，可以单独部署作业，以便各个作业资源隔离。

• 输入：组合订阅分流flow的不同扇出数据，进行数据计算；

• 输出：数据混合计算后，输出至业务消息队列，业务方自行订阅处理；

• 业务filter：作为发送至业务层的终极算子，负责各个数据流在端到端层面。（打点server、端的系统重试数据）的不重。打点server将每一条打点数据生成唯一标识（类似一条数据md5），业务flow filter算子进行全局的去重。

通过客户端发送逻辑不断优化，在时效性上也取得了巨大收益。收敛率双端提升2%+。

四、展望

前文介绍了日志中台服务在打点数据准确性保障方面，做的一些努力。当然，后面我们还会继续深挖系统的风险点，如：

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

希望，日志中台持续不断优化，为业务准确使用打点数据做出贡献。

推荐阅读：

视觉Transformer中的输入可视化方法

深入理解 WKWebView (渲染篇) —— DOM 树的构建

深入理解 WKWebView（入门篇）—— WebKit 源码调试与分析

GDP Streaming RPC 设计

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

来源：百度Geek说