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

简介:

本节书摘来自华章出版社《大数据集成(1)》一书中的第1章,第1.1节,作者 [美] 董欣(Xin Luna Dong)戴夫士·斯里瓦斯塔瓦(Divesh Srivastava),更多章节内容可以访问云栖社区“华章计算机”公众号查看

1.1 传统数据集成

  数据集成的目标是为多个自治数据源中的数据提供统一的存取。这一目标说起来容易,但实现起来已被证明异常困难,即使是针对少量几个结构化数据源,即传统的数据集成[Doan et al. 2012]。
  为了理解数据集成中一些挑战性的问题,这里用一个航空领域的例子来说明。该领域的常见任务是跟踪航班的起飞和降落,检查航班时刻表以及预定航班等。

1.1.1 航班示例:数据源

  我们有一些不同类型的数据源,包括:两个航空公司数据源Airline1和Airline2(如美国联合航空公司、美国航空公司、达美等),分别提供自家航空公司航班的信息;一个机场数据源Airport3,提供在某机场(如EWR、SFO)出发和到达航班的信息;以及一个旅行数据源Airfare4(如Kayak、Orbitz等),提供不同航班不同价位的票价信息;还有一个信息类数据源Airinfo5(如Wikipedia table),提供有关机场和航空公司的数据。
  各数据源的样例数据如表1-1~表1-8所示。为简便起见,表中使用缩写的属性名,属性名的缩写和全称的对应关系见表1-9。下面解释各表的具体内容。
  1.数据源Airline1
  数据源Airline1提供两张关系表Airline1.Schedule(Flight Id, Flight Number, Start Date, End Date, Departure Time, Departure Airport, Arrival Time, Arrival Airport)和Airline1.Flight(Flight Id, Departure Date, Departure Time, Departure Gate, Arrival Date, Arrival Time, Arrival Gate, Plane Id)。加下划线的属性构成相应表的主键。Flight Id被用作两张表的连接键。
  关系表Airline1.Schedule如表1-1所示,显示了航班的时间计划表。例如,Airline1.Schedule中的记录r11说明Airline1航空公司的49号航班在2013-10-01到2014-03-31期间,固定从EWR飞往SFO,起飞时间18:05,到达时间21:10。记录r12显示同一航班在2014-04-01到2014-09-30期间安排了另外的起飞降落时间。记录r13和r14分别显示了55号航班在2013-10-01到2014-09-30期间两个飞行段的安排,第一段从ORD飞到BOS,第二段从BOS飞到EWR。
  关系表Airline1.Flight如表1-2所示,显示了Airline1.Schedule中航班的实际起飞和到达信息。例如,Airline1.Flight中的r21记录了对应于r11(FI等于123,为两者的连接键)的航班的一次具体的飞行,即PI(飞机号)为4013的飞机,实际于2013-12-21的18:45(比计划的时间18:05晚40分钟)从C98登机口起飞,并于2013-12-21的21:30(比计划的时间21:10晚20分钟)降落在81号登机口。记录r11和r21都用浅灰高亮显示以表示它们的关系。同一张表中的记录r22记录了航班r11的另外一次实际飞行,比计划的起飞降落时间有更大的延迟。记录r23和r24记录的是2013-12-29航班r13和r14的飞行信息。
image

2.数据源Airline2
  数据源Airline2提供的信息类似于数据源Airline1,但是使用的是关系表Airline2.Flight(Flight Number, Departure Airport, Scheduled Departure Date, Scheduled Departure Time, Actual Departure Time, Arrival Airport, Scheduled Arrival Date, Scheduled Arrival Time, Actual Arrival Time)。
  关系表Airline2.Flight如表1-3所示,包含计划的和实际的航班信息。例如,记录r31记录了Airline2航空公司的53号航班计划2013-12-21的15:30从SFO起飞,但实际延迟30分钟,计划2013-12-21的23:35抵达EWR,但实际晚点了40分钟,第二天(表中显示+1d)即2013-12-22到达。注意表中有一条关于Airline2航空公司49号航班的记录r35,它不同于Ailine1航空公司的49号航班。这表明不同航空公司可以使用相同的航班号。
  不同于数据源Airline1,数据源Airline2没有发布出发登机口和到达登机口以及飞机号。这表明这些数据源的模式之间是有差异的。
image

