天博电竞APP性能平台负责MEG所有研发数据的管理、接入、传输、应用等各个环节。数据的提速对于公司报表建设、决策分析、转化策略效果都有至关重要的影响。重点介绍数据生产端与消费端提速落地实践，如何高性价比满足大数据生产端提速？如何在数据合规基础上快速满足数据报表提速？本文从业务优化视角整体介绍提速思路，包含5类优化路径，涉及18种提速方法。

　　性能平台是APP性能追踪的一站式解决方案平台，为APP提供全面、专业、实时的性能分析服务与工具链。基于先进的端异常采集能力、实时反混淆技术等，提供实时性强、定位速度快、场景丰富的应用监控分析能力，并构建异常解决的闭环，在厂内移动端产品得以大范围应用，保障移动端用户体验，有效地减少了用户流失。

　　已覆盖了厂内大多数重点产品，其中包括：百度APP全打点、小程序、矩阵APP等，数据指标如下：

　　UDW：Universal Data Warehouse，百度通用数据仓库，UDW用平台化的存储管理、数据管理、数据建设过程管理和元数据管理技术，提供全面、一致、高质量、面向分析的用户行为基础数据，百度早期数据仓库。

　　TM：是一个面向工作流的分布式计算系统，具有简洁、高可靠性和高吞吐量的特性，且易被方便地管理和监控。能够满足准实时（秒到分钟级）的流式计算需求，故障时可以做到数据不丢不重。

　　一脉：整合多种数据源的全业务自助分析工具，为分析师、PM、运营、RD各角色提供服务。一脉打破了原有报表、工具的定制限制，支持零SQL基础的同学可视化拼接查询条件、或直接SQL查询，同时提供多种通用分析模板供大家使用。

　　AFS：百度自研的Append-Only分布式文件系统产品，覆盖百度所有业务线，为开发者提供高性能、高可用、高可扩展的存储能力，广泛应用于离线计算、AI训练、数据备份等场景。

　　覆盖范围：涵盖崩溃、卡顿、Flutter、端异常、日志回捞、网络库、磁盘等大部分性能场景，覆盖了公司多条产品线

　　异常感知方面：事前线下检测，事中平台上线check机制、事后分钟级告警、感知并分析异常，快速止损；

　　问题分析阶段：聚类、探测、全网热力图、日志调用链分析、日志回捞等工具，协助快速定位问题；

　　数据技术基建落后；存储系统（厂版化无法迭代）、查询引擎（厂内引擎下线、查询速度较慢）、实时计算（不支持实时引擎）、资源调度（资源弹性弱）等能力不足；

　　数据缺少服务分级；核心数据与非核心区分，服务级别保障机制不明确；离线数据流架构不合理、大量使用公共队列数据SLA无法保障。预期：实时流数据分钟级别SLA、准实时数据30分钟级别SLA、离线流数据小时级别SLA；

　　数据无效/重复上报；部分点位下线、点位之间功能重合度高仍在上报导致数据总量存在虚高；数据报表冗余，无人访问或者业务重复；有限计算/存储资源供给到无效数据上。

　　数据合规性难保障；数据缺少统一出口，数据消费同时存在接口、结果层数据库、中间层数据等系统中进行数据报表呈现，用于数据分析、报警监控。

　　数据需求满足度低；报表类需求占我们需求整体接近50%, 数据需求需要点对点单独排期与开发，此研发流程投入大，需求交付速度慢。

　　用户整体满意度低；数据实时性差：从数据产生到数据可被查询，中间存在较高时延(从数十分钟到天级别不等)查询较慢,SLA保障机制弱；数据需求交付慢：用户数据需求完全依赖数据团队产出，当有人力补充时数据维护/学习成本高，容易出现Delay，增加字段/修改数据源等会覆盖整个流程。

　　思路：基于流批一体的思路，通过TM引擎的实时解析平铺 + Spark动态索引导入图灵的方式代替QE引擎静态导入UDW，从而进行ETL阶段的提速，在该阶段提前将嵌套字段进行铺平形成图灵研发大表去除旧数据流中的中间表产出环节。

　　2021年9月1日正式实施《中华人民共和国数据安全法》，涉及数据的出口管制、数据分类分级、数据合规性等一系列数据方面法律法规要求。数据消费流程增加势必会影响用户使用体验，如何在数据满足合规的基础上快速助力业务发展是我们的努力的方向。

　　3、数据自产自销；我们的业务特点连接双端研发、多方数据、QA等多方面角色对接，初中期适合API方式，慢慢收敛到数据自产自销。

　　市面上的BI分析均支持API方式连接，基本已实现协议标准化。BI连接数据库查询方式，主要优点在于快速实现报表，但是在数据合规、数据缓存、负载均衡、多引擎数据聚合等能力上明显弱于API方式。

　　通过近一年需求数据分析，报表类需求占整体数据需求的50%，如果实现数据报表自助化，需要按照数仓分层，可达成数据消费侧的需求快速交付与报表时效性提升。

　　日志协议Schema的解析；性能平台在业务方配置自助化任务之前，会采用离线任务天级别的将性能平台涉及到的UBC点位进行Schema的解析，即将UBC协议的Schema进行按层级全局展开，供业务方在界面上进行勾选。

　　内存宽表的建立； 业务方在性能平台上完成自助配置化任务时，勾选自身需要清洗的UBC点位日志经过平铺后的协议字段，天博电竞APP通过性能平台提供的通用函数解析(透传、时间函数、网络函数等)以及性能平台提供的自定义函数QLExpress进行原始协议的清洗，然后平铺成一张内存宽表。

　　宽表数据聚合；业务方自身的需求往往有PV聚合、UV聚合、天博电竞APP分位数聚合等一些常用指标的聚合计算，此时利用性能平台提供的聚合模板选择相应维度指标进行计算，形成最终的聚合结果指标。

　　UI配置、告警配置；业务方得到最终的聚合结果指标后，可以选择聚合后的维度和指标构建UI，例如折线图，表格等。同时，也可以根据聚合后的指标配置阈值告警。最终，通过上述的流程，天博电竞APP业务方自助化的完成了数据流的建立、UI报表的生成，告警的配置。

　　以Feed研发宽表举例说明，通过数据分层强化数据层职责范围，每一层级数据量级明显减少，对用户侧结果数据报表提速明显。数据研发同学关注各层之间数据SLA与需求功能的满足；用户通过业务宽表、宽表说明文档、报表自助化平台实现报表自助化，来达成需求快速实现。

　　前文介绍了性能平台在数据生产与数据消费端的提速手段与具体案例，所做的一些努力。后面我们还会继续优化系统，如：

　　数据时效性可说明，报表承诺时间与报表实际产出时间，各个阶段数据漏斗，达到时效性数据的沉淀与可分析。

　　数据准确性可证明，在APP接入层与数据报表之间，通过构造预期Case与实际数据做对比，来判别系统数据准确性；