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

元数据

元数据概述

  • 核心定义:"描述数据的数据"------记录数据的结构、含义、血缘、生命周期等核心属性。

  • 元数据分类

    类型 描述 典型数据 平台工具
    技术元数据 数据的物理存储与结构信息 表结构、文件路径、压缩格式 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%)
graph LR A[原始任务] --> B{优化分析} B -->|数据倾斜| C[随机前缀/二次聚合] B -->|小文件| D[Compaction服务] B -->|长尾| E[任务分裂+备份执行] B -->|无效计算| F[空任务过滤+中间层复用] C & D & E & F --> G[高效任务]
相关推荐
摇滚侠14 小时前
Spring Boot 3零基础教程,WEB 开发 静态资源默认配置 笔记27
spring boot·笔记·后端
天若有情67317 小时前
Java Swing 实战:从零打造经典黄金矿工游戏
java·后端·游戏·黄金矿工·swin
一只叫煤球的猫17 小时前
建了索引还是慢?索引失效原因有哪些?这10个坑你踩了几个
后端·mysql·性能优化
magic3341656319 小时前
Springboot整合MinIO文件服务(windows版本)
windows·spring boot·后端·minio·文件对象存储
开心-开心急了19 小时前
Flask入门教程——李辉 第一、二章关键知识梳理(更新一次)
后端·python·flask
IT小哥哥呀19 小时前
电池制造行业数字化实施
大数据·制造·智能制造·数字化·mom·电池·信息化
Xi xi xi19 小时前
苏州唯理科技近期也正式发布了国内首款神经腕带产品
大数据·人工智能·经验分享·科技
掘金码甲哥19 小时前
调试grpc的哼哈二将,你值得拥有
后端
小学鸡!20 小时前
Spring Boot实现日志链路追踪
java·spring boot·后端
yumgpkpm20 小时前
华为鲲鹏 Aarch64 环境下多 Oracle 、mysql数据库汇聚到Cloudera CDP7.3操作指南
大数据·数据库·mysql·华为·oracle·kafka·cloudera