数据建模之大数据

发表: 2015-09-22 浏览: 7103

大数据

说在前面的话: 本文是鄙人学习过程中未经作者授权翻译的一份文档，原文已经附在附件中了。希望没有大的翻译错误。

作者：Jinbao Zhu: CA首席软件工程师

Allen Wang: CA经理，软件工程师

在互联网时代，我们处理的数据规模增长至TB级别乃至PB级别。随着数据规模的持续增长，由应用产生数据类型已经较从前更为丰富。因此，捕获、存储、搜索、分享、分析以及可视化数据在不断挑战传统的关系型数据库。越来越多的IT公司开始尝试用NoSQL（not only SQL）数据库去应对大数据带来的挑战, 比如Cassandra或者HBase，并且采用如Hadoop这类分布式计算机系统。NoSQL数据库是典型的key-values模式存储的，非关联性，分布式的，横向扩展以及模式自由的。

由此，我们在今天是否仍然需要数据建模呢？传统的数据建模聚焦于规划模式下的解决复杂的关系问题。但是，这些思考并不适用于于非关系型，无模式的数据库。因此，旧有的数据建模方式已经不再适用。我们需要一种新的方法论去管理大数据，以便于最大化商业价值。

大数据模型

大数据模型是一个用于管理存储于物理设备的数据的抽象层。今天，我们在全局设备上有不同格式的大量的数据。大数据模型提供了一个可视化的方式去管理数据源，并且创建基础数据架构以便于我们能够有更多的应用去优化数据重用以及减少计算成本。通常的大数据架构如下图所示：

图1

如上图所示，大数据架构共有三层。“物理数据层”保存我们在大数据系统中的数据。它可以存储不同的数据类型，例如视频，音频，日志，业务表等等。“数据模型层” 是我们创建的用于管理物理数据的抽象层。计算模型层是我们用来萃取信息获得商业价值的应用层。在这三层中，我们构建数据模型去分离数据的物理存放以及数据的使用。这意味着，应用通过数据模型去访问数据，而不是直接访问物理层。这样就使应用更加灵活，以及数据可以更方便的管理。去构筑一个大数据模型，我们必须基于数据存储，数据类型，数据关系以及读写需求等等去创建数据块。接下来，我们就必须使用建模应用去维护和管理这些模型，以使数据模型能够展现以及保存最新的数据。

混合数据模型

在过去，我们一直尝试将各种类型的数据塞进一个关系型数据库；而现在，我们必须把一些东西挪出来。

尽管采用进化了的NoSQL数据库去解决管理大数据的具体问题，但由于SQL语言的经久不衰，当前的趋势仍然是在一个数据库中支持SQL和NoSQL这两种功能。传统的关系型数据库厂商，如微软和甲骨文都在最近的发布中提供NoSQL特性的支持，比如微软SQL Server2012以及Teradata Warehouse 14的数据库列存支持。而从NoSQL这端，比如Hadoop的子项目Hive，以及CQL查询语言的Cassandra，都很快的升级去支持类SQL的语言。而Google，大数据的领导者，也在开发混合的分布式数据库，Megastore，其能在NoSQL的存储模式下的支持SQL的特性。这事不奇怪，无论数据的数量还是花样都在快速的增长，我们需要许多模型和工具去处理它。由于大数据驱动着搜集以及处理数据的变革，考虑到join处理性能下降以及数据增长给硬件存储容量处理能力带来的压力等问题的显著增多，我们需要重新审视以及思考当前数据以及存储的模型。现在有一些新的选择去解决这些问题，我们能够选择迁移大数据到NoSQL数据库，如果有可能的话，去运行一个混合的系统去折中处理，这降低了风险以及成本。

新模型工具与技术

在众多NoSQL数据库中，属性-Value导向的JSON是非常适合Key-Value数据结构，尽管XML仍有它的位置。

在大数据时代，流行的数据模型工具如Erwin采用混合模型的概念，继续帮助我们分析以及理解数据架构。与创建纯关系型模型不同，我们现在将NoSQL子模型嵌入到关系型数据模型中。通常，数据大小以及性能瓶颈是帮助我们决定哪些数据应该放到NoSQL数据库中的重要因素。

更进一步，我们能够重新设计模型。例如，我们可以逆规范化去减少对关系的依赖, 比如在ER图中从不同的实体中聚集属性到同一个实体。由于在文档中我们需要去表述原始数据的层级关系，我们需要一个好的数据表现格式去辅助理解原始数据的关系。在众多的NoSQL数据存储中，“属性-值”导向的JSON格式是很适合表述“键-值”结构，尽管XML仍有他的地位。随着表现层的变革，模型工具如CAERWin Data Modeler能够分析模式的改变，生成代码模板去建立当下RDBMS和目标NoSQL系统之间的桥梁。这能够辅助由RDBMS到NoSQL数据库的数据迁移，并且提供发布于不同数据系统的完整视图。

下图描绘了数据迁移的设计：

图2

数据迁移

NoSQL数据：

数据如果有如下特质，更适合于NoSQL系统

1. 数据规模增长快速

2. Data为列增长模式

3. 文档以及数组数据

4. 层级以及图类型数据

RDBMS数据：

数据如果有如下特性，或更适合于传统的RDBMS

5. 在线交易处理需要

6. ACID需求(原子性,一致性,隔离性,持久性)

7. 复杂的数据关系

8. 复杂的查询需求

数据消费

迁移数据远比迁移数据的消费者简单得多。一旦我们习惯使用一个混合模型去迁移数据，那些基于关系型数据库理论访问数据而设计的应用必须重新设计去适应新的数据架构。未来的混合数据库系统应该能够提供内置的迁移工具去帮助开启NoSQL的潜能，这让人们充满期待。在当下，在将既存系统迁移至NoSQL系统之前的模型重定义是至关重要的事情，模型工具需要被评估以确认满足新的需求。

