数据架构简史:转换中的范式

大数据
据架构是一系列决定收集哪些数据,如何在数据库系统中使用、处理和存储数据的规则、策略以及模型。例如,数据集成是依赖于数据架构用于集成过程中的指令。如果没有从编程范式转换到数据架构范式,现代计算机将会变得更加笨拙迟钝。

[[201069]]

据架构是一系列决定收集哪些数据,如何在数据库系统中使用、处理和存储数据的规则、策略以及模型。例如,数据集成是依赖于数据架构用于集成过程中的指令。如果没有从编程范式转换到数据架构范式,现代计算机将会变得更加笨拙迟钝。

对于早期的计算机,创建过分简单化的程序是为了处理特定类型的计算机问题,甚至没有考虑过数据集成的概念,每个程序之间都是单独分开的。二十世纪四十年代至七十年代,程序处理是最主要的问题,有关建立数据架构的问题根本考虑得少之又少,甚至不在考虑的范围之内。程序员致力于让计算机通过执行特定的操作,以支持组织的短期目标。只有定义为“程序需要”的数据被使用,计算机才不会被用于长期的数据存储,恢复数据需要能够编写、检索特定信息的程序,而这相当耗费时间和金钱。

编程范式转换为数据库架构范式

1970年,Edgar F. Codd公开发表题为“大型共享数据库数据的关系模型”的论文,文中提到了组织起数据的相关步骤,Codd的理论基于运用于集合论里面的数学运算,结合了一列规则,以确保数据被存储在最小冗余里。他的方法成功的创建了数据库架构,简化了计算机的效能。在Codd的理论之前,COBOL程序和大多数其他的程序都是按等级排列的,这样的排列使得搜索有必要从总类别开始,然后再逐渐缩小搜索类别。而Codd提供的相关途径则允许用户更加有序、有效地利用二维表储存数据。(Codd 称之为“关系法”)

1976年,在麻省理工学院工作的Peter Chen发表题为“实体-关系模型对数据的统一视图”的论文,文中介绍了实体/关系建模,也就是今天被广泛熟知的“数据建模”。他以图表的形式生动形象地呈现了数据架构,两年后,Oracle宣布推出首款涉及业务的关系数据库管理系统(RDBMS)。

以计算机为工具工作的人们开始意识到数据架构比程序架构更加靠谱。它的稳定性源自重新设计系统的中间部分,并将进程彼此隔离(类似于程序员将程序隔离的方式),重新设计的关键在于添加了数据缓冲区。

缓冲区最初是一个临时记忆储存系统,旨在从原始计算机的内存中快速移除数据,这样计算机就不会陷入运阻,并能继续解决问题。 然后,数据从缓冲区传输到打印机,“慢慢”打印出最新的计算结果。今天的数据缓冲区的版本是一个由设备共享的区域,或者一个程序的进程,它们以不同的速度运行,或者有不同的优先级。现代缓冲区允许每个进程(或设备)在没有冲突的情况下运行,与缓存类似,缓冲区充当“中间存储空间”,但也有助于协调不同的活动,而不是简单地简化内存访问。

商业界很快就意识到Edgar F. Codd和Peter Chen的见解的优势,新的数据架构设计显而易见的比程序结构更快更灵活更稳定。此外,他们的见解促使计算机编程社区发生了文化上的转变,数据结构现在被认为是远比程序重要得多。

假设:数据在范式转换中丢失

数据架构的进化需要消除三个基本的假设(假设的定义:一些被认为是理所当然的事情;一种缺乏有力证据的猜测,却被当作事实来看待。)

假设1:每个程序必须和其他程序隔离开来。这种隔离论导致了程序代码、数据定义和数据条目的重复。Codd的关系法解决了不必要的副本麻烦,他的模型将数据库的模架或布局从物理信息存储中分离出来(成为数据库系统的标准)。他的关系模型指出,数据不需要存储在单独的、孤立的程序中,数据条目和程序编码不需要不必要地复制。一个单独的关系数据库足以用于存储所有的数据,所以,一致性可能(几乎可以)得到保证,并且也更易于查找错误。

假设2:输入和输出是对等的,设计上应该让他们相匹配。目前,输出和输入设备的数据处理速率有很大差异,这与预想着两者以相同速度运行的期望是完全不同的。缓冲区的使用开启了实现输出、输入的区别对待,Peter Chen的革新揭示了数据创造者和数据用户之间的差异。数据用户通常希望从潜藏在数据库下的不同部分看到大量的信息以作比较,并从中提取最有用的信息。数据创造者,从另外一方面来说,则专注于处理数据,一次一个进程。数据创造者(输入)和数据用户(输出)两者的目的是截然不同的。

