连载:阿里巴巴大数据实践—数据建模综述

本文涉及的产品
智能数据建设与治理Dataphin,200数据处理单元
可视分析地图(DataV-Atlas),3 个项目,100M 存储空间
数据可视化DataV,5个大屏 1个月
简介: 数据模型就是数据组织和存储方法,它强调从业务、数据存取和使用角度合理存储数据。

前言:
-更多关于数智化转型、数据中台内容请加入阿里云数据中台交流群—数智俱乐部 和关注官方微信公总号(文末扫描二维码或点此加入

-阿里云数据中台官网 https://dp.alibaba.com/index

来源:数智化转型俱乐部

随着DT时代互联网、智能设备及其他信息技术的发展,数据爆发式增长,如何将这些数据进行有序、有结构地分类组织和存储是我们面临的一个挑战。

如果把数据看作图书馆里的书,我们希望看到它们在书架上分门别类地放置;如果把数据看作城市的建筑,我们希望城市规划布局合理;如果把数据看作电脑文件和文件夹,我们希望按照自己的习惯有很好的文件夹组织方式,而不是糟糕混乱的桌面,经常为找一个文件而不知所措。

数据模型就是数据组织和存储方法,它强调从业务、数据存取和使用角度合理存储数据。Linux的创始人Torvalds有一段关于“什么才是优秀程序员”的话:“烂程序员关心的是代码,好程序员关心的是数据结构和它们之间的关系”,其阐述了数据模型的重要性。有了适合业务和基础数据存储环境的模型,那么大数据就能获得以下好处。

  • 性能:良好的数据模型能帮助我们快速查询所需要的数据,减少数据的I/O吞吐。
  • 成本:良好的数据模型能极大地减少不必要的数据冗余,也能实现计算结果复用,极大地降低大数据系统中的存储和计算成本。
  • 效率:良好的数据模型能极大地改善用户使用数据的体验,提高使用数据的效率。
  • 质量:良好的数据模型能改善数据统计口径的不一致性,减少数据计算错误的可能性。

因此,毋庸置疑,大数据系统需要数据模型方法来帮助更好地组织和存储数据,以便在性能、成本、效率和质量之间取得最佳平衡。

1.关系数据库系统和数据仓库

E .F .Codd是关系数据库的鼻祖,他首次提出了数据库系统的关系模型,开创了数据库关系方法和关系数据理论的研究。随着一大批大型关系数据库商业软件(如Oracle、Informix、DB2等)的兴起,现代企业信息系统几乎都使用关系数据库来存储、加工和处理数据。数据仓库系统也不例外,大量的数据仓库系统依托强大的关系数据库能力存储和处理数据,其采用的数据模型方法也是基于关系数据库理论的。

虽然近年来大数据的存储和计算基础设施在分布式方面有了飞速的发展,NoSQL技术也曾流行一时,但是不管是Hadoop、Spark还是阿里巴巴集团的MaxCompute系统,仍然在大规模使用SQL进行数据的加工和处理,仍然在用Table存储数据,仍然在使用关系理论描述数据之间的关系,只是在大数据领域,基于其数据存取的特点在关系数据模型的范式上有了不同的选择而已。关于范式的详细说明和定义,以及其他一些关系数据库的理论是大数据领域建模的基础,有兴趣的读者可以参考相关的经典数据库理论书籍,如《数据库系统概念》。

2.从OLTP和OLAP系统的区别看模型方法论的选择

OLTP系统通常面向的主要数据操作是随机读写,主要采用满足3NF的实体关系模型存储数据,从而在事务处理中解决数据的冗余和一致性问题;而OLAP系统面向的主要数据操作是批量读写,事务处理中的一致性不是OLAP所关注的,其主要关注数据的整合,以及在一次性的复杂大数据查询和处理中的性能,因此它需要采用一些不同的数据建模方法。

3.典型的数据仓库建模方法论

ER模型

数据仓库之父Bill Inmon提出的建模方法是从全企业的高度设计一个3NF模型,用实体关系(Entity Relationship,ER)模型描述企业业务,在范式理论上符合3NF。数据仓库中的3NF与OLTP系统中的3NF的区别在于,它是站在企业角度面向主题的抽象,而不是针对某个具体业务流程的实体对象关系的抽象。其具有以下几个特点:

1)需要全面了解企业业务和数据;

2)实施周期非常长;

3)对建模人员的能力要求非常高;

