日志中台不重不丢实现浅谈

PHP小丑

导读：日志数据的生命周期包含日志采集、接入、传输、应用等各个环节。数据的稳定性对于公司报表建设、决策分析、转化策略效果都有至关重要的影响。全文旨在介绍百度日志中台当前的现状，公司内部应用推广情况。尤其在数据准确性的建设上，进行深入的探讨。数据产生到最终业务应用中各个环节的稳定性建设，包括：数据上报时效性优化、接入持久化的思考、数据流式计算过程中的不重不丢建设等。 
 全文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，横向通用组件方面。
  
  
  
  
  

二、日志中台核心目标
如前文介绍，日志中台承载着百度内所有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 日志优先持久化
日志中台现有的扇出数据，需要优先进行持久化，这是日志接入层基本要求。而实时流方面，在保证业务数据转发分钟级延迟的情况下，要做到数据“尽可能不丢”。

  

• 持久化：接入层在真正业务处理之前，优先将数据持久化处理，“尽可能”先保证数据不丢失。
    
  
• 实时流：避免直接对接消息队列，优先采用落盘+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视频播放中的解码优