写点什么

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

  • 2022 年 4 月 07 日
  • 本文字数:3885 字

    阅读完需:约 13 分钟

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


全文 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 日志优先持久化

日志中台现有的扇出数据,需要优先进行持久化,这是日志接入层基本要求。而实时流方面,在保证业务数据转发分钟级延迟的情况下,要做到数据“尽可能不丢”。

  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%+。


四、展望

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

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

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

用户头像

关注百度开发者中心,收获一手技术干货。 2018.11.12 加入

汇聚百度所有对外开放技术、平台和服务资源,提供全方位支持,助力开发者加速成功,实现开发者、消费者和百度三方共赢。https://developer.baidu.com/

评论

发布
暂无评论
日志中台不重不丢实现浅谈_百度开发者中心_InfoQ写作平台