采用ER模型建设数据仓库模型的出发点是整合数据,将各个系统中的数据以整个企业角度按主题进行相似性组合和合并,并进行一致性处理,为数据分析决策服务,但是并不能直接用于分析决策。其建模步骤分为三个阶段:

1)高层模型:一个高度抽象的模型,描述主要的主题以及主题间的关系,用于描述企业的业务总体概况。

2)中层模型:在高层模型的基础上,细化主题的数据项。

3)物理模型(也叫底层模型):在中层模型的基础上,考虑物理存储,同时基于性能和平台特点进行物理属性的设计,也可能做一些表的合并、分区的设计等。

ER模型在实践中最典型的代表是Teradata公司基于金融业务发布的FS-LDM(Financial Services Logical Data Model),它通过对金融业务的高度抽象和总结,将金融业务划分为10大主题,并以设计面向金融仓库模型的核心为基础,企业基于此模型做适当调整和扩展就能快速落地实施。

**维度模型
**

维度模型是数据仓库领域的Ralph Kimball大师所倡导的,他的The Data Warehouse Toolkit-The Complete Guide to Dimensional Modeling是数据仓库工程领域最流行的数据仓库建模的经典。

维度建模从分析决策的需求出发构建模型,为分析需求服务,因此它重点关注用户如何更快速地完成需求分析,同时具有较好的大规模复杂查询的响应性能。其典型的代表是星形模型,以及在一些特殊场景下使用的雪花模型。其设计分为以下几个步骤。

选择需要进行分析决策的业务过程。业务过程可以是单个业务事件,比如交易的支付、退款等;也可以是某个事件的状态,比如当前的账户余额等;还可以是一系列相关业务事件组成的业务流程,具体需要看我们分析的是某些事件发生情况,还是当前状态,或是事件流转效率。

1)选择粒度:在事件分析中,我们要预判所有分析需要细分的程度,从而决定选择的粒度。粒度是维度的一个组合。

2)识别维表:选择好粒度之后,就需要基于此粒度设计维表,包括维度属性,用于分析时进行分组和筛选。

3)选择事实:确定分析需要衡量的指标。

Data Vault模型

Data Vault是Dan Linstedt发起创建的一种模型,它是ER模型的衍生,其设计的出发点也是为了实现数据的整合,但不能直接用于数据分析决策。它强调建立一个可审计的基础数据层,也就是强调数据的历史性、可追溯性和原子性,而不要求对数据进行过度的一致性处理和整合;同时它基于主题概念将企业数据进行结构化组织,并引入了更进一步的范式处理来优化模型,以应对源系统变更的扩展性。Data Vault模型由以下几部分组成。

1)Hub:是企业的核心业务实体,由实体key、数据仓库序列代理键、装载时间、数据来源组成。

2)Link:代表Hub之间的关系。这里与ER模型最大的区别是将关系作为一个独立的单元抽象,可以提升模型的扩展性。它可以直接描述1:1、1:n和n:n的关系,而不需要做任何变更。它由Hub的代理键、装载时间、数据来源组成。

3)Satellite:是Hub的详细描述内容,一个Hub可以有多个Satellite。它由Hub的代理键、装载时间、来源类型、详细的Hub描述信息组成。

Data Vault模型比ER模型更容易设计和产出,它的ETL加工可实现配置化。通过Dan Linstedt的比喻更能理解Data Vault的核心思想:Hub可以想象成人的骨架,那么Link就是连接骨架的韧带,而Satellite就是骨架上面的血肉。看如下实例(来自Data Vault Modeling Guide,作者Hans Hultgren),如图所示。

image.png
Data Vault模型实例

Anchor模型

Anchor对Data Vault模型做了进一步规范化处理,Lars. Rönnbäck的初衷是设计一个高度可扩展的模型,其核心思想是所有的扩展只是添加而不是修改,因此将模型规范到6NF,基本变成了k-v结构化模型。我们看一下Anchor模型的组成。

1)Anchors:类似于Data Vault的Hub,代表业务实体,且只有主键。

2)Attributes:功能类似于Data Vault的Satellite,但是它更加规范化,将其全部k-v结构化,一个表只有一个Anchors的属性描述。

3)Ties:就是Anchors之间的关系,单独用表来描述,类似于Data Vault的Link,可以提升整体模型关系的扩展能力。

4)Knots:代表那些可能会在多个Anchors中公用的属性的提炼,比如性别、状态等这种枚举类型且被公用的属性。

在上述四个基本对象的基础上,又可以细划分为历史的和非历史的,其中历史的会以时间戳加多条记录的方式记录数据的变迁历史。