假设3:企业组织应该反应在他们的计算机程序里面。随着缓冲区和关系数据库的运用,“程序”这个概念应该会逐渐模仿公司的结构,更加灵活的数据库取代了企业在提供有用结构方面的角色,同时收集和处理信息。现代数据模型既反映了企业的组织结构,也反映了用于实现目标的工具。

SQL和数据架构

Codd的关系法导致结构化的查询语言(SQL),在上世纪八十年代成为了标准的查询语言。关系数据库变得非常受欢迎,促进了数据库市场的发展,这反过来又导致了等级数据库模型的没落。

二十世纪九十年代早期,许多主要的计算机公司仍然专注于程序,试图销售昂贵而复杂的数据库产品。回以他们的则是新的、更具竞争力的企业开始发布工具和软件(如:Oracle开发人员、PowerBuilder)用来增强系统数据架构。二十世纪九十年代中期,互联网的使用推进了数据库行业的显著增长以及计算机的总体销售情况。

数据库架构性的设计,引领了数据管理的蓬勃发展。企业已经发现了信息本身对公司的价值,二十世纪九十年代以后,诸如“数据管理员”、“数据库管理员”的标题开始出现。数据管理员的职责在于保证数据使用中的高质量和完整性。

关系数据库管理系统使创建一个呈现概念模式(某种类型的映射)的数据库成为可能,然后提供数据库的不同透视图,这是为数据创建者和数据使用者设计的。另外,每个数据库管理系统都可以将其物理存储参数与列结构和表分开。

NoSQL和数据架构

NoSQL不是一个程序,它是一个数据库管理系统,使用的是相当简单的架构。在处理大数据和不需要关系模型时,它是很有用的。NoSQL数据库系统在管理和存储数据的方法和过程中是非常多样化的。SQL系统在功能方面通常比NoSQL系统具有更大的灵活性,但是缺乏NoSQL系统的可伸缩性。但是,现在有许多商业软件包可以结合“两个世界的最佳方式”,而且更多的软件包将会一直进入市场。

最近,一些机构组织在DATAVERSITY的文章和访谈中(还有许多其他的可能性)提供了一种数据架构解决方案,利用关系数据库中常见的工具来处理大数据。Kyvos Insights公司销售与hadoop存储系统兼容的软件,它们的“Hadoop/OLAP ”组合在不同程度上促进了非结构化和结构化数据的处理,使得人们可以相对轻松地对大数据进行分析。

Hackolade公司也销售一款软件包,采用一种用户友好数据模型提供了“高功能”的工具来处理NoSQL。该软件将NoSQL融合了可视化图形的简明性,结合Hackolade其他工具一起使用,既减少开发时间,又提高了应用程序的质量。他们的软件目前和Couchbase、DynamoDB、MongoDB 模式兼容(他们计划未来能囊括更多NoSQL数据库)。

RedisLabs将他们的云计算与他们的软件包Redis Pack结合在一起,提供另一个架构解决方案。Redis Pack和它的云计算提供了三种优势:速度、持久性(保存您的信息),以及他们提供的数据类型的多样性。从本质上来说,Redis是一个“非常快”的NoSQL、键值数据存储,同时可以充当数据库、缓存和消息代理。

Reltio提供服务。他们已经创建了一个云管理平台,并提供完成处理大数据所需的工具和服务。他们提供研究人员,将来自多个来源的大数据与主数据管理(MDM)合并在一起,并开发统一的目标。Reltio的系统支持多种行业领域,包括零售、生命科学、娱乐、医疗保健和政府。

数据架构从早期就完全改变了,并且很可能是由于一些新的趋势,例如物联网、云计算、微服务、高级分析、机器学习和人工智能,以及像Blockchain这样的新兴技术,将会继续改变未来的发展方向。 

责任编辑:庞桂玉 来源: 36大数据
相关推荐

2018-04-24 07:35:51

2020-10-29 07:09:07

编程花括号程序员

2011-04-15 11:29:31

数据库设计

2013-03-04 15:04:16

2021-09-01 09:52:52

路由器计算机架构

2017-07-19 08:30:31

2017-06-15 14:16:39

2023-03-05 20:28:49

数据数据集架构

2023-09-13 10:48:40

2022-10-27 20:42:04

JavaScripJava编程语言

2013-02-20 09:33:07

PythonWeb

2011-04-14 14:43:38

SSISTransformat

2024-09-29 17:52:16

数据飞轮数据中台数字化转型

2017-03-03 15:23:46

数据库设计范式

2024-12-09 12:00:00

Python编程数据类型转换

2021-08-30 11:48:26

数字化

2011-11-03 15:55:40

Windows Pho

2018-03-22 12:31:40

2023-07-12 17:13:40

数据中心综合布线

2024-08-12 10:00:31

点赞
收藏

51CTO技术栈公众号