大数据之路：阿里巴巴大数据实践——元数据与计算管理

元数据

元数据概述

• 核心定义：“描述数据的数据”——记录数据的结构、含义、血缘、生命周期等核心属性。

• 元数据分类

  类型	描述	典型数据	平台工具
  技术元数据	数据的物理存储与结构信息	表结构、文件路径、压缩格式	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%）