- 最新动态
- 功能总览
- 产品介绍
- 计费说明
- 快速入门
-
用户指南
- 准备工作
- 权限管理
- 首页
- 流编排
-
连接器
- 连接器概述
- 连接器管理
-
公共连接器
- 公共连接器概述
-
内置类
- 手动触发流
- 计划
- 流运行监控
- 业务对象
- 控制
- 变量
- 变量V2
- 日期时间
- API流
- API流(简易版)
- SQL执行器
- SQL构造器
- Code代码
- Code代码(简易版)
- JSON构造器
- 编码工具
- 消息中间件(RabbitMQ)
- 消息中间件(RocketMQ)
- 文档数据库(MongoDB)
- 分布式缓存(Redis)
- 分布式消息(Kafka)
- SAP RFC
- SOAP
- HTTP(无认证)
- HTTP(基本认证)
- HTTP(IAM认证)
- HTTP(apiKey认证)
- HTTP(AKSK认证)
- MySQL
- webSocket连接器
- MQTT连接器
- wait
- 数据解析
- 输入输出定义
- 调用子流程
- 数据格式转换
- 生成器
-
华为类
- 华为图像识别
- 华为图像识别(体验)
- 华为图像搜索
- 华为文字识别
- 华为文字识别(体验)
- 华为人脸识别
- 华为语音识别
- 华为语言生成
- 华为语言理解
- 华为机器翻译
- 华为机器翻译(体验)
- 华为天气服务
- 华为天气(体验)
- 华为会议(体验)
- 华为云OBS
- 华为短信
- 华为短信(体验)
- 华为空气质量(体验)
- 华为人证核身
- 华为内容审核
- 华为内容审核(体验)
- 华为位置服务
- HMS位置服务
- HMS花瓣地图
- AOM运维告警
- AOM运维日志
- 消息通知
- 云消息服务(KooMessage)
- 开天企业工作台
- EG事件网格
- 函数工作流
- 对话机器人服务CBS
- ROMA数据集成
- 数据管理服务
- 弹性云服务器
- 华为云数字工厂
- IoT数据分析
- 人像动漫化渲染
-
生活服务类
- 全网热搜榜
- 抖音热搜榜
- 早安心语
- 晚安心语
- 生活小窍门
- 每日简报
- 每日菜谱
- 每日英语
- 健康小提示
- 营养成分表
- BMI标准体重
- IT资讯
- 影视资讯
- 足球联赛
- NBA赛事
- NBA新闻
- 汽车新闻
- 综合新闻
- 国内地区新闻
- 手机号空号检测
- 身份证归属地
- 坐标地址查询
- 旅游景区大全
- 全国景点查询
- 中药大全
- 药品说明书
- 药品查询
- ip地址查询
- 收货地址解析
- 全球物流快递查询
- 全球时间查询
- 宠物大全
- 随机密码生成
- 字符串处理
- 汉字转拼音
- 金额转大写
- 中国老黄历
- 周公解梦
- 吉凶测试
- 性格测试
- 星座运势
- 近义词反义词
- 励志古言
- 英文励志语录
- 网络流行语
- 土味情话
- 雷人笑话
- 猜字谜
- 猜成语
- 网易163邮箱
- 网易126邮箱
- QQ邮箱
- 二十四节气
- 空气质量指数
- 心知天气
- 气象预警
- 天气预报
- 贷款公积金计算器
- 一站到底
- 查询域名解析
- WeatherAPI
- 网安备案查询
- 航班时刻票价查询
- 全国实时油价
- 企业微信(服务端)
- 钉钉(企业内部应用)
- 历史上的今天
- 限制高消费查询
- 企业工商信息查询
- 企业经营状况查询
- 企业经营风险查询
- 银行卡归属信息查询
- 黄金价格查询
- 白银价格查询
- 全国快递物流查询
- 全国高校信息查询
- 查询海关编码
- 沪深股票
- 股票历史行情查询
- 世界时区时间
- 银行网点查询
- 医院信息查询
- 商品条形码查询
- 企业开票税号查询
- 台风预警
- 科学计算器
- 汇率查询
- 实时汇率
- 汇率换算
- 语雀
- 站长之家
- 数据安全中心(DSC)
- 云日志服务LTS
- 飞书云文档
- 百度地图
- 高德地图
- 快手
- 国家预警信息
- 停车场查询
- 拼多多
- 佐糖图片修复
- 铁路出行
- 连接管理
- 边缘节点
- 行业模板介绍
- API生命周期
- Astro轻应用
- 业务可视化
- 应用模型
- 集成项目管理
- 审计
- 最佳实践
- API参考
- SDK参考
- 常见问题
- 视频帮助
- 文档下载
- 通用参考
链接复制成功!
基本概念
元模型设计原则
企业架构元模型的核心目的是“Organize、Analyze、Communicate”:
- Organize:组织是指将企业中流程、业务能力、应用、技术、人等组成企业架构的元素形成一张完整的视图。在元模型设计方法中,是利用适当的抽象方法,来将类似概念抽象,这样在看企业架构的时候,能够看到最关键的组成要素,而不是陷入细节。
- Analyze:分析是指能够使用企业架构元数据去回答关键的业务问题。在元模型设计方法中,需要将元素合理的进行组织,以方便查询关键的元数据,来回答这些业务问题。
- Communicate:沟通是指能够让受众清晰易懂理解企业架构的关键元素。比如如果一个元模型中定义了dashboard,受众要能够理解其含义是仪表盘。元模型是企业架构师向受众讲述架构故事的一种媒介,如果一些有价值的见解被模糊的概念或者晦涩的技术所掩盖,那么受众将很难获得有价值的决策信息。
元模型设计的七个原则,以帮助企业架构师设计比较好的元模型
- 限制元模型中组件(Component,即本文语境中的实体)和引用类型(Reference Type)的数量:
- 对实体和引用类型的数量要保守,控制企业架构元模型的复杂度至关重要。假设你使用15个实体定义一个领域元模型来描述Cloud Service,此时是清晰明了的;如果你需要进一步描述Cloud Service如何支撑应用、应用如何支撑业务流程、业务流程如何形成商业产品和服务,此时就需要跨领域元模型,如果每个领域都是15个实体,此时60个实体之间要建立关系和查询能力,会变得异常复杂;未来降低这种复杂度,就需要进行一定程度的抽象。
- 避免过度具体化或过度抽象化。
- 简化和整合标准以满足需求:
- 在参考多个建模标准之前,请了解多个建模标准中的重叠部分,每个标准都是面向一个特定领域的,例如BPMN用于业务流程建模,UML用于软件工程建模,ITIL用于IT运维建模,ERD用于数据建模等。
- 在必要时消除多个标准中的重复部分和简化标准。
- 定义多个业务、IT团队共同的语言:
- 理解不同的部门、团队可能对相同的概念使用不同的术语,例如Dynamics CRM、Application、Deployment Package表达的是一个意思。
- 使用例子来描述概念的异同处。
- 使用层次机构来组织架构中的架构元素:
- 确保高阶概念(High-Level)和低阶概念(Low-Level)的匹配:
- 理解哪些实体是高阶概念、哪些是低阶设计,如业务能力(Business Capability)或者价值流(Value Stream)被认为是高阶概念,功能(Function)或者业务流程(Business Process)被认为是低阶概念。
- 检查高阶概念的实体和关系,在低阶概念中对应的一致性。构建企业架构模型需要的是一个持续的过程,在高阶概念和低阶概念模型之间相互检查,寻找差距(gaps)和脱节(disconnects),持续的协调一致。
- 体系结构模型的顶层(高阶概念)的目的是聚合细节(低阶概念),而不是消除细节;建议先从低阶概念设计开始,根据业务和IT的工作逐步抽象高阶概念。
- 在使用抽象实体类型时需注意:
- 使用抽象实体类型对其他实体类型进行分类。
- 如果使用不当,抽象实体类型可能会降低您进行影响分析或建立可追溯性的能力。
举例:部门A使用Outlook,其可以定义为“Organization A- Uses - Outlook”;部门B使用Gmail,其可以定义为“Organization - Uses - Gmail”;如果将Outlook和Gmail抽象为TechnologyService实体,其值为Email,则部门A和B使用的都是Email服务,无法直接得出使用的邮件服务的差异。
- 最完美的元模型是持续演进的:
- 建立一个有合理信心的内核模型(Core),但不要害怕扩展实验。
- 根据用户反馈、技术演进和这七个原则来不停演进企业架构元模型。
元模型概述
FabricMetamodelV2.0内核和扩展实体如图3所示。
FabricMetamodelV2.0内核中包括如下的一些实体:
- 行政单元(AdministrationUnit):行政单元指按照各行业固有的行政管理结构来划分、具备行政管理职责的单位。如政府的省/市/区、企业的集团/分支机构、法人实体等。
- 行政领域(AdministrationDomain):在企业组织范围内,行政领域指基于向外部和内部客户提供的商品或服务的主要子结构,如零售、物流、云计算服务等;在政府领域内,行政领域指政府各职能领域,如工商、公安、卫检等。
- 用户(User):数据资产管理和运营用户旅程中的个人参与方,如数据管家、数据分析师、数据普查员等。
- 空间(Space):用于描述数据分析师的工作空间,此空间为一个逻辑概念,空间中涵盖了“数据分析师团队、团队拥有的数据底座、有访问权限的数据资产、数据开发工具、数据应用”等关联概念。
- 主题域分组(SubjectAreaGroup):公司顶层信息分类,通过数据视角体现公司最高层关注的业务领域。
- 主题域(SubjectArea):互不重叠数据的高层面的分类,用于管理下一级的业务对象。
- 业务对象(BusinessObject):业务领域重要的人、事、物,承载了业务运作和管理涉及的重要信息。
- 逻辑数据实体(LogicalEntity):具有一定逻辑关系的数据属性的集合。
- 属性(Attribute):描述业务对象的数据特征,是数据最基本的单元。
- 数据标准(DataStandard):定义组织层面需共同遵守的属性层数据含义和业务规则,是组织层面对某个数据的共同理解,这些理解一旦确定下来,就应作为组织层面的标准在组织内被共同遵守。
- 应用(Application):应用是数据资产运营枢纽中对IT系统的统称,包括文件应用、业务系统应用、企业应用、数据仓库应用等。
- 数据平台实例(DataPlatformInstance):数据源是元数据的来源。包括以下几类来源:关系型数据库(比如MySQL、Oracle)、对象存储(比如华为云OBS)、企业应用(比如金蝶ERP)、BI软件(比如四方伟业BI、帆软BI)、大数据存储(比如Hive、HDFS)、消息队列(比如kafka)、ETL工具(比如AWS Glue)、时序数据库(比如influx)等。数据源又称数据平台实例。
- 数据集(DataSet):代表了数据的集合,通常指数据库中的表/视图、流处理系统中的流、数据湖系统中以文件或文件夹形式存在的数据集合等。
- 数据集容器(Container):包括一组DataSet的逻辑库。
- 数据集字段(SchemaField):数据集中的每一列字段对应一个数据集字段。
FabricMetamodelV2.0扩展中包括如下的一些实体:
- 团队(Group):数据资产管理和运营用户旅程中的团队参与方。
- 报表(Report):以特定格式展现数据的一种可视化报告,能直观地展现业务分析结果,用于支撑业务决策。
- 报表分组(ReportGroup):对报表的分类信息。
- 卡片(Card):报表由多个可视化组件组成,一个可视化组件称为卡片。
主要的实体联接的描述如下:
- 兼容FabricMetamodelV1.0的信息架构管理的实体联接:
- 信息架构L1-L5层元素间的实体联接:
- “属性-被包含-逻辑数据实体”:描述信息架构中L5层属性和L4层逻辑实体的关系。
- “逻辑数据实体-被包含-业务对象”:描述信息架构中L4层逻辑数据实体和L3层业务对象的关系。
- “业务对象-被包含-主题域”:描述信息架构中L3层业务对象和L2层主题域的关系。
- “主题域-被包含-主题域分组”:描述信息架构中L2层主题域和L1层主题域分组的关系。
- 信息架构和用户之间的实体联接:
- “主题域分组-关联于-团队”:描述的是信息架构委员会团队管理所有主题域分组、领域数据管家团队管理本领域主题域的场景。
- “主题域分组-被拥有-用户”:描述的是数据Owner管理主题域分组的场景。
- “主题域-被拥有-用户”:描述的是数据Owner作为主题域数据主人的场景。
- “业务对象/逻辑数据实体-被管理-用户”:描述的是数据管家管理业务对象/逻辑数据实体的场景。
- “业务对象/逻辑数据实体-被拥有-用户”:描述的是数据Owner管理业务对象/逻辑实体的场景。
- 信息架构和数据集之间的实体联接:
- “数据集-关联于-逻辑数据实体”:描述的是多个物理存在的数据集,关联到一个逻辑数据实体进行管理的场景。比如一张物理表在源业务系统、业务系统备库、数据湖、数据仓库中存在了多次,则其被注册到一个逻辑数据实体中。逻辑数据实体中的属性是从管理维度定义的最重要的数据资产属性,和数据集字段可能存在不完全一致的情况。
- “数据集-关联于-业务对象”:此关系是在未定义“逻辑数据实体”时引入的,当前已经失效,将在FabricMetamodelV2.1中删除。
- 信息架构L1-L5层元素间的实体联接:
- 兼容FabricMetamodelV1.0的数据普查的实体联接:
- 数据普查L1-L5层元素间的实体联接:
- “数据集-被包含-数据容器”:描述数据库的逻辑库(如Schema)包含多个数据集的场景。
- “数据集-被包含-数据平台实例”:描述数据集存储在哪个数据平台实例的场景。
- “数据平台实例-关联于-应用”:描述业务系统关联数据平台实例的场景。
- “应用-关联于-行政领域”:描述此业务系统是哪一个业务领域建设的场景。
- “行政领域-被包含-行政单元”:描述是业务领域是哪一级组织(如集团、分公司)的场景。
- 数据普查L1-L5层元素间的实体联接:
- 兼容FabricMetamodelV1.0的RDBMS的实体联接:
- “数据集字段-被包含-数据集”:描述的是数据集(物理表/视图)包括哪些字段的场景。
- “数据集-被包含-数据集容器”:描述的是逻辑库中包括哪些数据集(物理表/视图)的场景。
- “数据集-被包含-数据平台实例”:描述的是数据集(物理表/视图)实际存储在哪个数据平台实例的场景。
- RDBMS元模型中CWM元模型中如下元素尚未兼容:
- 唯一键
- 主键
- 外键
- 存储过程
- 索引/索引字段
- 触发器
- 分析师360中管理数据消费的实体联接:
- “空间-被拥有-用户”:描述的是空间Owner拥有工作空间的场景,当前空间中成员信息没有保存在元模型中。
- “数据集-被消费-报表”:描述的是物理表被BI报表应用所消费的场景。
- “报表-被拥有-用户”:描述的是报表是由哪个数据分析师创建、开发和发布的场景。
- “报表-被包含-报表分组”:描述的是BI报表进行分组管理的场景。
- “报表分组-被包含-工作空间”:描述的是工作空间中由数据分析师开发了多个BI报表的场景。
- 数据管家360中管理数据普查的实体联接:
- “数据集-被拥有-用户”:描述的是数据Owner作为数据集数据主人的场景。
- “数据集-被管理-用户”:描述的是数据管家作为数据集管理者的场景。
元模型详述
ABM进行元模型建模后的画布视图,其描述了所有的实体联接,并支撑如下核心功能:
- 数据普查目录:使用“用户、行政单元、行政领域、应用、数据平台实例、数据容器、数据集、数据集字段”实体。
- 数据资产目录:使用“用户、主题域分组、主题域、业务对象、逻辑数据实体、属性、数据标准、数据平台实例、数据容器、数据集、数据集字段”实体。
- 分析师360:使用“团队、用户、空间、报表、报表分组、数据集”实体。

