大数据之路_模型篇

• 一.为什么需要数据建模
  数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。
   Linux 的创始人 Torva lds 一段关于“什么才是优秀程序员”的话：“烂程序员关心的是代码，好程序员关心的是数据结构和它们之间的关系”，其阐述了数据模型的重要性。有了适合业务和基础数据存储环境的模型，那么大数据就能获得以下好处。
  • 性能 ：良好的数据模型能帮助我们快速查询所需要的数据，减少数据的吞吐。
  • 成本: 良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低大数据系统中的存储和计算成本。
  • 效率 ：良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率。
  • 质量 :良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。
  因此，毋庸置疑，大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡。
   
  二.关系数据库系统和数据仓库
  大量的数据仓库系统依托强大的关系数据库能力存储和处理数据，其采用的数据模型方法也是基于关系数据库理论的。虽然近年来大数据的存储和计算基础设施在分布式方面有了飞速的发展，NoSQL 技术也曾流行一时，但是不管是 Hadoop Spark 还是阿里巴巴集团的 MaxCompute 系统，仍然在大规模使用 SQL 进行数据的加工和处理，仍然在用 Table 存储数据，仍然在使用关系理论描述数据之间的关系 ，只是在大数据领域，基于其数据存取的特点在关系数据模型的范式上有了不同 的选择而已。
   
  三.OLTP OLAP 系统的区别看模型万法论的选择
  OLTP 系统通常面向的主要数据操作是随机读写，主要采用满足3NF 实体关系模型存储数据，从而在事务处理中解决数据的冗余和一致性问题。而 OLAP 系统面向的主要数据操作是批量读写，事务处理中的一致性不是 OLAP 关注的，其主要关注数据的整合，以及在一次性的复杂大数据查询和处理中的性能，因此它需要采用一些不同的数据建模方法。
   
  四.典型的数据仓库建模方法论
  ER 模型
  采用 模型建设数据仓库模型的出发点是整合数据，将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性处理，为数据分析决策服务，但是并不能直接用于分析决策。
  其建模步骤分为三个阶段。
  高层模型：一个高度抽象的模型，描述主要的主题以及主题间的关系，用于描述企业的业务总体概况。
  中层模型：在高层模型的基础上，细化主题的数据项。
  物理模型（也叫底层模型）：在中层模型的基础上，考虑物理存储，同时基于性能和平台特点进行物理属性的设计，也可能做一些表的合并、分区的设计等。
  ER 模型在实践中最典型的代表是 Teradata 公司基于金融业务发布的FS-LDM (Financial Services Logical Data Model ），它通过对金融业务的高度抽象和总结，将金融业务划分为 10 主题 ，并以设计面向金融仓库模型的核心为基础，企业基于此模型做适当调整和扩展就能快速落地实施。
   
  维度模型
  维度模型是数据仓库领域的 Ralph Kimball 大师所倡导的，他的 The Data rehouse olkit-The Complete Guide to Dimensional Modeling是数据仓库工程领域最流行的数据仓库建模的经典。
  维度建模从分析决策的需求出发构建模型，为分析需求服务，因此它重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。其典型的代表是星形模型，以及在一些特殊场景下使用的雪花模型。其设计分为以下几个步骤。
  • 选择需要进行分析决策的业务过程。业务过程可以是单个业务事件，比如交易的支付、退款等；也可以是某个事件的状态，比如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。
  • 选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。
  • 识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。
  • 选择事实。确定分析需要衡量的指标。
   
  Data Vault 模型
  Data Vault Dan Linstedt 发起创建的一种模型，它是 模型的衍生，其设计的出发点也是为了实现数据的整合，但不能直接用于数据分析决策。它强调建立一个可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合同时它基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型，以应对源系统变更的扩展性。 Data Vault 型由以下几部分组成。
   
  • Hub ：是企业的核心业务实体，由 实体 key 、数据仓库序列代理键、装载时间、数据来源组成。
  • Link ：代表 Hub 之间的关系。这里与 模型最大的区别是将关系作为一个独立的单元抽象，可以提升模型的扩展性。它可以直接描述 1:n n:n 的关系，而不需要做任何变更。它由 Hub的代理键、装载时间、数据来源组成。
  • Satellite ：是 Hub 的详细描述内容， 一个 ub 可以有多个 Satellite.它由 Hub 的代理键、装载时间、来源类型、详细的 Hub 描述信息组成。
  • Data Vault 模型比 ER 模型更容易设计和产出，它的 ETL 加工可实现配置化。通过 Dan Linstedt 的比喻更能理解 Data Vault 的核心思想：Hub 可以想象成人的骨架，那么 Link 就是连接骨架的韧带，而 Satellite就是骨架上面的血肉。
   
  Anchor 模型
  Anchor Data Vault 模型做了进一步规范化处理，其核心思想是所有的扩展只是添加而不是修改，因此将模型规范到 6NF ，基本变成了 k-v 结构化模型。看 Anchor 模型的组成。
• Anchors ：类似于 Data Vault Hub ，代表业务实体，且只有主键。
• Attributes ：功能类似于 Data Vault Satellite ，但是它更加规范化，将其全部 k-v 结构化， 个表只有 Anchors 的属性描述。
• Ties ：就是 Anchors 之间的关系，单独用表来描述，类似于 DataVault Link ，可以提升整体模型关系的扩展能力。
• Knots ：代表那些可能会在 Anchors 中公用的属性的提炼，比如性别、状态等这种枚举类型且被公用的属性。

Anchor 模型的创建者以此方式来获取极大的可扩展性，但是也会增加非常多的查询 join 操作。创建者的观点是，数据仓库中的分析查询只是基于一小部分字段进行的，类似于列存储结构，可以大大减少数据扫描，从而对查询性能影响较小。