4、数据入湖方式
数据入湖有以下5种主要技术手段。
1)批量集成(Bulk/Batch Data Movement)。对于需要进行复杂数据清理和转换且数据量较大的场景,批量集成是首选。通常,调度作业每小时或每天执行,主要包含ETL、ELT和FTP等工具。批量集成不适合低数据延迟和高灵活性的场景。
【备注说明】离线数据批量入湖场景。
2)数据复制同步(Data Replication/Data Synchronization)。适用于需要高可用性和对数据源影响小的场景。使用基于日志的CDC捕获数据变更,实时获取数据。数据复制同步不适合处理各种数据结构以及需要清理和转换复杂数据的场景。
【备注说明】基于日志捕获的增量场景。
3)消息集成(Message-Oriented Movement of Data)。通常通过API捕获或提取数据,适用于处理不同数据结构以及需要高可靠性和复杂转换的场景。尤其对于许多遗留系统、ERP和SaaS来说,消息集成是唯一的选择。消息集成不适合处理大量数据的场景。
【备注说明】API接口数据集成
4)流集成(Stream Data Integration)。主要关注流数据的采集和处理,满足数据实时集成需求,处理每秒数万甚至数十万个事件流,有时甚至数以百万计的事件流。流集成不适合需要复杂数据清理和转换的场景。
【备注说明】基于KAFKA的实时流数据集成场景
5)数据虚拟化(Data Virtualization)。对于需要低数据延迟、高灵活性和临时模式(不断变化下的模式)的消费场景,数据虚拟化是一个很好的选择。在数据虚拟化的基础上,通过共享数据访问层,分离数据源和数据湖,减少数据源变更带来的影响,同时支持数据实时消费。数据虚拟化不适合需要处理大量数据的场景。
【备注说明】数据虚拟入湖场景。只入元数据,数据不入湖。
5、结构化数据入湖
结构化数据入湖过程:
1) 数据入湖需求分析及管理:
对于规划驱动入湖场景而言,由对应的数据代表基于数据湖的建设规划,输出入湖规划清单,清单包含主题域分组、主题域、业务对象、逻辑实体、业务属性、源系统物理表和物理字段等信息。
对于需求驱动入湖场景而言,由数据消费方的业务代表提出入湖需求,并提供数据需求的业务元数据和技术元数据的信息,包括业务对象、逻辑实体、业务属性对应界面的截图。
无论是主动规划还是被动响应需求,入湖需求清单必须通过业务代表和数据代表的联合评审。当业务代表和数据代表就评审结论发生争议时,可到专业评审组织申请仲裁。
2)检查数据入湖条件和评估入湖标准:
检查数据源准备度:数据有源是数据入湖的基本前提,数据源准备度检查不仅需要源系统的IT团队提供源系统的数据字典和数据模型并检查源系统的物理表规范度,而且需要数据代表评估源系统的数据质量。
评估入湖标准:
明确数据Owner:为保证入湖数据的管理责任清晰,在数据入湖前应明确数据Owner。
发布数据标准:入湖数据应有数据标准,数据标准定义了数据属性的业务含义、业务规则等,是正确理解和使用数据的重要依据,也是业务元数据的重要组成部分。
认证数据源:原则上以初始源进湖,数据源认证是保证数据湖数据一致性和唯一性的重要措施。
定义数据密级:定义完整、明确的数据密级是数据湖数据共享、权限控制等的关键依据。信息安全管理专员向业务Owner提出定密需求,并与业务Owner确定定密规则,确定数据密级、定密时间、降密期/降密条件等,然后由信息安全管理专员在信息架构管理平台注册密级信息。
评估入湖数据质量:对入湖数据做质量评估,给入湖数据打质量标签。
3)实施数据入湖:
虚拟入湖由数据代表实施,数据代表负责设计和部署虚拟表。
物理入湖由对应数据湖的IT代表承接IT实施需求,设计集成方案和数据质量监测方案,实施数据入湖。数据代表组织UAT测试、上线验证。
4) 注册元数据:
元数据是公司的重要资产,是数据共享和消费的前提,为数据导航和数据地图建设提供关键输入。对元数据进行有效注册是实现上述目的的前提。
虚拟表部署完成后或IT实施完成后,由数据代表检查并注册元数据,元数据注册应遵循企业元数据注册规范。
【备注说明】业务、数据代表、IT代表,数据Owner 这几类数据入湖中的角色一定要搞清楚,一般在企业里面,数据入湖是由需求驱动的,比如驾驶舱指标驱动,这种情况下,业务是数据入湖的提出者,业务需要将指标的业务逻辑与数据代表传递清楚,数据代表是指理解信息系统数据的人员,一般在企业里面是指信息化相应信息系统的负责人,也就是应用架构师角色。业务和数据代表将入湖需要的材料整理后提交给信息化入湖负责人,后续入湖动作在企业里面一般是由信息化负责入湖的开发人员完成的,即所谓的IT代表。
6、非结构化数据入湖
1)非结构化数据管理的范围:
非结构化数据包括无格式的文本、各类格式的文档、图像、音频、视频等多样异构的格式文件。相较于结构化数据,非结构化数据更难以标准化和理解,因而非结构化数据的管理不仅包括文件本身,而且包括对文件的描述属性,也就是非结构化的元数据信息。
这些元数据信息包括文件对象的标题、格式、Owner等基本特征,还包括对数据内容的客观理解信息,如标签、相似性检索、相似性连接等。这些元数据信息便于用户对非结构化数据进行搜索和消费。非结构化数据的元数据实体如下图所示。
都柏林核心元数据:
是一个致力于规范Web资源体系结构的国际性元数据解决方案,它定义了一个所有Web资源都应遵循的通用核心标准。
基本特征类属性由公司进行统一管理,内容增强类属性由承担数据分析工作的项目组自行设计,但其分析结果都应由公司元数据管理平台自动采集后进行统一存储。
【备注说明】非结构化数据的管理一般也是将元数据和数据内容分开管理。
2)非结构化数据入湖的4种方式:
a)基本特征元数据入湖:
主要通过从源端集成的文档本身的基本信息入湖。入湖的过程中,数据内容仍存储在源系统,数据湖中仅存储非结构化数据的基本特征元数据。基本特征元数据入湖需同时满足如下条件:
已经设计了包含基本特征元数据的索引表。
已经设计了信息架构,如业务对象和逻辑实体。
已经定义了索引表中每笔记录对应文件的Owner、标准、密级,认证了数据源并满足质量要求。
参考都柏林核心元数据,非结构化数据的基本特征类属性元数据规范如下表所示:
【备注说明】元数据入湖。
b)文件解析内容入湖
对数据源的文件内容进行文本解析、拆分后入湖。入湖的过程中,原始文件仍存储在源系统,数据湖中仅存储解析后的内容增强元数据。内容解析入湖需同时满足如下条件:
已经确定解析后的内容对应的Owner、密级和使用的范围。
已经获取了解析前对应原始文件的基本特征元数据。
已经确定了内容解析后的存储位置,并保证至少一年内不会迁移。
c)文件关系入湖
根据知识图谱等应用案例在源端提取的文件上下文关系入湖。入湖的过程中,原始文件仍存储在源系统,数据湖中仅存储文件的关系等内容增强元数据。文件关系入湖需同时满足如下条件:
已经确定文件对应的Owner、密级和使用的范围。
已经获取了文件的基本特征元数据。
已经确定了关系实体的存储位置,并保证至少一年内不会迁移。
d)原始文件入湖
根据消费应用案例从源端把原始文件搬入湖。数据湖中存储原始文件并进行全生命周期管理。原始文件入湖需同时满足如下条件:
已经确定原始文件对应的Owner、密级和使用的范围。
已经获取了基本特征元数据。
已经确定了存储位置,并保证至少一年内不会迁移。
【备注说明】当前企业内部真正把非结构化数据管理好的企业不多,其实很多企业积累了大量的非结构化数据,比如售后维修报修的图片、热线报个的音频文件等,但如何把这些非结构化管理起来并充分利用起来挖掘数据价值,这是个很重要的问题,首先第一点要把数据统一存储管理,要进行结构化的存储管理,参考都柏林核心元数据进行管理是一个很好的方法。
三、数据主题联接
1、5类数据主题联接的应用场景
2、多维模型设计
定义:多维模型是面向业务的多视角、多维度的分析,通过明确的业务关系,建立基于事实表、维度表以及相互间联接关系,实现多维数据查询和分析。
设计步骤:
(1)确定业务场景:分析业务需求,识别需求中所涉及的业务流及其对应的逻辑数据实体和关联关系。
(2)声明粒度:粒度表示数据单元的细节程度或综合程度,细节程度越高,粒度越细;细节程度越低,粒度越粗。声明粒度是维度和事实表设计的重要步骤,声明粒度意味着精确定义事实表的每一行表示什么。
(3)维度设计。 维度是用于观察和分析业务数据的视角,支持对数据进行汇聚、钻取、切片分析,如下图所示。维度由层次结构(关系)、层级、成员、属性组成。维度可以分为基础树和组合树,维度基础树提供统一定义的、完整的层级结构和成员;维度组合树根据业务使用场景进行定制。
维度设计需要满足单一性、单向性和正交性。
单一性:有且仅有一个视角,在同一个维度中不能穿插其他经营分析的视角,例如,区域维不含客户视角,产品维不含客户视角等。下图中区域维度客户视角不满足单一性要求。
单向性:“上大下小”,维度只能支撑自上而下的分解和自下而上的收敛,每个成员只能存在向上的收敛路径,不能具备向上和向下两个方向的收敛逻辑。如下图中代表处维度低于国家维度,不满足单向性要求。
正交性:成员两两不相交,同一成员不能同时拥有多个上级成员,以产品维为例,华为向客户提供的设备或服务都只能被准确地分配到唯一叶子(最底层)节点,并以此路径进行收敛。如下图中最小粒度成员“无线专业服务”同时归属不同的上层节点,不满足正交性要求。
(4)事实表设计
事实表存储业务过程事件的性能度量结果,由粒度属性、维度属性、事实属性和其他描述属性组成,如下图所示。
粒度属性是事实表的主键,通常由原始数据的主键或一组维度属性生成。
维度属性是从维度中继承的属性,可以只继承主键作为事实表的外键,也可以继承维度中全部或其他部分的属性。在上述例子中,事实表中除了有币种ID,还可以带有币种编码和币种名称等属性。
事实属性是可以对该颗粒度的事实进行定量的属性,大多数的事实表包括一个或多个事实字段。
同一事实表中不能存在多种不同粒度的事实,比如PO行明细事实表中不应该包含PO总金额,否则PO总金额累加时会出现错误。
尽可能包含所有与业务过程相关的事实,不包含与业务过程无关的事实,比如在设计“订单下单”这个业务过程的事实表时,不应该存在“支付金额”这个支付业务过程的事实。
对于不可相加的事实,需要分解为可加的事实。比如比率,需要分解为分子和分母。
事实的数值单位要保持一致。
其他属性主要包括创建人、创建时间、最后修改人、最后修改时间等审计字段。
【备注说明】多维数据模型是面向分析OLAP的场景设计的数据模型,简单点说就是从多个不同的纬度来看业务事实,比如产品销量这个业务事实,可以分别从客户、时间、区域、产品分类等多个不同的维度去查看。华为给出了事实表和纬度表的设计原则,企业完全可以参考这些原则进行设计。
3、图模型设计
定义:图模型面向数据间的关联影响分析,通过建立数据对象以及数据实例之间的关系,帮助业务快速定位关联影响。例如,查看某国家原产地的项目的数据具体关联到哪个客户以及合同、订单、产品的详细信息时,可以通过图模型快速分析关联影响,支撑业务决策。
组成:
1)图模型由节点和边组成。节点表示实体或概念,边则由属性或关系构成。
2)实体指的是具有可区别性且独立存在的某种事物,如某一个人、某一个城市、某一种植物、某一种商品等,是图模型中的最基本元素;
3)概念是对特征的组合而形成的知识单元,主要指集合、类别、对象类型、事物的种类,例如人物、地理等;
4)属性主要指描述实体或概念的特征或特性,例如人员的国籍、生日等。
示例:
以“哲学家”为例设计图模型,如下图所示。
构建关键步骤:
1)业务场景定义:
业务场景决定信息涵盖范围,以及信息颗粒度的表示。
信息颗粒度在图模型建设中是个不可忽视的问题,根据应用场景决定信息颗粒度以及图模型的精确性与有效性。
同样的信息范围,颗粒度越细,图模型应用越广泛,关系越丰富,但冗余越多,知识消费越低效。
信息颗粒度的原则是“能满足业务应用的最粗颗粒度”。
2)信息收集:
信息的选取要考虑两个方面的内容:
与应用场景直接相关的信息。例如,判断不可抗力供应中断影响的范围,直接相关的信息有物料信息、产品配置、合同信息等。
与应用场景间接相关,但可辅助理解问题的信息。这包括企业信息、专业领域信息、行业信息以及开放域信息。
3)图建模:
相同的数据可以有若干种模式的定义,良好的模式可以减少数据冗余,提高实体识别的准确率,在建模的过程中,要结合数据特点与应用场景来完成。同样的数据从不同的视角可以得出不同的图模型。
4)实体、概念、属性、关系的标注:
企业图模型中涉及的实体和概念可分为三类:
公共类:如人名、机构名、地名、公司名、时间等
企业类:如业务术语、企业部门等
行业类:如金融行业、通信行业等
5)实体和概念的识别:
企业图模型中实体、概念的识别可将业务输入与数据资产中已有的信息作为种子,运用命名实体识别(NER)的方法扩展出新实体概念,经业务确认后,列入实体、概念库。
6)属性识别与关系识别:
企业图模型的存储技术要综合考虑应用场景、图模型中节点和联接的数量、逻辑的复杂度、属性的复杂度,以及性能要求。一般建议采用混合存储方式,用图数据库存储关系,关系型数据库或键值对存储属性。偏重逻辑推理的应用场景用RDF的存储方式,偏重图计算的应用场景选择属性图的存储方式。发挥两类数据存储和读写的各自优势。
知识计算主要是根据图谱提供的信息得到更多隐含的知识,如通过模式层以及规则推理技术可以获取数据中存在的隐含信息。知识计算涉及三大关键技术:图挖掘计算、基于本体的推理、基于规则的推理。
图挖掘计算是基于图论的相关算法,实现对图谱的探索和挖掘。图挖掘计算主要分为如下6类:
图遍历:知识图谱构建完之后可以理解为是一张很大的图,可以去查询和遍历这个图,要根据图的特点和应用场景进行遍历。
图里面经典的算法:如最短路径
路径的探寻:即根据给定两个实体或多个实体去发现它们之间的关系
权威节点的分析:这在社交网络分析中使用较多
族群分析、相似节点的发现
图模型在企业中的价值,很大程度上取决于企业基于对象节点可以构建多完善的关系,这个关系的构建是一个逐步完善的过程,基于业务场景不断补充和完善关系,这就是图模型的优势。当形成一个足够完善的企业级图模型后,领域分段的业务场景应用只需要裁剪部分节点和关系,就可以满足业务的需求,达到快速响应业务需求、降低开发成本的目的。
【备注说明】图建模的要求专业性比较强,需要专业图模型理论,企业使用图模型需要寻找需求场景,初期可以搭建开源免费的图数据库。图模型对于一些整车厂商很重要,比如一个厂商的零件出问题,如果想查询影响的整车产品,便 可以通过图模型进行快速的查询定位。