3.数据源Airport3
  数据源Airport3提供两张关系表Airport3.Departures(Air Line, Flight Number, Scheduled, Actual, Gate Time, Takeoff Time, Terminal, Gate, Runway)和Airport3.Arrivals(Air Line, Flight Number, Scheduled, Actual, Gate Time, Landing Time, Terminal, Gate, Runway)。
  关系表Airport3.Departures如表1-4所示,仅发布了从EWR机场起飞的航班。例如,表中的记录r41记录了Airline1航空公司的49号航班,计划在2013-12-21的18:45从航站楼C的98号登机口出发,18:53从跑道2起飞。表中没有该航班的到达机场、到达日期和时间的信息。注意r41对应于记录r11和r21,同样用浅灰高亮显示。
image
 关系表Airport3.Arrivals如表1-5所示,仅发布了到达EWR机场的航班。例如,表中的记录r51记录了Airline2航空公司的53号航班,计划2013-12-21到达,实际2013-12-22到达,于00:15在跑道2降落,00:21抵达航站楼B的53号登机口。表中没有该航班的出发机场、出发日期和时间。注意r51对应于记录r31。
image

  不同于数据源Airline1和Airline2,数据源Airport3区分开航班离开/到达登机口的时间和在机场跑道上起飞/降落的时间。
  4.数据源Airfare4
  旅行数据源Airfare4发布对不同航空公司售票信息的比较,包括航班的时间计划Airfare4.Flight(Flight Id, Flight Number, Departure Airport, Departure Date, Departure Time, Arrival Airport, Arrival Time)以及机票价格Airfare4.Fares(Flight Id, Fare Class, Fare)。Flight Id被用作两表的连接键。
  例如,如表1-6所示,Airfare4.Flight中的记录r61显示Airline1航空公司的航班A1-49计划于2013-12-21的18:05从Newark Liberty机场出发,并于当天的21:10抵达San Franciso机场。注意r61对应于记录r11、r21和r41。
  关系表Airfare4.Fares中的记录如表1-7所示,给出了该航班的各类票价。例如,记录r71显示该航班的A类票价是$5799.00;FI456是连接键。
image
5.数据源Airinfo5
  数据源Airinfo5发布的是关于机场和航空公司的信息,即关系表Airinfo5.AirportCodes(Airport Code, Airport Name)和Airinfo5.AirlineCodes(Air Line Code, Air Line Name)。
  例如,如表1-8所示,Airinfo5.AirportCodes中的记录r81显示代号为EWR的机场是美国新泽西州的Newark Liberty机场。类似地,Airinfo5.AirlineCodes的记录r91显示代号为A1的航空公司是Airline1航空公司。
image
image

