B站元数据中心建设和数据治理实践

1. B站元数据中心建设和数据治理实践 From：villager(袁帅) TIME： 2023-01-14

2. 分享嘉宾: 袁帅（villager） B站基础架构/业务SRE 资深研发工程师 • 2020年加入B站 • 擅长基础架构、Devops、SRE等领域架构设计和研发 • 先后从事过大数据运维平台，B站Tidb平台化建设，运维作业平台及CMDB资产管理平台的研发工作 • 目前专注于SRE CMDB元信息平台的研发和治理工作

3. 01 背景：B站SRE体系是如何构建元数据和使用的目录 CONTENTS 02 一步步，服务树沦为一个毫无边界的元数据中心 03 B站运维数仓建设思路 04 关注数据质量

4. PART 一 B站SRE体系是如何构建元数据和使用

5. 服务树的诞生主要功能： l 服务（树形）目录：以应用的视角组织服务的树形目录，细化和统一资源隔离 l 全局应用ID：为应用分配全局唯一Appid,周边平台业务数据组织，聚合均已Appid标识 l 实例管理：提供应用部署相关的元信息（IP，机房，云厂商等） l 节点角色管理：基于内部统一用户，托管个系统角色用户管理功能，实现鉴权

6. 元数据构建如何构建数据 • 按照部门.项目.应用建立应用组织关系，提供全局应用ID • 管理业务和资产的关联关系，实现机器故障时的业务感知 • 提供RBAC模式业务人员角色 • 自上而下的角色继承关系

7. 元数据使用如何使用数据 • Appid作为平台资源管理核心 • 以CI平台为例，创建应用构建信息，编译构建产出围绕Appid建设， CD发布时根据应用选择制品，选择实例 • 周边平台的资源都围绕Appid建设，应用提供资源和人员信息关联

8. 元数据使用如何使用数据 • Appid作为平台资源管理核心 • 以CI平台为例，创建应用构建信息，编译构建产出围绕Appid建设， CD发布时根据应用选择制品，选择实例 • 周边平台的资源都围绕Appid建设，应用提供资源和人员信息关联

9. PART 二一步步，服务树沦为一个毫无边届的数据中心

10. OpenAPI混乱缺乏规范和制度，快速迭代，快速满足需求平台调用方缺乏治理和维护接口替换代码不处理，接口文档长期不维护消费场景太多，平台定制接口太多，很多功能可以复用接口

11. 数据更新依赖全量查询

12. 非标的使用方式太多

13. 无法应用画像 • 应用缺乏应用资源注册 • 应用上下游依赖关系没有梳理

14. SRE团队治理数据无从下手 • 最小权限安全控制原则，服务树权限申请审批没有限制导致人员、权限信息混乱 • 应用无法迁移 • 应用无法交接 • 应用下所使用的资源，无法做关联，覆盖不全

15. PART 三 B站运维数仓建设的整体思路

16. 明确目标和准则

17. 服务在运行期间与元数据中心的关系 • 元数据中心为服务全生命周期内提供数据基础 • 元数据中心也是作为服务的支撑平台存在的，贯穿服务始终

18. 元数据中心如何建立数据模型以数据全生命周期为出发点，确定属性，理清关系，确定消费场景，自动化流程保障数据准确性

19. 举例：应用数据模型的创建创建思路基本按照流程一步步细分自定义一个数据模型需要产品、研发一起界定数据规范需要各方遵守

20. 元数据中心产品架构

21. 元数据中心技术架构

22. 元数据中心数据采集 • 数据源(Origin): 采集的数据节点采集器会将数据发送到指定的内部消息队列里, DataCollection订阅指定Topics接收采集数据 • DataCollection集群: 分布式，连接Topics消费数据 • 数据存储：数据经DataCollection处理最终落在 Mysql, Redis和内部KV存储上

23. 原始数据关联关系分析 Relation Model 关系说明示例依赖 depend on 应用依赖配置包含 include k8s集群中包含组件运行 run in 容器运行在宿主机上安装在 install in 数据库安装在服务器上连接 connect with 服务器连接在交换机上 • 把 CI 和 CI 之间的关系种类列出来，前提需要产品、 • 业务方充分沟通 • 以应用为例： • 应用运行在物理主机上，应用的 DB 安装在服务器上， • 服务器链接网络交换机，机柜支撑物理设备。。。 • 按照梳理的关系分析整理出节点类型和边类型 • 最后定义出以应用视角的图模型

24. 如何落地

25. PART 四关注数据质量

26. 制度规范规范要求明确定义CMDB平台的作用，以及与其它业务系统间的关系明确定义资源的管理过程以及责任人和责任平台流程要求组织要求平台要求能够真实反映资源状况成立统一的配置管理能力建设主体逐步实现配置自动发现，自动维护能够完整的包含所有的资源信息以及资源间关系各个业务团队明确配置消费和完善的责任实时跟踪资源的状态及配置变化明确定义资源的基线标准以及偏差管理办法全局唯一的权威数据源形成配置管理讨论、优化和需求收集的机制模型灵活，能够根据业务需求实时扩展和调整从服务业务场景的视角来规划和建设配置管理能力数据能够被用户及系统方便，及时和高效的获取配置可视化，能够支持资源问题的分析和快速定位

27. 打造数据全生命周期闭环闭环： • 依托运维流程引擎闭环，针对资产类数据建设重构 • 期间存在短期没有闭环的流程，我们对此类上报的数据没有匹配上后，将此类数据列入异常数据中，生成数据报表，反推 • 保留所有变更记录

28. 持续的运营和改进阶四阶段四阶段三价值导向阶段二服务导向阶段一面向业务，支撑业务发展 • CMDB全面支撑服务及业务发展，如服务容量管理，可用性管理，成为IT运维的基石场景导向数据导向部门导向共享型CMDB，参考业界标准数据模型信息分散、孤立、管理无规范 • 不论是否有CMDB系统，实际都存在 CMDB需求，以部门为单元维护配置信息 • 信息是孤立的，不及时的，无法保证完整性和正确性 • 构建共享型CMDB，将各部门都关心的数据及相互关系统一纳入CMDB管理，并建立配置管理流程制度。 • 由于消费场景不明确，造成消费价值与生产成本的失衡面向特定使用场景，如资产管理，流程关联 • 局部数据标准化程度，准确性较高 • 由于使用场景单一，总体消费价值不高，生产成本相对较高整合型CMDB，整合更多的管理对象，对外提供数据服务 • 使用场景全面，提供数据供给服务，支撑日常操作管控，如自动化，监控，作业流管理，运维分析等 • 引入多样化的数据生产手段，逐步平衡消费价值与生产成本 • 配置管理主动推动组织IT管理水平的提升

29. Thanks