数据集成的演化:从EII到Big Data

本文讲的是数据集成的演化:从EII到Big Data,“企业信息集成(EII):实用方式”于2005年发布,描述了一套集成不同数据源的方法论,它利用了当时的先进技术,如面向服务架构(SOA)、Web Services、XML、资源描述架构(RDF)、基于XML的元数据格式、数据提取、转换和加载(ETL)等。EII基本能够为关系型数据元素提供统一视角,但在性能效率上还无法替代数据仓库和多维数据库。五年之后,技术已经得到了显著提升,不仅体现在对分散数据的操作上,还体现在简化了单一容器下不同数据的整合,以及对数据深入挖掘的能力上。

  数据管理方式的技术正在向虚拟化转换,包括低成本存储、云计算、NoSQL数据库以及Hadoop等。当我们提起虚拟化时,已经远远超出为一台物理机器提供一套软件实例的概念。时至今日,我们可以对服务器、存储以及网络实现虚拟化。所有这些虚拟化意味着我们不再受这些物理条件的限制,能够迅速构建物理环境,以支持我们特定时刻的特定需求。当面对Gb、Tb、Pb等级数据量的处理需求时,我们基本能摆脱结构化的数据仓库。我们不再需要仅仅为了发掘业务的某一方面而建立特殊的环境了。

  低成本存储在业务的数据存储方面节省了开支。高昂的存储成本会使得企业寻找在有限规模的数据之上进行关键业务分析的方案,这使得如何选择最重要的数据变得十分关键,而且还限制了系统能够处理的数据的质量。负面影响是业务最终可能面临很少选择,因为无法提供足够的历史数据,从而识别一种有效关键模式。或者因为高昂的投入使得业务停止,而使用常规惯例来确定模式。

  云计算提供了一种方式,可以满足需要通过海量数据源在合理时间范围内产生结果的需求。海量数据处理需要两点:弹性存储,CPU。高速网络很有帮助,但是稍后我们会看到,软件在处理海量数据时,它并非是系统的瓶颈。弹性存储意味着企业不会在期望操作的数据规模或类型上受到限制,从而降低了使用数据仓库无法获取最佳结果的风险。更多的CPU使得结果能够在期望的时间范围内更快地被交付。

  NoSQL提供了对海量数据的支持,但与传统的关系型数据库没有关联。而且大部分NoSQL数据库是开源的,无须支付购买证书等费用。NoSQL对于表结构有着惊人的灵活性,无须随着系统的改进而不断修改完善定义。NoSQL可以支持不同数据源的合并查看,从而成为EII之后另一种备选方案,这或许是NoSQL最重要的方面了。

  NoSQL内置了数据冗余与分布式数据存储机制。海量数据的最大问题之一就是磁盘读写,NoSQL通过将数据分布至一系列节点来缓解这个问题。当发出查询请求时,这些节点能够并行查询自身节点,而不是仅仅依靠一块磁盘,一个磁盘阵列或一条网络连接,数据查询能够在节省了读写开支之后变得更加迅速。

  最终,我们来讨论Hadoop,集合了上述所有技术力量于一身、用于检测和分析数据的框架。有些人可能认为Hadoop是一项NoSQL技术,实际上Hadoop是一个分布组件的java框架,用于分解“吃大象”(此处是双关语,Hadoop是以创立者的儿子给自己的大象玩具起的名字)的工作——每次一口。

  Hadoop自身实际上与待处理数据是彼此独立的。它将大型查询任务分解为小的并行查询任务,然后收集结果,并整合出答案返回给用户。Hadoop相对于NoSQL来说是一种并行查询框架,通过云计算驱动节点,运行在低成本存储及虚拟化技术之上。

  Kickin的知识回顾

  EII第一次作为最佳实践出现于2003-2004年,那是的关键要素就是无需再移动数据了。当时大部分的数据中心仍然运行于低速网络中,有限的空间用于复制数据。之后,EII成为了当时可用技术和问题域中最优秀的解决方案。EII的某些方面的优秀即使在海量数据中也是很显著的。

  EII的优点之一就是将处理过程转移到数据所在地。海量数据方案的关键架构要素之一就是将处理过程转移到数据所在地,而不是转移数据。EII中的一条重要原则就是使用数据归属地的查询功能。这项实践就是构建靠近数据源网络的Web Service,能够建立起通用查询接口,但只针对本地数据库进行查询。我们通过开放的基于Web的接口解决了数据的专有格式的问题,从而使得多个数据子集能够迅速的整合并以统一模式展示。

  有了低成本存储和10G网络之后,我们就不必那么担心数据冗余与数据迁移,但还是有其他问题存在,数据仓库无法确保数据的原始性便是其中之一。在EII中,我们将从原始数据源获取数据视为“黄金准则”,这样就能够保证信息未被修改过,且是准确的。

  Big Data要求数据必须转移到新的物理位置,这样可信任度又成为了问题。EII的那些获取基线数据的最佳实践仍然是相关且重要的。实际上,那些为EII设计开发的Web Services接口最终在Big Data的启用中扮演主要角色。

  当然,讨论数据管理不能不涉及到安全问题。EII在安全领域中还是超过了Big Data。技术上来说,Big Data在数据集成方面更加高效与敏捷,但是大部分缺少了固有的安全性,因为在设计上会加大处理的难度。所以,可能要由源系统来担任起数据访问安全方面的责任。因为EII直接在源系统中查询数据,所以必须要求有适当的授权,否则查询就将失败。

  上述关于安全讨论描述的是内在的安全控制情况。将访问权限控制列表集成到数据库中非常合理,这将确保安全能够作为查询的一部分进行维护。然后,一旦能够直接查询NoSQL数据源,就意味着能够自由的访问你所有的数据。

  总结

  引用老的Virginia Slims的广告中的台词:“我们已经历很长的路途了,宝贝儿!”文中讨论到的技术的发展已经对21世纪第二个10年中的数据解决方案产生了巨大的影响。商业化与小型化扫除了一些思想体系上的障碍,使得架构师能够专注于问题本身,而不是寻找一些实用及可实现的问题解决方案。构建10000个节点的处理引擎,能够在数秒内处理Pb级别的数据量,而每小时只消耗几便士,这就是数据处理的美好前景。

  有了这些新工具,我们就要重新考虑如何推进数据管理。为何数据无法很好地维护整合,并且需要花费数万美元。数据管理几乎是每个大中型企业的心病。数据管理曾经在存储、管理、访问、整合以及查询上花费巨大,但是今后不再会是这样了。

  关于作者

  JP Morgenthal 是在IT策略与云计算方面的世界级专家之一。他在企业复杂问题域的解决方案实施上拥有25年的经验。JP Morgenthal以其在技术方面的深度和广度,有利的支持他在企业问题域中的敏感度。他在集成、软件开发和云计算是一位让人尊敬的作者,同时也是InfoQ在引领云计算方面的编辑,并且参与了“云计算:评估风险”项目。

  关于译者

  陈晨, 长期从事互联网信息收集分析领域架构研究。对海量数据处理,NoSQL等处理运用有丰富经验,关注过程方法及其自动化。他的新浪微博:一酌散千忧

