1. 为什么B站需要Apache Gravitino在B站这样日活用户过亿的平台每天产生的数据量堪比天文数字。我亲眼见证过数据团队凌晨三点还在为元数据不一致的问题加班——某个推荐算法因为Hive表和Iceberg表的schema对不上导致当天首页推荐全部乱套。这种数据打架的情况在引入Gravitino之前简直是家常便饭。传统元数据管理就像用不同方言沟通的团队。Hive Metastore、Kafka Schema Registry、HDFS目录各自为政工程师要记住三套不同的操作方式。最头疼的是AI训练数据管理动辄PB级的视频帧和特征文件散落在HDFS各个角落连创建者自己半年后都找不到原始数据。我们做过统计数据工程师60%的时间都花在在不同系统间手动同步schema翻找半年前创建的HDFS目录调试因元数据不一致报错的Flink任务给没有权限体系的文件目录打补丁2. Gravitino如何重构元数据管理体系2.1 统一元数据门户想象一下把派出所、车管所、民政局的服务窗口合并成市民中心。Gravitino的REST API就是这样的存在它用三层结构管理所有数据资产Metalake相当于数据宇宙的命名空间Catalog按数据源类型划分比如HiveCatalog、KafkaCatalogSchema/FileSet结构化数据用Schema非结构化数据用FileSet我们内部称这套系统为OneMeta最实用的改进是元数据检索速度提升70%。以前查个Hive表要穿透三层服务现在就像用搜索引擎一样快。2.2 文件管理的革命性变化AI团队是最早受益的群体。过去管理训练数据是这样的流程# 老方法硬编码路径 data_path hdfs://cluster/user/ai_team/video_frames/2023/07/15现在变成# 新方法语义化访问 data_path viewfs://gravitino/prod/ai/video_frames#date2023-07-15这个viewfs协议背后是GVFSGravitino Virtual File System它像给HDFS套了层智能导航系统。我们给某个FileSet设置TTL策略后系统会自动清理过期数据AI团队再也不用手动写清理脚本了。3. 在AI场景中的实战效果3.1 训练数据版本管理模型迭代最痛苦的不是调参而是找不到上个月用的训练数据。通过FileSet Iceberg branch的组合现在可以这样操作主分支保持原始视频帧数据为每个实验创建特性分支如augmentation_v2在不同分支上应用数据增强策略-- 创建实验分支 CREATE BRANCH augmentation_v2 IN gravitino.prod.vision_data COMMENT 数据增强实验v2;存储成本直降80%因为所有分支共享底层数据块。3.2 跨团队数据协作推荐算法组和广告组经常需要相同用户特征但各自维护副本。现在通过FileSet权限控制grant READ on fileset gravitino.prod.user_features to group recommendation_team;物理存储只有一份权限精细到字段级别。某次数据异常时我们通过血缘关系30分钟就定位到问题源头而过去这种排查至少需要两天。4. 踩坑经验分享第一个大坑是HDFS小文件合并。最初直接对FileSet路径执行合并操作结果元数据统计信息全部错乱。后来摸索出正确姿势通过GVFS获取临时写入路径合并完成后触发元数据刷新更新FileSet的统计信息第二个坑是Kafka schema演化。有次PB格式变更导致Flink作业集体挂掉现在我们强制要求所有schema变更必须通过CI/CD流水线向后兼容性检查作为卡点自动生成版本差异报告5. 未来还能怎么玩正在测试的两个杀手级功能模型元数据管理把MLflow的模型版本整合到Gravitino实现从原始数据到模型产出的全链路追溯冷热数据自动分层根据FileSet访问模式自动迁移数据预计可再省30%存储成本有团队在尝试更激进的方案——用FileSet管理Kafka消息持久化存储这样流批统一存储就不是梦了。不过这个方案还在POC阶段等有具体成果再和大家分享。