关于大数据:性能平台数据提速之路

46次阅读

共计 4058 个字符,预计需要花费 11 分钟才能阅读完成。

作者 | 性能中台团队

导读

性能平台负责 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 服务分级实践反对

  1. 进步服务效率:更好地理解用户的需要,提供更加精准、业余的服务,从而进步服务效率。
  2. 改善服务质量:服务分级能够让用户享受到更加贴近需要的服务,进步服务的品质和满意度。
  3. 优化资源配置:更好地依据不同的服务需要和服务对象,优化资源配置,进步资源利用率。

3.2.2 数据流 / 报表 SLA

3.3 数据点位 / 指标 / 报表治理

3.3.1 治理思路

[外链图片转存失败, 源站可能有防盗链机制, 倡议将图片保留下来间接上传(img-ezx2sPvX-1678155747102)(https://mmbiz.qpic.cn/mmbiz_png/5p8giadRibbO9765J2SfqzcZFneaE…)]

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 与需要性能的满足;用户通过业务宽表、宽表阐明文档、报表自助化平台实现报表自助化,来达成需要疾速实现。

04 将来瞻望

前文介绍了性能平台在数据生产与数据生产端的提速伎俩与具体案例,所做的一些致力。前面咱们还会持续优化零碎,如:

  • 数据时效性可阐明,报表承诺工夫与报表理论产出工夫,各个阶段数据漏斗,达到时效性数据的积淀与可剖析。
  • 数据准确性可证实,在 APP 接入层与数据报表之间,通过结构预期 Case 与理论数据做比照,来判断零碎数据准确性;

心愿,性能平台在数据安全合规的根底上疾速赋能撑持业务倒退。

——END——

举荐浏览:

采编式 AIGC 视频生产流程编排实际

百度工程师漫谈视频了解

百度工程师带你理解 Module Federation

巧用 Golang 泛型,简化代码编写

Go 语言 DDD 实战高级篇

Diffie-Hellman 密钥协商算法探索

正文完
 0