性能平台数据提速之路
GEEK TALK
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机制、事后分钟级告警、感知并分析异常，快速止损；
问题分析阶段：多维聚类、多维探测、全网热力图、日志调用链分析、日志回捞等工具，协助快速定位问题；
GEEK TALK
02
面临的问题
2.1 数据生产阶段
数据技术基建落后；存储系统（厂版化无法迭代）、查询引擎（厂内引擎下线、查询速度较慢）、实时计算（不支持实时引擎）、资源调度（资源弹性弱）等能力不足；
数据缺少服务分级；核心数据与非核心区分，服务级别保障机制不明确；离线数据流架构不合理、大量使用公共队列数据SLA无法保障。预期：实时流数据分钟级别SLA、准实时数据30分钟级别SLA、离线流数据小时级别SLA；
数据无效/重复上报；部分点位下线、点位之间功能重合度高仍在上报导致数据总量存在虚高；数据报表冗余，无人访问或者业务重复；有限计算/存储资源供给到无效数据上。
2.2 数据消费阶段
数据合规性难保障；数据缺少统一出口，数据消费同时存在接口、结果层数据库、中间层数据等系统中进行数据报表呈现，用于数据分析、报警监控。
数据需求满足度低；报表类需求占我们需求整体接近50%, 数据需求需要点对点单独排期与开发，此研发流程投入大，需求交付速度慢。
用户整体满意度低；数据实时性差：从数据产生到数据可被查询，中间存在较高时延(从数十分钟到天级别不等)查询较慢,SLA保障机制弱；数据需求交付慢：用户数据需求完全依赖数据团队产出，当有人力补充时数据维护/学习成本高，容易出现Delay，增加字段/修改数据源等会覆盖整个流程。
GEEK TALK
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 治理思路
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 元数据查询协议说明
// Schema 数据获取能力描述// 协议能力描述：// 1. 数据查询能力,多引擎/标准SQL查询能力封装「如:palo/mysql/clickhouse/es-sql等」Query结构。// 2. 数据聚合能力,具备单关键字数据组合&Merge能力,如果Len(Schema.Query)>1:具备数据聚合能力. // 3. 数据缓存能力,两层级缓存能力封装,Cache结构。type Schema struct { // 元数据查询能力描述 Query []Query `json:"query"` // 元数据整体缓存能力描述 Cache Cache `json:"cache"`}
// Query 数据查询能力描述type Query struct { // 结构化查询描述 SQL string `json:"sql"` // 产品线信息, rpc_name = meta_{engine}_{prod}.toml, rpc通信具备超时控制、服务发现、高级负载均衡策略等稳定性提升能力 Prod string `json:"prod"` // 存储引擎描述, 调用不同引擎能力 Engine string `json:"engine"` // 单次查询缓存能力描述 Cache Cache `json:"cache"`}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与需求功能的满足；用户通过业务宽表、宽表说明文档、报表自助化平台实现报表自助化，来达成需求快速实现。
GEEK TALK
04
未来展望
前文介绍了性能平台在数据生产与数据消费端的提速手段与具体案例，所做的一些努力。后面我们还会继续优化系统，如：
数据时效性可说明，报表承诺时间与报表实际产出时间，各个阶段数据漏斗，达到时效性数据的沉淀与可分析。
数据准确性可证明，在APP接入层与数据报表之间，通过构造预期Case与实际数据做对比，来判别系统数据准确性；
希望，性能平台在数据安全合规的基础上快速赋能支撑业务发展。
END