作者:陈晨 译

来源: IT168

原文标题:数据集成的演化:从EII到Big Data

时间: 2024-08-03 05:56:42

数据集成的演化:从EII到Big Data的相关文章

Sybase操作型BI数据管理与数据集成

本文将对Sybase 操作型BI解决方案(Operational BI)进行评述,目的不是要提供一个深入的产品指南,而是对解决方案的主要特征进行概述,同时介绍Sybase是如何支持操作型BI环境的-- 数据管理服务组件 Sybase可提供操作型BI数据管理与数据集成.它不仅开发了管理BI信息的产品,还开发了数据库设计产品.Sybase IQ与Sybase PowerDesigner则是其中两个关键的产品. Sybase IQ Sybase操作型BI解决方案的基石是Sybase IQ关系型数据库系

Sybase数据集成套件介绍

如今,企业迫切希望 DBA(数据库管理员)和开发人员能够集成公司数据,以便协助管理信息.挖掘客户数据库或满足日常要求.Sybase 正借助一种称为 Sybase 数据集成 (DI) 套件的新产品来满足这种需求.此项新技术的主要功能包括: _ 访问多个不同数据源,且能够创建单一.集成的数据视图 _ 访问各种异构数据源,包括大型机数据源 _ 捕获数据源中的实时事件,并将其传播到应用程序中 _ 使用上下文搜索对结构化和非结构化数据中的信息进行搜索和查询 _ 使用 Sybase WorkSpace 开发

《大数据集成(1)》一1.2 大数据集成:挑战