1.1.2 航班示例:数据集成

  虽然5个数据源单独都是有用的,但当它们被集成在一起时,这些数据的价值将被大大提升。
  1.集成数据源
  首先,每个航空公司数据源(如Airline1、Airline2)都从与机场数据源Airport3的链接中获益,因为机场数据源提供了航班实际出发和到达的详细信息,如登机时间、起飞降落的时间和使用的跑道;这些可以帮助航空公司更好地分析航班延误的原因。其次,机场数据源Airport3也可以从与航空公司数据源(如Airline1、Airline2)的链接中获益,因为航空公司数据源提供了关于航班时刻表和整体飞行计划的详细信息(尤其是对那些多段飞行的航班,如Airline1的55号航班);这些可以帮助机场更好地理解航班的飞行模式。第三,旅行数据源Airfare4可以通过链接航空公司数据源和机场数据源提供一些附加信息,例如历史上准点起飞/到达的统计数据等;而这些信息对预定航班的用户可能非常有用。这种关联使得信息源Airinfo5非常关键。这一点我们在后面会看到。最后,将所有这些不同数据源集成起来也会使用户获益,因为他们不需要分别去访问多个数据源才能获得自己想要的信息。
  例如,查询“计算出上个月每个航班的计划和实际出发时间之间的平均延迟,以及实际登机和起飞时间之间的平均延迟”可以在集成起来的数据库上作答,却无法用任一单个的数据源回答。
  然而,集成多个自治的数据源非常困难,经常需要大量人工的努力去理解每个数据源的数据语义以解决歧义性问题。让我们再一次看一下航班的示例。
  2.语义歧义性
  为了正确对齐各种数据源表,我们需要理解:i)同一概念信息在不同数据源中的表示可能非常不同;ii)不同概念信息在不同数据源中的表示可能很相似。
  例如,数据源Airline1在表Airline1.Schedule中给出在一定日期范围内(由Start Date和End Date所指定)的航班时刻表,使用属性Departure Time和Arrival Time记录时间信息。然而,数据源Airline2在表Airline2.Flight中一起给出了航班时刻表和实际航班的飞行信息,每次不同的飞行用不同的记录描述,并且使用不同的属性名称,Scheduled Departure Date,Scheduled Departure Time,Scheduled Arrival Date,Scheduled Arrival Time。
  又如,数据源Airport3既记录了航班的实际登机口出发/到达时间(表Airport3.Departures和表Airport3.Arrivals中的Gate Time),也记录了实际起飞/降落时间(表Airport3.Departures中的Takeoff Time和表Airport3.Arrivals中的Landing Time)。而Airline1和Airline2数据源只记录其中一种时间,具体地,仔细检查数据就会发现,数据源Airline1记录的是登机口出发/到达时间(表Airline1.Schedule和Airline1.Flight中的Departure Time和Arrival Time),而Airline2记录的是起飞/降落时间(表Airline2.Flight中的Scheduled Departure Time,Actual Departure Time,Scheduled Arrival Time,Actual Arrival Time)。
  不同的概念信息表示得很相似,如属性Departure Date在数据源Airline1中表示实际出发日期(在表Airline1.Flight中),但是在数据源Airfare4中表示计划的出发日期(在表Airfare4.Flight中)。
  3.实例表示歧义性
  要将来自多个数据源的同一个数据实例关联在一起,我们需要意识到由于数据源的自治性,这些数据实例具有不同的表示形式。
  例如,航班号在数据源Airline1和Airline2中被表示为数字(例如,r11中的49,r31中的53),在数据源Airfare4中被表示为数字和字母的组合(如,r61中的A1-49)。类似地,出发和到达机场在数据源Airline1和Airline2中被表示为三字母的编码(如EWR、SFO、LAX),但在Airfare4.Flight表中被表示为一个描述性的字符串(如Newark Liberty,San Francisco)。由于航班是由属性组合(Airline, Flight Number, Departure Airport, Departure Date)所唯一标识的,如果没有另外一张表(例如表1-8中的Airinfo5.AirlineCodes和Airinfo5.AirportCodes表)将航空公司编码和机场编码分别和它们描述性的名字对应起来的话,表Airline4.Flight中的数据将无法和Airline1、Airline2和Airline3中的相应数据关联起来。即使有这样的对应表,我们仍然需要使用近似字符串匹配的技术 [Hadjieleftheriou and Srivastava 2011]将Airfare4.Flight中的Newark Liberty匹配到Airinfo5.AirportCodes表中的Newark Liberty, NJ, US。
  4.数据不一致性
  为了融合来自不同数据源的数据,我们需要解决实例级的歧义性和数据源之间的不一致性。
  例如,Airline2.Flight中的r32和Airport3.Arrivals中的r52存在着不一致(两者被高亮显示为蓝色以表明它们指的是同一航班)。r32表示Airline2航空公司的53号航班的原定到达日期和实际到达时间分别是2013-12-22和00:30,即实际到达日期和原定到达日期是同一天(不同于r31,其实际到达时间包含了(+1d),表明实际到达日期比原定到达日期晚一天)。然而,r52则记录了此航班的实际到达时间是2013-12-23的00:30。在集成的数据里,需要解决这样的不一致性。
  另一个例子,Airfare4.Flight中的r62表示Airline1的49号航班在2014-04-05原定的出发和到达时间分别是18:05和21:10。虽然出发日期和Airline1.Schedule中的r12一致(r12和r62被高亮显示为绿色来表示它们之间的这种关系),但是原定的出发和到达时间却不一致,也许因为r62错误地使用了Airline1.Schedule中的r11中给出的过去的出发和到达时间。类似地,Airfare4.Flight中的r65表示Airline2的53号航班在2014-06-28原定的出发和到达时间分别是15:30和23:35。虽然出发日期和Airline2.Flight中的r33一致(r65和r33都被高亮显示为黄绿色以表明它们之间的关系),但是原定的出发和到达时间却不一致,也许因为r65错误地使用了Airline2.Flight中的r32给出的过去的出发和到达时间。再一次表明,这些不一致性在集成起来的数据里需要被解决。