Anchor模型的创建者以此方式来获取极大的可扩展性,但是也会增加非常多的查询join操作。创建者的观点是,数据仓库中的分析查询只是基于一小部分字段进行的,类似于列存储结构,可以大大减少数据扫描,从而对查询性能影响较小。一些有数据表裁剪(Table Elimination)特性的数据库如MariaDB的出现,还会大量减少join操作。但是实际情况是不是如此,还有待商榷。下面是一个Anchor模型图(来自Anchor Modeling-Agile Information Modeling in Evolving Data Environments,作者Lars. Rönnbäck),如图所示。
image.png

节选自《大数据之路:阿里巴巴大数据实践》已受版权保护,未经授权不得转载

**连载1:阿里巴巴大数据实践—数据开发平台>>
连载2:阿里巴巴大数据实践—实时技术>>
连载3:阿里巴巴大数据实践—数据服务>>
连载4:阿里巴巴大数据实践—数据建模综述
连载5:阿里巴巴大数据实践—阿里巴巴的数据模型实践综述>>**


数据中台是企业数智化的新基建,阿里巴巴认为数据中台是集方法论、工具、组织于一体的,“快”、“准”、“全”、“统”、“通”的智能大数据体系。目前正通过阿里云数据中台解决方案对外输出,包括零售金融互联网政务等领域,其中核心产品有:

官方站点:
数据中台官网 https://dp.alibaba.com
数据中台钉钉群二维码2.jpg

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
2月前
|
SQL 分布式计算 运维
如何对付一个耗时6h+的ODPS任务:慢节点优化实践
本文描述了大数据处理任务(特别是涉及大量JOIN操作的任务)中遇到的性能瓶颈问题及其优化过程。
|
1月前
|
机器学习/深度学习 算法 搜索推荐
从理论到实践,Python算法复杂度分析一站式教程,助你轻松驾驭大数据挑战!
【10月更文挑战第4天】在大数据时代,算法效率至关重要。本文从理论入手,介绍时间复杂度和空间复杂度两个核心概念,并通过冒泡排序和快速排序的Python实现详细分析其复杂度。冒泡排序的时间复杂度为O(n^2),空间复杂度为O(1);快速排序平均时间复杂度为O(n log n),空间复杂度为O(log n)。文章还介绍了算法选择、分而治之及空间换时间等优化策略,帮助你在大数据挑战中游刃有余。
57 4
|
1月前
|
SQL 存储 分布式计算
ODPS技术架构深度剖析与实战指南——从零开始掌握阿里巴巴大数据处理平台的核心要义与应用技巧
【10月更文挑战第9天】ODPS是阿里巴巴推出的大数据处理平台,支持海量数据的存储与计算,适用于数据仓库、数据挖掘等场景。其核心组件涵盖数据存储、计算引擎、任务调度、资源管理和用户界面,确保数据处理的稳定、安全与高效。通过创建项目、上传数据、编写SQL或MapReduce程序,用户可轻松完成复杂的数据处理任务。示例展示了如何使用ODPS SQL查询每个用户的最早登录时间。
90 1
|
15天前
|
边缘计算 人工智能 搜索推荐
大数据与零售业:精准营销的实践
【10月更文挑战第31天】在信息化社会,大数据技术正成为推动零售业革新的重要驱动力。本文探讨了大数据在零售业中的应用,包括客户细分、个性化推荐、动态定价、营销自动化、预测性分析、忠诚度管理和社交网络洞察等方面,通过实际案例展示了大数据如何帮助商家洞悉消费者行为,优化决策,实现精准营销。同时,文章也讨论了大数据面临的挑战和未来展望。
|
1月前
|
SQL 消息中间件 分布式计算
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(一)
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(一)
71 0
|
1月前
|
SQL 大数据
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(二)
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(二)
57 0
|
1月前
|
SQL 消息中间件 分布式计算
大数据-130 - Flink CEP 详解 - CEP开发流程 与 案例实践:恶意登录检测实现
大数据-130 - Flink CEP 详解 - CEP开发流程 与 案例实践:恶意登录检测实现
40 0
|
1月前
|
存储 机器学习/深度学习 分布式计算
大数据技术——解锁数据的力量,引领未来趋势
【10月更文挑战第5天】大数据技术——解锁数据的力量,引领未来趋势
|
3天前
|
存储 分布式计算 数据挖掘
数据架构 ODPS 是什么?
数据架构 ODPS 是什么?
42 7
|
4天前
|
存储 分布式计算 大数据
大数据 优化数据读取
【11月更文挑战第4天】
14 2