1.2 大数据集成:挑战 为了更好地理解大数据集成带来的各种挑战,我们给出5个最近的案例研究,实验性地检查大数据集成中的Web数据源的各种特征,以及对这些特征自然分类的维度. "当你能度量你所说的,并能将它表示成数字,那么你就认识它一些了." --Lord Kelvin 1.2.1 "V"维度 大数据集成在多个维度上不同于传统数据集成,类似于大数据不同于传统数据库的维度. 1.海量性(Volume) 在大数据时代,不仅数据源包含大量的数据,而且数据源的数目也增长到千

[转载]数据集成之主数据管理(一)基础概念篇

问题描述 转自:http://blog.csdn.net/woohooli/archive/2009/01/07/3726040.aspx数据集成是当下比较热门的话题,相关的产品和平台也越来越多.很多CIO都在各种数据集成平台和产品之间犹豫不决.因此对数据集成平台的框架体系有全面的理解,对各个厂家产品所提供的功能有深入的认识才能为数据平台选型的决策提供可靠的保证.我有幸参与了国内一个知名企业的集成平台的设计工作,并主导了数据集成平台的需求分析和产品选型工作.这次工作中,研究了很多新的技术方向和产

《大数据集成(1)》一1.3 大数据集成:机遇

1.3 大数据集成:机遇 大数据集成不仅带来许多以"V"维度为特征的挑战,如第1.2节中我们讨论的.另外,大数据集成与管理分析大数据的基础设施也成就许多机遇,以应对这些挑战.我们主要讨论三个这样的机遇. 1.3.1 数据冗余性 从不同数据源得到的数据通常存在着部分重叠,因而导致要被集成的大量数据源之间存在巨大的数据冗余. 在我们给出的航班例子中,这一点非常清楚.例如,有关Airline1航空公司的49号航班的Departure Airport.Scheduled Departure T

《大数据集成(1)》一1.1 传统数据集成

1.1 传统数据集成 数据集成的目标是为多个自治数据源中的数据提供统一的存取.这一目标说起来容易,但实现起来已被证明异常困难,即使是针对少量几个结构化数据源,即传统的数据集成[Doan et al. 2012]. 为了理解数据集成中一些挑战性的问题,这里用一个航空领域的例子来说明.该领域的常见任务是跟踪航班的起飞和降落,检查航班时刻表以及预定航班等. 1.1.1 航班示例:数据源 我们有一些不同类型的数据源,包括:两个航空公司数据源Airline1和Airline2(如美国联合航空公司.美国航空

通用组件转换数据集成模型

通用组件转换数据集成模型 最常见的转换是那些使数据符合企业数据模型的转换.需要具体聚合和计算的转换被转移到主题领域加载,或者是转移到它们该去的地方,数据在主题领域被转换. 在企业级聚合和计算方面,通常非常少;大部分转换是针对具体主题领域的.图3.14描绘了一个通用组件转换数据集成主题领域模型示例. 图3.14 通用组件--转换数据集成模型示例. 请注意,需求沉淀层的聚合已经从通用组件模型中移除了,已经本着"把功能转移到需要的地方"这一思想转移到主题领域加载了. 物理主题领域加载数据集成

软件开发生命周期内的数据集成建模

数据集成模型遵从与软件开发生命周期中数据建模时出现的需求和设计抽象精 炼通用的级别.正如存在概念的,逻辑的和物理的数据模型,也存在概念的,逻 辑的和物理的数据集成需求,需要在软件开发生命周期的不同点进行捕获,它们 可能在流程模型中有所展现. 下面是每种模型类型的简要说明,关于角色 .步骤以及模型示例的更完整定义将会在本章的后面进行阐述. 概念数据 集成模型定义.为目标系统产生一种无需实施的数据集成需求展现,将作为确定 他们怎样能得到满足的基础. 逻辑数据集成模型定义.在数据集层面产生 详细的数据

利用流程建模进行数据集成

对于诸如数据集成这类信息技术应用,流程建模是一种经过尝试并证明可行的 方法.通过对数据集成应用流程建模技术,虚拟化和标准化的问题也会涉及到. 首先,我们来了解一下流程建模的类型吧. 利用流程建模进行数据集成 流程建模是以某种详细程度展示系统相关流程的一种手段,利用指定类型 的图表通过一系列流程展示数据流.流程建模技术通常图形化地展示具体流程, 以便更清晰地理解,交流并在设计和开发系统流程中的涉众之间进一步精细化. 流程建模不像数据建模,有几种不同的流程模型类型,它与不同的流程交 互类型有关.这些