1.1.3 数据集成:体系结构和三个主要步骤

  传统数据集成的方法解决语义歧义性、实例表示歧义性和数据不一致性带来的挑战时使用的是一种流水线体系结构,主要包含三个步骤,如图1-1所示。

image

  传统数据集成中的第一个主要步骤是模式对齐。它主要针对的是语义歧义性带来的问题,目标是理解哪些属性具有相同的含义而哪些属性的含义不同。其正式的定义如下。
   给定某一领域内的一组数据源模式,不同的模式用不同的方式描述该领域。模式对齐步骤生成以下三种输出。
  1)中间模式。它为不同数据源提供一个统一的视图,并描述了给定领域的突出方面。
  2)属性匹配。它将每个源模式中的属性匹配到中间模式的相应属性。
  3)模式映射。每个源模式和中间模式之间的映射用来说明数据源的内容和中间数据的内容之间的语义关系。
  结果模式映射被用来在查询问答中将一个用户查询重新表达成一组底层数据源上的查询。
  种种原因使得这一步并不简单。不同数据源可以用非常不同的模式描述同一领域,如前面的航班例子。他们可以用不同的属性名来描述同一属性(如Airline1.Flight中的Arrival Date、Airline2.Flight中的Actual Arrival Date以及Airport3.Arrivals中的Actual)。另外,数据源也会用相同的名字表示不同含义的属性(如Airport3.Departures中的Actual指的是实际出发日期,而Airport3.Arrivals中的Actual指的是实际到达日期)。
  传统数据集成中的第二个主要步骤是记录链接。它主要针对的是实例表示歧义性所造成的问题,目标是理解哪些记录表示相同的实体而哪些不是。其正式的定义如下。
   给定一组数据源,每个包含了定义在一组属性上的一组记录。记录链接是计算出记录集上的一个划分,使得每个划分类包含描述同一实体的记录。
  即使已经完成了模式对齐,记录链接仍然很有挑战。不同的数据源会用不同的方式描述同一实体。例如,Airline1.Schedule中的r11和Airline1.Flight中的r21应该被链接到Airport3.Departures中的r41;然而,r11和r21没有显式地提到航空公司的名字,而r41没有显式地给出起飞机场,而要唯一确定一个航班,这两种信息都需要。另外,不同数据源可能使用不同的形式表示相同的信息(例如前面例子中讨论的表示机场的各种方式)。最后,在数百亿条记录中使用两两比较的方法来判定两条记录是否描述同一实体的方法是不可行的。
  传统数据集成中的第三个主要步骤是数据融合。它主要针对的是数据质量带来的挑战,目标是理解在数据源提供相互冲突的数据值时在集成起来的数据中应该使用哪个值。其正式的定义如下。
   给定一组数据项,以及为其中一些数据项提供值的一组数据源。数据融合决定每个数据项正确的值。
  许多种原因都可能造成数据冲突,如输入错误、计算错误(例如,r32和r52的实际到达日期之间的不一致)、过时的信息(例如,r12和r62的原定出发和到达时间之间的不一致)等。
  我们将在后面的章节逐一介绍每一步骤中所使用的各种方法。下面我们继续讨论当数据集成从传统数据集成演化到大数据集成时所带来的挑战和机遇。