业务类扩展
在FabricMetamodelV1.0功能的基础上,V2.0增加了业务类扩展,增加了“空间、报表、报表分组、卡片”实体,支撑了分析师360功能如下功能的实现:
- 空间Owner管理空间、报表分组。
- 数据分析师团队共享各自独立开发的报表。
- BI报表工具从数据集实体获得元数据。
当前尚未对报表中卡片的元数据实现管理,因此“卡片”实体尚未使用。
架构编码
在ABM平台对于FabricMetamodel包的编码定义如下:
- 元模型架构编码:Metamodel3。
- 架构类型:业务架构。
- 架构名称:Fabric Metamodel V2.0。
- GraphQL名称:Metamodel3。
技术模型
技术模型又称技术元数据。技术元数据是结构化处理后的数据,提供了有关数据的技术细节(字段、数据库表结构、API描述、消息描述、文件描述等),方便数据库对数据进行识别、存储、传输和交换,例如MySQL数据库技术元数据等。
业务模型
业务模型又称业务元数据。业务元数据是用于描述业务侧的元数据,主要关注数据的业务内容和业务条件,例如有哪些业务范围、业务过程、业务发生主体、业务事件,业务规则等。
数据资产信息架构
系统预置模型架构,用于管理整个企业、工厂、部门等组织的一个核心业务模型。面向业务,是数据资产清单,信息架构是公司管理信息资产的分类。
行业模板信息架构包
也可简称行业模板,是用于描述和存储特定领域总结出来具有通用意义的数据模型。“数据模型”定义数据、以及数据间的关系,通过对特定领域内的概念、实体、实体间的关系进行描述,以期得到可以在该领域内通用和泛化的数据模型。
多个行业模板构成行业模板市场,行业模板市场中的行业模板可以用户间共享。