性能平台数据提速之路
作者 | 性能中台团队
导读
性能平台负责 MEG 所有研发数据的管理、接入、传输、应用等各个环节。数据的提速对于公司报表建设、决策分析、转化策略效果都有至关重要的影响。重点介绍数据生产端与消费端提速落地实践，如何高性价比满足大数据生产端提速？如何在数据合规基础上快速满足数据报表提速？本文从业务优化视角整体介绍提速思路，包含 5 类优化路径，涉及 18 种提速方法。
全文 3689 字，预计阅读时间 10 分钟。
01 概述
1.1 性能平台
性能平台是 APP 性能追踪的一站式解决方案平台，为 APP 提供全面、专业、实时的性能分析服务与工具链。基于先进的端异常采集能力、实时反混淆技术等，提供实时性强、定位速度快、场景丰富的应用监控分析能力，并构建异常解决的闭环，在厂内移动端产品得以大范围应用，保障移动端用户体验，有效地减少了用户流失。
1.2 接入情况
已覆盖了厂内大多数重点产品，其中包括：百度 APP 全打点、小程序、矩阵 APP 等，数据指标如下：
接入情况：几乎覆盖了厂内已有 APP，小程序，创新孵化 APP，以及厂外收购 APP。
服务规模：处理数据千亿/日、端到端入库时间毫秒级别、覆盖用户数 6 亿+。
1.3 名词解释
图灵：新一代数仓平台，在实时计算、存储能力、查询引擎、资源调度等均有提升。
UDW：Universal Data Warehouse，百度通用数据仓库，UDW 用平台化的存储管理、数据管理、数据建设过程管理和元数据管理技术，提供全面、一致、高质量、面向分析的用户行为基础数据，百度早期数据仓库。
TM：是一个面向工作流的分布式计算系统，具有简洁、高可靠性和高吞吐量的特性，且易被方便地管理和监控。能够满足准实时（秒到分钟级）的流式计算需求，故障时可以做到数据不丢不重。
一脉：整合多种数据源的全业务自助分析工具，为分析师、PM、运营、RD 各角色提供服务。一脉打破了原有报表、工具的定制限制，支持零 SQL 基础的同学可视化拼接查询条件、或直接 SQL 查询，同时提供多种通用分析模板供大家使用。
AFS：百度自研的 Append-Only 分布式文件系统产品，覆盖百度所有业务线，为开发者提供高性能、高可用、高可扩展的存储能力，广泛应用于离线计算、AI 训练、数据备份等场景。
1.4 业务介绍
覆盖范围：涵盖崩溃、卡顿、Flutter、端异常、日志回捞、网络库、磁盘等大部分性能场景，覆盖了公司多条产品线
数据加工：提供实时、可靠准确的实时用户监测，秒级精确加工 10 万 QPS 吞吐数据。
异常感知方面：事前线下检测，事中平台上线 check 机制、事后分钟级告警、感知并分析异常，快速止损；
问题分析阶段：多维聚类、多维探测、全网热力图、日志调用链分析、日志回捞等工具，协助快速定位问题；
02 面临的问题
2.1 数据生产阶段
数据技术基建落后；存储系统（厂版化无法迭代）、查询引擎（厂内引擎下线、查询速度较慢）、实时计算（不支持实时引擎）、资源调度（资源弹性弱）等能力不足；
数据缺少服务分级；核心数据与非核心区分，服务级别保障机制不明确；离线数据流架构不合理、大量使用公共队列数据 SLA 无法保障。预期：实时流数据分钟级别 SLA、准实时数据 30 分钟级别 SLA、离线流数据小时级别 SLA；
数据无效/重复上报；部分点位下线、点位之间功能重合度高仍在上报导致数据总量存在虚高；数据报表冗余，无人访问或者业务重复；有限计算/存储资源供给到无效数据上。
2.2 数据消费阶段
数据合规性难保障；数据缺少统一出口，数据消费同时存在接口、结果层数据库、中间层数据等系统中进行数据报表呈现，用于数据分析、报警监控。
数据需求满足度低；报表类需求占我们需求整体接近 50%, 数据需求需要点对点单独排期与开发，此研发流程投入大，需求交付速度慢。
用户整体满意度低；数据实时性差：从数据产生到数据可被查询，中间存在较高时延(从数十分钟到天级别不等)查询较慢,SLA 保障机制弱；数据需求交付慢：用户数据需求完全依赖数据团队产出，当有人力补充时数据维护/学习成本高，容易出现 Delay，增加字段/修改数据源等会覆盖整个流程。
03 优化路径
3.1 新老基建对比
思路：基于流批一体的思路，通过 TM 引擎的实时解析平铺 + Spark 动态索引导入图灵的方式代替 QE 引擎静态导入 UDW，从而进行 ETL 阶段的提速，在该阶段提前将嵌套字段进行铺平形成图灵研发大表去除旧数据流中的中间表产出环节。
3.1.1 新老基建对比
3.1.2 新老数据流
3.2 数据服务分级
3.2.1 服务分级理论支持
提高服务效率：更好地了解用户的需求，提供更加精准、专业的服务，从而提高服务效率。
改善服务质量：服务分级可以让用户享受到更加贴近需求的服务，提高服务的质量和满意度。
优化资源配置：更好地根据不同的服务需求和服务对象，优化资源配置，提高资源利用率。
3.2.2 数据流/报表 SLA
3.3 数据点位/指标/报表治理
3.3.1 治理思路
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ezx2sPvX-1678155747102)(https://mmbiz.qpic.cn/mmbiz_png/5p8giadRibbO9765J2SfqzcZFneaEYktrhGsuY2DPzAUO42UkeViblKmWILWHbAzch1Hibk1w6dibcGZyHWD202KHWA/640?wx_fmt=png)]
3.4 数据合规性治理
3.4.1 背景介绍
2021 年 9 月 1 日正式实施《中华人民共和国数据安全法》，涉及数据的出口管制、数据分类分级、数据合规性等一系列数据方面法律法规要求。数据消费流程增加势必会影响用户使用体验，如何在数据满足合规的基础上快速助力业务发展是我们的努力的方向。
数据 BI 平台/ 性能平台/其他数据分析平台数据接入方案大致分为如下几种：
1、直连存储引擎；
2、数据抽象 API ；
3、数据自产自销；我们的业务特点连接双端研发、多方数据、QA 等多方面角色对接，初中期适合 API 方式，慢慢收敛到数据自产自销。
补充说明：
市面上的 BI 分析均支持 API 方式连接，基本已实现协议标准化。BI 连接数据库查询方式，主要优点在于快速实现报表，但是在数据合规、数据缓存、负载均衡、多引擎数据聚合等能力上明显弱于 API 方式。
3.4.2 API 优化点举例说明
3.4.3 元数据查询协议说明
3.5 数据自助化建设
3.5.1 背景介绍
通过近一年需求数据分析，报表类需求占整体数据需求的 50%，如果实现数据报表自助化，需要按照数仓分层，可达成数据消费侧的需求快速交付与报表时效性提升。
自助化方式与数据流有关，针对实时数据流采用内存方式构建宽表，准实时/离线采用磁盘宽表构建。
3.5.2 实时化自助化（内存）
内存自助化核心逻辑包含：
日志协议 Schema 的解析；性能平台在业务方配置自助化任务之前，会采用离线任务天级别的将性能平台涉及到的 UBC 点位进行 Schema 的解析，即将 UBC 协议的 Schema 进行按层级全局展开，供业务方在界面上进行勾选。
内存宽表的建立； 业务方在性能平台上完成自助配置化任务时，勾选自身需要清洗的 UBC 点位日志经过平铺后的协议字段，通过性能平台提供的通用函数解析(透传、时间函数、网络函数等)以及性能平台提供的自定义函数 QLExpress 进行原始协议的清洗，然后平铺成一张内存宽表。
宽表数据聚合；业务方自身的需求往往有 PV 聚合、UV 聚合、分位数聚合等一些常用指标的聚合计算，此时利用性能平台提供的聚合模板选择相应维度指标进行计算，形成最终的聚合结果指标。
UI 配置、告警配置；业务方得到最终的聚合结果指标后，可以选择聚合后的维度和指标构建 UI，例如折线图，表格等。同时，也可以根据聚合后的指标配置阈值告警。最终，通过上述的流程，业务方自助化的完成了数据流的建立、UI 报表的生成，告警的配置。
3.5.3 准实时 &离线数据自助化（磁盘）
以 Feed 研发宽表举例说明，通过数据分层强化数据层职责范围，每一层级数据量级明显减少，对用户侧结果数据报表提速明显。数据研发同学关注各层之间数据 SLA 与需求功能的满足；用户通过业务宽表、宽表说明文档、报表自助化平台实现报表自助化，来达成需求快速实现。
04 未来展望
前文介绍了性能平台在数据生产与数据消费端的提速手段与具体案例，所做的一些努力。后面我们还会继续优化系统，如：
数据时效性可说明，报表承诺时间与报表实际产出时间，各个阶段数据漏斗，达到时效性数据的沉淀与可分析。
数据准确性可证明，在 APP 接入层与数据报表之间，通过构造预期 Case 与实际数据做对比，来判别系统数据准确性；
希望，性能平台在数据安全合规的基础上快速赋能支撑业务发展。
——END——
推荐阅读：
版权声明: 本文为 InfoQ 作者【百度Geek说】的原创文章。
原文链接:【http://xie.infoq.cn/article/3469533108b4263792ebe701a】。文章转载请联系作者。
百度官方技术账号 2021-01-22 加入
关注我们，带你了解更多百度技术干货。
评论