元数据
元数据概述
核心定义:“描述数据的数据”——记录数据的结构、含义、血缘、生命周期等核心属性。
元数据分类
| 类型 | 描述 | 典型数据 | 平台工具 |
| :------------- | :----------------------- | :------------------------- | :--------------- |
| 技术元数据 | 数据的物理存储与结构信息 | 表结构、文件路径、压缩格式 | DataWorks |
| 业务元数据 | 数据的业务含义与规则 | 指标定义(GMV)、业务术语 | OneData |
| 管理元数据 | 数据的运维与治理信息 | 负责人、访问权限、生命周期 | Data Catalog |关键技术创新
- 实时血缘捕获:解析Flink SQL语法树 → 自动生成字段级血缘。
- 智能元数据推荐:基于历史访问模式,自动推荐表关联关系。
- 冷热数据分级:根据
last_access_time自动迁移存储介质。
元数据应用
- Data Profile
- 基础标签 :针对数据的存储情况、访问情况、安全等级等进行打标。
- 数仓标签:针对数据是增量还是全量、是否可再生、数据的生命周期来进行标签化处理。
- 业务标签:根据数据归属的主题域、产品线、业务类型为数据打上不同的标签。
- 潜在标签:这类标签主要是为了说明数据潜在的应用场景, 比如社交、媒体、广告、电商、金融等。
- 元数据门户
- 数据地图:拥有功能强大的血缘信息,包括字段结构、分区信息、数据血缘、数据任务产出以及数据表索引、存储等配置信息。
- 数据管理:提供个人和 BU 全局资产管理、成本管理和质量管理等。
- 应用链路:一种是通过 MaxCompute 任务日志进行解析;一种是根据任务依赖进行解析。
- 数据建模
- 表的基础元数据:包括下游情况、查询次数、关联次数、聚合次数、产出时间等。
- 表的关联关系元数据:包括关联表、关联类型、关联字段、关联次数等。
- 表的字段基础元数据:包括字段名称、字段注释、查询次数、 关联次数、聚合次数、过滤次数等。
计算管理
系统优化
业务背景
- 资源分配失衡:MaxCompute集群日均运行200万 + 任务,传统Hadoop基于输入数据量的静态资源分配导致。
- Map阶段:小文件过多引发Instance负载不均,部分Instance处理仅4MB数据,部分超4GB。
- Reduce阶段:输入依赖Map输出,静态评估误差大,造成小任务资源浪费、大任务长尾(完成时间延迟)。
- 统计信息成本高:传统CBO(如Oracle)需全量收集统计信息,在大数据场景下资源消耗过大。
优化目标:提升资源利用率(CPU/内存/Instance并发);缩短任务执行时长,支持流量峰值场景。
HBO(History-Based Optimizer):基于历史的优化器
核心原理:动态结合任务历史执行数据与集群状态,通过基础资源估算 + 加权资源追加分配资源。
基础资源估算
Map Task:按输入数据量及预设处理量计算初始Instance数,分层控制防止超大任务独占资源。
Reduce Task:取最近7天Map输出的平均数据量作为Reduce输入基准,避免Map输入量估算偏差。
加权资源追加:对比历史处理速度与系统期望值,若平均速度低于期望值,按比例追加Instance。
CBO(Cost-Based Optimizer):基于代价的优化器
架构设计:基于Volcano模型,构建多模块协同优化引擎。
Meta Manager:提供表结构、分区信息等元数据,支持分区裁剪(如过滤条件排除无效分区)。
Statistics
低成本统计:采用抽样算法(如Distinct值估算)替代全量扫描,资源消耗降低90%。
关键指标:行数(Count)、唯一值(Distinct)、高频值(TopN)。
Rule Set:Substitute Rule——确定性优化(如过滤条件下推);Explore Rule——多路径探索(如Join重排序)。
Volcano Planner Core:基于代价模型,综合CPU、I/O、内存开销,选择总代价最低的执行计划。
任务优化
- 业务背景
| 问题类型 | 具体表现 | 优化目标 |
|---|---|---|
| 数据倾斜 | 少数Reduce处理超大数据量(如某个用户行为日志占比90%) | 负载均衡,避免单点长尾 |
| 小文件过多 | Map任务处理大量KB级文件,启动开销>计算耗时 | 合并文件,提升处理效率 |
| 长尾任务 | 99%的Task在5分钟内完成,剩余1%耗时超1小时 | 动态分裂+备份执行 |
| 资源浪费 | 空任务(如过滤后无输出)、重复计算 | 消除无效计算 |
数据倾斜优化
Map倾斜:通过上游小文件合并或者使用
DISTRIBUTE BY rand()打乱数据分布防止Map端的倾斜。Join倾斜优化
MapJoin优化: Join 操作提前到 Map 端执行, 将小表读人内存, 顺序扫描大表完成 Join 。
空值Key优化:将小表的空值Key处理成随机值。
热点Key优化:倾斜Key添加随机前缀,分桶打散后Join。
Reduce倾斜优化:一般由Count Distinct引起,可以对热点Key进行单独处理,通过
UNION ALL合并,或通过小文件合并解决。Group By倾斜优化(二次聚合):第一阶段进行局部聚合,对热点枚举值进行Map和Reduce,第二阶段轻量级汇总中间结果。
小文件优化
| 策略 | 适用场景 | 实现方式 | 收益 |
|---|---|---|---|
| 写入时合并 | 实时写入场景(Flink/Spark) | 设置文件滚动策略:128MB或10分钟 | 从源头杜绝小文件 |
| Compaction服务 | 离线数仓(Hive/MaxCompute) | 定时任务合并小于128MB的文件 | 文件数减少90% |
| 查询时合并 | Ad-hoc查询 | SELECT /*+ MERGE_FILES */ * FROM table |
查询I/O降低70% |
- 计算效率提升:四类无效任务治理
| 问题类型 | 检测方法 | 优化方案 |
|---|---|---|
| 空任务 | 输出文件大小为0 | 过滤条件前置,避免进入计算链 |
| 重复计算 | 血缘分析发现相同逻辑多任务执行 | 建立中间层复用结果(DWS汇总层) |
| 低效SQL | 扫描全表却仅返回10行 | 谓词下推+索引优化 |
| 过度聚合 | UV计算使用COUNT(DISTINCT)全扫描 | 改用HyperLogLog(误差<1%) |