物理数据感知模型

在过去的30年里，一直延用先定义后搜集的数据建模套路。采用这种办法，我们在数据进入系统之前都会事先将模型定义好。也就是说，数据如何使用决定了数据模型的定义。而在大数据环境下，这种传统的方式将不在适用，因为数据不再是固化的模式或者格式。因此，我们需要一个新的模型方法论去适应大数据的特性以及部署。

这里，我们介绍一种新的方法去管理大数据的多变性。

动态模式定义

即使对于半结构化，非结构化的大数据，我们仍然需要去定义模式，因为数据关系比从前更为复杂。在程序中去隐藏数据关系逻辑不是一个管理数据复杂性的好办法。因为大数据采用’后结构化’的办法，在大多数的情况下，我们当数据被创建以后才能知道数据的模式。本文所推荐的方法论是用于在既存数据被搜集以及存放以后去定义模式，并且使用该模式去在运行时状态下获取数据。在定义中，模式函数应该是尽可能原子化以及独立的。为了达到这个目的，我们必须找到模式函数所适用的数据范围，以及该模式幻术能够适用的数据的版本。这个就成为“动态模式”，用于区分传统的数据搜集前定义的固定模式。

如下是一个模式函数，表述了如何从一个身份证号码中获取生日和邮政编码。

图3

数据块

数据块是由元数据定义的物理数据。我们必须清楚数据的实际位置，因此我们能够在模型层为它建模，并且计算机程序知道去哪里获取它。

在如下的元数据定义中：

l 区域服务器: 数据存储的物理位置

l 数据访问路径：程序可以用其访问数据

l 数据格式：数据保存的格式

l 其他属性：当数据被适用时根据需要增加的属性

在同一个数据块中，放置具有唯一格式以及模式函数的数据，这是管理相似类型数据的一贯法则。

数据在数据块中应该被存储在相近的物理位置。比如，高概率被同时使用的数据应该在相同的挂架，或者至少相同的区域中。

数据版本

在一个实时的生产环境场景中，数据在它不同的生命周期可能有多种格式。数据模型应该管理这些版本的数据，因此模式函数能够确保可兼容的数据更新。模式函数应该是版本感知的，因此历史数据应该可以通过适当的历史版本模式函数获取得到。

数据关系

在现实世界汇总，多数据块间的数据关系仍然存在。尽管在大数据系统中大多数的数据被设计成无关系类型(也就是说，没有joins)去适用可扩展性。尽管逆规范化可以将数据多重复制，但如果数据不得不被频繁的更新，在分布式系统中会有些问题。我们需要去权衡为了扩展性而复制数据与查询性能以及特殊需求的更新处理性能。

关系是在数据块中的模式函数中定义的，关系仅仅就是数据链接。可以选用的代理应用去维护数据变化后得数据一致性。比如删除数据块或者改变数据格式。

数据计算模型

在物理数据模型的顶层，我们通常需要根据业务需求去创建数据流以及计算任务。在物理数据模型化过程中，是可以创建计算模型的，它可用来表述计算数据的逻辑路径。这可以帮助更好的设计计算任务，以及使数据重用更有效率。

Hadoop提供了一个新的分布式数据处理模型，它的HBase数据库为数据复制，备份，扩展等提供了炫酷的解决方案。Hadoop也提供了Map/Reduce的计算框架，去从分布式系统中取得数据的值。Map/Reduce是一个分解-聚合模式的并行处理框架。

随着商业的增长，计算需求变得越来越复杂。比如，一些常规的计算任务可能需要一些Map/Reduce的子任务去一些特定的商业需求。我们需要更好的设计。我们需要一个在实现复杂计算方面更好的数据流设计。重用既存的Mapper/Reducer也是使生产环境更高效的潜在的需求。

数据单元

一对Mapper和Reducer组合是计算最终产出的最小单位。一个好的设计其中一条就是要简单，因为它能够更准确的定位错误以及提供更稳定的环境。重点是，如何使Mapper以及Reducer组合独立于物理数据，以便于我们能够更好的重用这些计算单元去加速开发以及减少成本。

计算流

如下图所示，

图4

如上图所示，与其写入更大的Mapper和Reducer，还不如我们能够将既存的工作流中Mapper和Reducer合并。第一个Map-Reduce的输出就是第二个Map-Reduce的输入。整个工作流可以被可视化，并被基于如上描述的数据模型所管理。数据计算模型帮助管理基于裸格式的数据存储的计算算法，数据模型可以协助计算任务向前运转，并帮助监控数据处理的进程。同时，我们可以讲数据模型嵌入到如Hadoop这样的大数据系统之中，一旦数据被移走或者导入，Hadoop能够在第一时间与数据模型同步。

与Hive的集成

Hive创建分离的数据系统去更好的查询和计算。在Hive的表具有清晰的定义模式。我们能够反向工程去导入模式到具体的数据块中，并集成Hive数据和外部Hadoop HBase数据库中的裸数据到同一个数据模型中。如果Hive不得不从裸数据中抽取数据，并在数据挖掘过程中基于两个数据源执行计算任务时，这是很价值的基础架构。

结论

关系型数据库的复杂性限制了数据存储的扩展，但它使通过SQL引擎查询数据变得非常简单。大数据NoSQL系统具备相反的特质：无限扩展但更有限的查询能力。大数据面临的挑战是要使查询数据更容易。基于物理数据,计算路径创建数据模型去帮助管理裸数据。未来，它会提供更多的混合系统，同时，动态模式模型在设计和过程中对如Hive这类大数据系统提供了给力的支持。