相关文章
|
1月前
|
分布式计算 大数据 Apache
ClickHouse与大数据生态集成:Spark & Flink 实战
【10月更文挑战第26天】在当今这个数据爆炸的时代,能够高效地处理和分析海量数据成为了企业和组织提升竞争力的关键。作为一款高性能的列式数据库系统,ClickHouse 在大数据分析领域展现出了卓越的能力。然而,为了充分利用ClickHouse的优势,将其与现有的大数据处理框架(如Apache Spark和Apache Flink)进行集成变得尤为重要。本文将从我个人的角度出发,探讨如何通过这些技术的结合,实现对大规模数据的实时处理和分析。
107 2
ClickHouse与大数据生态集成:Spark & Flink 实战
|
4月前
|
分布式计算 DataWorks 关系型数据库
MaxCompute 生态系统中的数据集成工具
【8月更文第31天】在大数据时代,数据集成对于构建高效的数据处理流水线至关重要。阿里云的 MaxCompute 是一个用于处理大规模数据集的服务平台,它提供了强大的计算能力和丰富的生态系统工具来帮助用户管理和处理数据。本文将详细介绍如何使用 DataWorks 这样的工具将 MaxCompute 整合到整个数据处理流程中,以便更有效地管理数据生命周期。
142 0
|
1月前
|
分布式计算 大数据 OLAP
AnalyticDB与大数据生态集成:Spark & Flink
【10月更文挑战第25天】在大数据时代,实时数据处理和分析变得越来越重要。AnalyticDB(ADB)是阿里云推出的一款完全托管的实时数据仓库服务,支持PB级数据的实时分析。为了充分发挥AnalyticDB的潜力,将其与大数据处理工具如Apache Spark和Apache Flink集成是非常必要的。本文将从我个人的角度出发,分享如何将AnalyticDB与Spark和Flink集成,构建端到端的大数据处理流水线,实现数据的实时分析和处理。
62 1
|
4月前
|
消息中间件 分布式计算 大数据
RabbitMQ与大数据平台的集成
【8月更文第28天】在现代的大数据处理架构中,消息队列作为数据传输的关键组件扮演着重要的角色。RabbitMQ 是一个开源的消息代理软件,它支持多种消息协议,能够为分布式系统提供可靠的消息传递服务。本篇文章将探讨如何使用 RabbitMQ 与 Hadoop 和 Spark 进行集成,以实现高效的数据处理和分析。
45 1
|
4月前
|
分布式计算 大数据 数据处理
【大数据管理新纪元】EMR Delta Lake 与 DLF 深度集成:解锁企业级数据湖的无限潜能!
【8月更文挑战第26天】随着大数据技术的发展,Apache Spark已成为处理大规模数据集的首选工具。亚马逊的EMR服务简化了Spark集群的搭建和运行流程。结合使用Delta Lake(提供ACID事务保证和数据版本控制)与DLF(加强数据访问控制及管理),可以显著提升数据湖的可靠性和性能。本文通过一个电商公司的具体案例展示了如何在EMR上部署集成Delta Lake和DLF的环境,以及这一集成方案带来的几大优势:增强的可靠性、细粒度访问控制、性能优化以及易于管理的特性。这为数据工程师提供了一个高效且灵活的数据湖平台,简化了数据湖的建设和维护工作。
62 1
|
4月前
|
机器学习/深度学习 设计模式 人工智能
面向对象方法在AIGC和大数据集成项目中的应用
【8月更文第12天】随着人工智能生成内容(AIGC)和大数据技术的快速发展,企业面临着前所未有的挑战和机遇。AIGC技术能够自动产生高质量的内容,而大数据技术则能提供海量数据的支持,两者的结合为企业提供了强大的竞争优势。然而,要充分利用这些技术,就需要构建一个既能处理大规模数据又能高效集成机器学习模型的集成框架。面向对象编程(OOP)以其封装性、继承性和多态性等特点,在构建这样的复杂系统中扮演着至关重要的角色。
70 3
|
5月前
|
存储 JSON DataWorks
DataWorks产品使用合集之如何通过数据集成将API接口产生的数据集成到DataWorks
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
5月前
|
分布式计算 DataWorks 调度
DataWorks产品使用合集之在使用MaxCompute进行数据集成同步到OSS时,出现表名和OSS文件名不一致且多了后缀,该如何处理
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
5月前
|
数据采集 分布式计算 大数据
MaxCompute产品使用合集之数据集成中进行数据抽取时,是否可以定义使用和源数据库一样的字符集进行抽取
MaxCompute作为一款全面的大数据处理平台,广泛应用于各类大数据分析、数据挖掘、BI及机器学习场景。掌握其核心功能、熟练操作流程、遵循最佳实践,可以帮助用户高效、安全地管理和利用海量数据。以下是一个关于MaxCompute产品使用的合集,涵盖了其核心功能、应用场景、操作流程以及最佳实践等内容。
|
5月前
|
机器学习/深度学习 分布式计算 大数据
MaxCompute 2.0:开源系统的集成与创新
增强实时处理能力:进一步加强与Flink等实时处理框架的合作。 强化机器学习支持:提供更多内置的机器学习算法和工具。 增强数据治理功能:提供更完善的数据质量和安全治理方案。