元数据
元数据概述
-
核心定义："描述数据的数据"------记录数据的结构、含义、血缘、生命周期等核心属性。
-
元数据分类
类型 描述 典型数据 平台工具 技术元数据 数据的物理存储与结构信息 表结构、文件路径、压缩格式 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、内存开销，选择总代价最低的执行计划。
graph TB A[Meta Manager] --> B[提供表/分区元数据] C[Statistics] --> D[收集统计信息] E[Rule Set] --> F[执行优化规则] G[Volcano Planner Core] --> H[生成最小代价计划] B --> G D --> G F --> G -
任务优化
-
业务背景
问题类型 具体表现 优化目标 数据倾斜 少数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%）