随着DT时代互联网、智能设备和其他信息技术的发展，数据急剧增长。 如何组织、从结构上分类、组织和存储这些数据是一个挑战。
如果把数据看作图书馆的书，为什么需要数据建模；如果把想看到书架上分别放置的数据看作城市建筑，希望城市规划布局合理； 如果把数据当成电脑上的文件和文件夹，我们就想按照自己的习惯好好整理文件夹，而不是糟糕的混乱桌面。 我经常对查找文件感到困惑。
数据模型是一种组织和存储数据的方法，强调从业务、数据访问和使用角度正确存储数据。 Linux的创始人Torvalds就“什么是优秀的程序员”一词表示：“腐朽的程序员关心代码，好的程序员关心数据结构及其关系。”并阐述了数据模型的重要性。 如果有适合业务和基本数据存储环境的模型，大数据将有以下好处：
性能—良好的数据模型有助于快速查询所需的数据，并降低数据的I/O吞吐量。 成本：良好的数据模型可以大大降低不必要的数据冗馀，实现计算结果的复用，大大降低大数据系统中的存储和计算成本。 效率：良好的数据模型可以大大改善用户使用数据的体验，提高数据的使用效率。 质量：良好的数据模型可以改善数据统计口径的不一致性，减少数据计算错误的可能性。 因此，大数据系统当然需要一种数据模型方法来更好地组织和存储数据，以优化性能、成本、效率和质量之间的平衡。
关系数据库系统和数据仓库E .F .Codd是关系数据库的鼻祖，他首次提出了数据库系统的关系模型，开始了数据库关系方法和关系数据理论的研究。 随着Oracle、Informix和DB2等大型关系数据库业务软件的兴起，现代企业信息系统大多使用关系数据库来存储、加工和处理数据。 数据仓库系统也不例外，大量的数据仓库系统基于强大的关系数据库能力存储和处理数据，其采用的数据模型方法也基于关系数据库理论。 近年来，大数据存储和计算基础架构在分布式方面发展迅速，NoSQL技术也曾风行一时，但无论是Hadoop、Spark还是阿里巴巴集团的MaxCompute系统，仍然大规模地使用SQL 虽然仍然用Table保存数据，并仍然用关系理论描述数据之间的关系，但在大数据领域，基于该数据访问特征的范例的详细说明和定义，以及其他关系数据库理论都是大数据领域的建模
从OLTP系统和OLAP系统的区别来看，模型方法论的选择OLTP系统通常面向的主要数据操作是随机读写，主要采用满足3NF的实体关系模型来存储数据，从而在事务处理中实现数据冗馀和一致性另一方面，由于OLAP系统面向的主要数据操作是批量读写，事务中的一致性不是OLAP关注的问题，而是主要关注数据集成，以及一次性复杂大数据查询和处理过程中的性能，因此有几种不同的数据建模方法
典型的数据仓库建模方法论ER模型
数据仓库之父Bill Inmon提出的建模方法是从整个企业的高度设计3NF模型，用实体关系(Entity Relationship，ER )模型描述企业业务，在范式理论上符合3NF。 数据仓库中的3NF和OLTP系统中的3NF的区别在于，它们是以企业为视角的面向主题的抽象，而不是对特定业务流程的物理对象关系的抽象。 它具有以下特点：
有必要全面了解企业的业务和数据。 实施周期非常长。 对建模者的能力要求非常高。 用ER模型建设数据仓库模型的出发点是整合数据，将各系统的数据从整个企业的角度按主题进行相似性组合和整合，进行一致性处理，为数据分析决策提供服务，但不能直接用于分析决策
其建模步骤分为三个阶段。
高级模型：描述主要主题和主题之间关系的高度抽象模型。 用于概述企业的整个业务。 中间层模型：基于高层模型细分主题数据项。 物理模型(也称为基础模型) :基于中间层模型，根据性能和平台特征进行物理属性设计，同时考虑物理存储。 另外，有时也进行几个表的合并、分区的设计等。 实践中ER模式最典型的代表是Teradata公司基于金融业务发布的金融服务逻辑数据模型(fs-LDM )，通过对金融业务的高度抽象和总结，将金融业务分为10个主题，金融仓库
维度模型
维度模型由数据仓库领域的Ralph Kimball大师提出，他的thedatawarehousetoolkit-thecompleteguidetodimensionalmodeling是数据仓库工程领域最受欢迎的
维度建模从分析决策需求开始构建模型，为分析需求提供服务，因此侧重于用户如何快速完成需求分析，同时提高大型复杂查询的响应能力。 其代表性的是星形模型和在一些特殊场景中使用的雪花模型。 其设计分为以下步骤。
选择需要分析决策的业务流程。 业务流程可以是单个业务事件，例如交易支付、退款等； 一个事件的状态可以是当前帐户馀额等，也可以是由一系列相关业务事件组成的业务流程，具体要看我们
分析的是某些事件发生情况，还是当前状态，或是事件流转效率。选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。选择事实。确定分析需要衡量的指标。Data Vault模型
Data Vault是Dan Linstedt发起创建的一种模型，它是ER模型的衍生，其设计的出发点也是为了实现数据的整合，但不能直接用于数据分析决策。它强调建立一个可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合；同时它基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型，以应对源系统变更的扩展性。Data Vault模型由以下几部分组成。
Hub：是企业的核心业务实体，由实体key、数据仓库序列代理键、装载时间、数据来源组成。Link：代表Hub之间的关系。这里与ER模型最大的区别是将关系作为一个独立的单元抽象，可以提升模型的扩展性。它可以直接描述1:1、1:n和n:n的关系，而不需要做任何变更。它由Hub的代理键、装载时间、数据来源组成。Satellite：是Hub的详细描述内容，一个Hub可以有多个Satellite。它由Hub的代理键、装载时间、来源类型、详细的Hub描述信息组成。Data Vault模型比ER模型更容易设计和产出，它的ETL加工可实现配置化。通过Dan Linstedt的比喻更能理解Data Vault的核心思想：Hub可以想象成人的骨架，那么Link就是连接骨架的韧带，而Satellite就是骨架上面的血肉。看如下实例（来自Data Vault Modeling Guide，作者危机的白云 Hultgren），如图1所示。
图1 Data Vault模型实例
Anchor模型
Anchor对Data Vault模型做了进一步规范化处理，Lars. Rönnbäck的初衷是设计一个高度可扩展的模型，其核心思想是所有的扩展只是添加而不是修改，因此将模型规范到6NF，基本变成了k-v结构化模型。我们看一下Anchor模型的组成。
Anchors：类似于Data Vault的Hub，代表业务实体，且只有主键。Attributes：功能类似于Data Vault的Satellite，但是它更加规范化，将其全部k-v结构化，一个表只有一个Anchors的属性描述。Ties：就是Anchors之间的关系，单独用表来描述，类似于Data Vault的Link，可以提升整体模型关系的扩展能力。Knots：代表那些可能会在多个Anchors中公用的属性的提炼，比如性别、状态等这种枚举类型且被公用的属性。在上述四个基本对象的基础上，又可以细划分为历史的和非历史的，其中历史的会以时间戳加多条记录的方式记录数据的变迁历史。
Anchor模型的创建者以此方式来获取极大的可扩展性，但是也会增加非常多的查询join操作。创建者的观点是，数据仓库中的分析查询只是基于一小部分字段进行的，类似于列存储结构，可以大大减少数据扫描，从而对查询性能影响较小。一些有数据表裁剪（Table Elimination）特性的数据库如MariaDB的出现，还会大量减少join操作。但是实际情况是不是如此，还有待商榷。下面是一个Anchor模型图（来自Anchor Modeling-Agile Information Modeling in Evolving Data Environments，作者Lars. Rönnbäck），如图2所示。
图2 Anchor模型图
阿里巴巴数据模型实践综述
阿里巴巴集团很早就已经把大数据作为其战略目标实施，而且其各个业务也非常依赖数据支撑运营，那么阿里巴巴究竟采取何种方法构建自己的数据仓库模型呢？阿里巴巴的数据仓库模型建设经历了多个发展阶段。
第一个阶段：完全应用驱动的时代，阿里巴巴的第一代数据仓库系统构建在Oracle上，数据完全以满足报表需求为目的，将数据以与源结构相同的方式同步到Oracle（称作ODS层），数据工程师基于ODS数据进行统计，基本没有系统化的模型方法体系，完全基于对Oracle数据库特性的利用进行数据存储和加工，部分采用一些维度建模的缓慢变化维方式进行历史数据处理。这时候的数据架构只有两层，即ODS+DSS。
第二个阶段：随着阿里巴巴业务的快速发展，数据量也在飞速增长，性能成为一个较大的问题，因此引入了当时MPP架构体系的Greenplum，同时阿里巴巴的数据团队也在着手进行一定的数据架构优化，希望通过一些模型技术改变烟囱式的开发模型，消除一些冗余，提升数据的一致性。来自传统行业的数据仓库工程师开始尝试将工程领域比较流行的ER模型+维度模型方式应用到阿里巴巴集团，构建出一个四层的模型架构，即ODL（操作数据层）+BDL（基础数据层）+IDL（接口数据层）+ADL（应用数据层）。ODL和源系统保持一致；BDL希望引入ER模型，加强数据的整合，构建一致的基础数据模型；IDL基于维度模型方法构建集市层；ADL完成应用的个性化和基于展现需求的数据组装。在此期间，我们在构建ER模型时遇到了比较大的困难和挑战，互联网业务的快速发展、人员的快速变化、业务知识功底的不够全面，导致ER模型设计迟迟不能产出。至此，我们也得到了一个经验：在不太成熟、快速变化的业务面前，构建ER模型的风险非常大，不太适合去构建ER模型。
第三个阶段：阿里巴巴集团的业务和数据还在飞速发展，这时候迎来了以Hadoop为代表的分布式存储计算平台的快速发展，同时阿里巴巴集团自主研发的分布式计算平台MaxCompute也在紧锣密鼓地进行着。我们在拥抱分布式计算平台的同时，也开始建设自己的第三代模型架构，这时候需要找到既适合阿里巴巴集团业务发展，又能充分利用分布式计算平台能力的数据模型方式。我们选择了以Kimball的维度建模为核心理念的模型方法论，同时对其进行了一定的升级和扩展，构建了阿里巴巴集团的公共层模型数据架构体系。
数据公共层建设的目的是着力解决数据存储和计算的共享问题。阿里巴巴集团当下已经发展为多个BU，各个业务产生庞大的数据，并且数据每年以近2.5倍的速度在增长，数据的增长远远超过业务的增长，带来的成本开销也是非常令人担忧的。
阿里巴巴数据公共层建设的指导方法是一套统一化的集团数据整合及管理的方法体系（在内部这一体系称为“OneData”），其包括一致性的指标定义体系、模型设计方法体系以及配套工具。
本文节选自《大数据之路：阿里巴巴大数据实践》一书，阿里巴巴数据技术及产品部所著。
在阿里巴巴集团内，数据人员面临的现实情况是：集团数据存储已经达到EB级别，部分单张表每天的数据记录数高达几千亿条；在2016年“双11购物狂欢节”的24小时中，支付金额达到了1207亿元人民币，支付峰值高达12万笔/秒，下单峰值达17.5万笔/秒，媒体直播大屏处理的总数据量高达百亿级别且所有数据都需要做到实时、准确地对外披露……巨大的信息量给数据采集、存储和计算都带来了极大的挑战。《大数据之路：阿里巴巴大数据实践》就是在此背景下完成的。相信《大数据之路：阿里巴巴大数据实践》中的实践和思考对同行会有很大的启发和借鉴意义。
小福利：关注CSDN大数据微信公众号，并在最新一条《阿里巴巴大数据实践之数据建模》下留言，就有机会获赠本书哦。
更多精彩，欢迎关注CSDN大数据公众号！