hadoop混搭

基于Internet的新型数据集成应用程序正在整个Internet上兴起。 俗称mashup ，它们的流行源于对交互式用户参与的重视以及类似于Frankenstein的怪物般的方式，它们将第三方数据聚合并缝合在一起。 发芽的隐喻是一个合理的隐喻。 mashup网站的特点是，它利用从组织边界之外的数据源中检索到的内容和功能，在整个Web上传播根源。

对混搭的这种模糊的数据集成定义当然不是严格的。 关于混搭的一个很好的见解是查看术语的词源：它是从流行音乐场景中借来的，混搭是一首新歌，是来自两首不同来源歌曲的人声和器乐曲混合而成的（通常属于不同类型）。 就像这些“混音流行”歌曲一样，混搭是一种不寻常的或创新的内容组合（通常来自无关数据源），是为人类（而非计算机化）消费而制作的。

那么，混搭可能是什么样子？ ChicagoCrime.org网站是一个很好的直观示例，它称为映射mashup 。 该网站是第一个在媒体上广泛流行的混搭程序之一，它将芝加哥警察局在线数据库中的犯罪数据与Google Maps中的制图技术进行混搭。 用户可以与mashup站点进行交互，例如指示其以图形方式显示包含图钉的地图，这些图钉揭示了南芝加哥最近发生的所有盗窃罪的详细信息。 概念和表示很简单，犯罪和地图数据的构成在视觉上很强大。

在Mashup风格中 ，您将调查mashup的流行类型，包括映射mashup。 相关技术概述了与混搭的构建和操作有关的技术领域。 技术挑战和社会挑战分别代表了突出的技术挑战和社会挑战，影响了混搭。

混搭类型

在本节中，我对著名的混搭类型进行了简要调查。

映射混搭

在这个信息技术时代，人类正在收集有关事物和活动的大量数据，而这两个数据都不会在位置上进行注释。 包含位置数据的所有这些多样化数据集都在尖叫，希望使用地图以图形方式呈现。 mashup出现的主要催化剂之一是Google推出了Google Maps API。 这打开了闸门，使Web开发人员（加上业余爱好者，修补匠和其他人）可以将各种数据（从核灾难到波士顿的CowParade奶牛的一切数据）融合到地图上。 不容忽视，不久之后来自Microsoft（Virtual Earth），Yahoo（Yahoo Maps）和AOL（MapQuest）的API。

视频和照片混搭

照片托管和诸如Flickr之类的带有公开照片共享API的社交网站的出现，导致了各种有趣的混搭。 由于这些内容提供者具有与其托管的图像相关的元数据（例如，谁拍摄的照片，照片的照片，拍摄的时间和地点等等），因此mashup设计人员可以将照片与可以关联的其他信息相融合与元数据。 例如，混搭可能会分析歌曲或诗歌歌词并创建相关照片的马赛克或拼贴，或者根据常见的照片元数据（主题，时间戳和其他元数据）显示社交网络图。 又一个示例可以将网站（例如CNN之类的新闻网站）作为输入，并通过将标记的照片与新闻中的单词进行匹配来呈现照片中的文本。

搜索和购物混搭

搜索和购物mashup在mashup一词被创造之前就已经存在了。 在使用Web API之前，诸如BizRate，PriceGrabber，MySimon和Google的Froogle之类的比较购物工具使用企业对企业（b2b）技术或屏幕抓取的组合来汇总比较价格数据。 为了促进混搭和其他有趣的Web应用程序，诸如eBay和Amazon之类的消费市场已经发布了API，用于以编程方式访问其内容。

新闻混搭

自2002年以来，新闻来源（例如《纽约时报》，BBC或路透社）就一直使用RSS和Atom之类的联合技术（在下一节中进行介绍）来传播与各种主题相关的新闻提要。 联合供稿混搭可以聚合用户的供稿，并通过Web呈现它们，从而创建个性化的报纸来满足读者的特定兴趣。 Diggdot.us是一个示例，它结合了面向技术人员的新闻源Digg.com，Slashdot.org和Del.icio.us的提要。

相关技术

本节概述了有助于混搭开发的技术。 有关这些技术的更多信息，请参阅相关主题在本文的结尾。

架构

混搭应用程序在结构上由三个不同的参与者组成，这三个参与者在逻辑上和物理上是不相交的（它们可能被网络和组织边界分隔开）：API /内容提供者，混搭站点和客户端的Web浏览器。

• API /内容提供者。 这些是（有时是不知情的）正在混搭的内容的提供者。 在ChicagoCrime.org混搭示例中，提供者是Google和芝加哥警察局。 为了促进数据检索，提供程序通常通过诸如REST，Web服务和RSS / Atom（如下所述）之类的Web协议公开其内容。 但是，许多有趣的潜在数据源（尚未）还方便地公开API。 从诸如Wikipedia，TV Guide以及几乎所有政府和公共领域网站之类的站点中提取内容的混搭都是通过称为屏幕抓取的技术来进行提取的。 在这种情况下，屏幕抓取表示一种过程，通过该过程，工具尝试通过尝试解析提供商最初打算供人使用的网页从内容提供商中提取信息。

• 混搭站点。 这是mashup的托管地。 有趣的是，仅因为这是mashup逻辑所在，它并不一定在其中执行。 一方面，可以使用服务器端动态内容生成技术（例如Java servlet，CGI，PHP或ASP）以类似于传统Web应用程序的方式实现混搭。

  或者，可以通过客户端脚本（即JavaScript）或applet直接在客户端浏览器中生成混搭内容。 这种客户端逻辑通常是直接嵌入mashup网页中的代码以及这些网页引用的脚本API库或小程序（由内容提供者提供）的组合。 使用这种方法的混搭可以称为富互联网应用程序 （RIA），这意味着它们非常面向交互式用户体验。 （丰富的Internet应用程序是现在称为“ Web 2.0”的一个标志，Web 2.0是万维网上可用的下一代服务。）客户端mashing的好处包括代表mashup服务器的开销较小（数据可以直接从内容提供者检索）和更无缝的用户体验（页面可以请求更新部分内容，而无需刷新整个页面）。 Google Maps API旨在通过浏览器端JavaScript进行访问，并且是客户端技术的示例。

  混搭通常使用服务器和客户端逻辑的组合来实现其数据聚合。 许多混搭应用程序使用由其用户群直接提供给他们的数据，从而（至少）使数据集之一成为本地数据集。 此外，对多个来源的数据执行复杂的查询（例如“向我显示与凯文·培根共同出演电影的演员购买的房地产的平均购买价格”）需要在客户端的Web上执行不可行的计算浏览器。

• 客户端的Web浏览器。 这是应用程序以图形方式呈现以及用户交互发生的地方。 如上所述，混搭通常使用客户端逻辑来组装和组成混搭的内容。

阿贾克斯

关于术语Ajax是否是首字母缩写词存在一些争议（有些人会说它代表“异步JavaScript + XML”）。 无论如何，Ajax是Web应用程序模型而不是特定技术。 它包含几种围绕异步加载和表示内容的技术：

• XHTML和CSS用于样式表示
• 浏览器公开的文档对象模型（DOM）API，用于动态显示和交互
• 异步数据交换，通常是XML数据
• 浏览器端脚本，主要是JavaScript

这些技术一起使用时，其目标是通过与内容服务器交换少量数据，而不是在执行某些用户操作后重新加载并重新呈现整个页面，从而为用户创造一种顺畅，凝聚的Web体验。 您可以从通常用JavaScript实现的各种Ajax工具包和库（例如Sajax或Zimbra）构建用于混搭的Ajax引擎。 Google Maps API包括一个专有的Ajax引擎，它对用户体验的影响是强大的：它的行为就像一个真正的本地应用程序，因为没有滚动条可以操纵或转换迫使页面重新加载的箭头。

Web协议：SOAP和REST

SOAP和REST都是平台无关的协议，用于与远程服务进行通信。 作为面向服务的体系结构范式的一部分，客户端可以使用SOAP和REST与远程服务进行交互，而无需了解其底层平台的实现情况：服务的功能完全由其请求和响应的消息的描述来传达。

SOAP是Web服务范例的基本技术。 SOAP最初是简单对象访问协议（Simple Object Access Protocol）的首字母缩写，由于其关注点已从基于对象的系统转向消息交换的互操作性，因此被重新称为面向服务的访问协议 （或简称SOAP）。 SOAP规范包含两个关键组件。 第一种是将XML消息格式用于平台无关的编码，第二种是消息结构，它由标头和主体组成。 标头用于交换不是特定于应用程序有效负载（主体）的上下文信息，例如身份验证信息。 SOAP消息主体封装了特定于应用程序的有效负载。 WSDL文档描述了用于Web服务的SOAP API，它们本身描述了服务公开的操作，接受的消息的格式（使用XML Schema）以及如何解决。 SOAP消息通常通过HTTP传输来传递，尽管其他传输（例如JMS或电子邮件）同样可行。

REST是表示状态转移 （ Representational State Transfer ）的首字母缩写，这是一种仅使用HTTP和XML的基于Web的通信技术。 它的简单性和缺乏严格的配置文件使它与SOAP脱颖而出，并使其具有吸引力。 与现代编程语言中的典型基于动词的接口不同（这些接口由多种方法组成，例如getEmployee() ， addEmployee() ， listEmployees()等），REST从根本上仅支持一些操作（即POST ， GET ， PUT ， DELETE ）适用于所有信息。 REST的重点是信息本身，即资源。 例如，员工的资源记录由URI标识，通过GET操作检索，通过PUT操作更新等等。 这样，REST与SOAP服务的文档文字样式相似。

屏幕刮

如前所述，缺少内容提供商的API通常会迫使混搭开发人员使用屏幕抓取来检索他们想要混搭的信息。 爬取是使用软件工具解析和分析最初为人类使用而编写的内容的过程，以提取表示该信息的语义数据结构，该语义数据结构可以通过编程方式使用和操作。 少数混搭使用屏幕抓取技术来获取数据，尤其是从公共部门获取数据时。 例如，房地产地图混搭可以将制图提供者的地图与从县档案局获得的“ comp”数据进行混搭，以出售或出租房屋清单。 XMLTV是另一个收集数据的混搭项目，XMLTV是一组工具的集合，这些工具汇总了来自世界各地的电视列表。

屏幕刮擦通常被认为是不完善的解决方案，并且有充分的理由。 它有两个主要的固有缺点。 首先是，与具有接口的API不同，抓取在内容提供者和内容消费者之间没有特定的程序协定。 抓取者必须围绕源内容模型设计其工具，并希望提供者始终遵循此表示模型。 网站有一种定期对其外观进行大修以保持其新鲜和时尚的趋势，这代表刮板造成了严重的维护麻烦，因为它们的工具可能会失效。

第二个问题是缺少复杂的，可重复使用的屏幕抓取工具包软件，俗称的是scrAPIs 。 缺少此类API和工具包的主要原因是每个单独的抓取工具都具有非常特定于应用程序的需求。 由于迫使设计人员对提供者站点中的内容进行逆向工程，开发数据模型，解析和汇总原始数据，因此，这将导致大量的开发开销。

语义网和RDF

屏幕抓取的不雅观可直接追溯到以下事实：为人类消费而创建的内容对于自动机器消费而言并不是很好的内容。 输入语义网，这是可以扩展现有Web的愿景，以用等效的机器可读信息补充为人类设计的内容。 在语义网的上下文中，信息一词不同于数据。 数据在传达含义时即成为信息（即可以理解）。 语义Web的目标是创建一个Web基础结构，以元数据扩充数据以赋予其含义，从而使其适合自动化，集成，推理和重用。

W3C规范家族统称为资源描述框架（RDF），其作用是提供建立描述数据的句法结构的方法。 XML本身是不够的。 它太武断了，因为您可以用多种方式对其进行编码以描述同一段数据。 RDF-Schema增加了RDF以机器可读的方式编码概念的能力。 一旦可以在数据模型中描述数据对象，RDF就会通过主谓谓对象三元组（“对象S与对象O的关系为R”）提供数据对象之间的关系的构造。 数据模型和关系图的组合允许创建本体，本体是可以搜索和正式推理的知识的层次结构。 例如，您可以定义一个模型，其中“食肉动物类型”作为“动物类型”的子类，并具有“吃掉”另一个“动物类型”的约束，并创建它的两个实例：一个实例填充有关猎豹和北极熊及其栖息地的数据，有关瞪羚和企鹅及其各自栖息地的数据。 然后，推理引擎可能会“融合”这些单独的模型实例，并说明猎豹可能捕食瞪羚而不是企鹅。

RDF数据正在各种领域中Swift被采用，包括社交网络应用程序（例如FOAF-朋友的朋友）和联合组织（例如RSS，我将在下面介绍）。 此外，RDF软件技术和组件已开始达到成熟水平，尤其是在RDF查询语言（例如RDQL和SPARQL）以及编程框架和推理引擎（例如Jena和Redland）方面。

RSS和ATOM

RSS是一系列基于XML的联合格式。 在这种情况下，联合意味着要分发内容的网站将创建一个RSS文档，并将该文档注册到RSS发布者。 然后，启用RSS的客户端可以检查发布者的供稿中是否有新内容，并以适当的方式对其进行React。 RSS已被用来联合多种内容，包括新闻报道和标题，CVS签入或Wiki页面的更改日志，项目更新，甚至是音视频数据（例如广播节目）。 1.0版是基于RDF的，但最新版本不是2.0版。

Atom是更新的但类似的联合协议。 它是Internet工程任务组（IETF）提出的标准，旨在维护比RSS更好的元数据，提供更好和更严格的文档，并结合了通用数据表示的构造概念。

这些聚合技术非常适合用于聚合基于事件或更新驱动内容的混搭，例如新闻和博客聚合器。

技术挑战

像任何其他数据集成领域一样，mashup开发充满了需要解决的技术挑战，尤其是当mashup应用程序具有更多的特性和功能时。 本节介绍了其中的一些挑战，您可以解决和缓解其中的一些挑战，而另一些则是未解决的问题。

数据集成挑战：语义含义和数据质量

定性调查表明，当今企业IT首要关注的是企业虚拟组织内的数据集成。 （在这种情况下，我使用“ 虚拟组织 ”一词来表示联合业务部门的组成，每个联合业务部门都包含在其自己的管理域中。）就像许多企业IT经理一样，他们发现自己要完成整合旧数据源的任务（例如，为了创建反映当前业务状况的公司仪表板），mashup开发人员面临着在异构数据集之间获取共享语义的类似挑战。 因此，要想了解mashup开发人员所拥有的东西，您只需要了解企业IT面临的存储集成难题。

例如，必须设计数据模型之间的转换系统。 将数据转换为通用格式时，通常在映射不完整时必须做出合理的假设（例如，一个数据源可能具有其中地址类型包含国家/地区字段的模型，而另一种则没有） 。 混搭开发人员可能不是源数据模型的领域专家，因为该模型是第三方的模型，并且这些合理的假设可能并不直观或明确，这已经使挑战变得更加棘手。

除了缺少数据或不完整的映射外，mashup设计人员还可能发现他们希望集成的数据不适合机器自动化。 它需要清洗。 例如，执法人员的逮捕记录可能会不一致地输入，使用通用的名称缩写（例如，一个记录中的“ mkt sqr”和另一个记录中的“ Market Square”），即使具有良好的启发式方法，也很难对平等进行自动推理。 语义建模技术（例如RDF）可以帮助缓解不同数据集之间的自动推理问题，前提是它内置于数据存储中。 在使用语义建模技术之前，传统数据源在分析和数据清理方面可能需要大量的人力。

混搭开发人员可能还必须应对IT集成管理人员可能不应对的几个问题，其中之一是数据污染。 作为其应用程序设计的一部分，许多混搭会征求公众用户的意见。 正如Wiki应用程序领域中所证明的那样，这是双刃刀片：它可以非常强大，因为它可以实现开放式贡献和同类最佳的数据演化，但是却可能受到不一致，错误或故意误导的数据输入的影响。 。 后者可能使人们对数据的可信度产生怀疑，这最终会损害混搭所提供的价值。

当必须使用屏幕抓取技术进行数据采集时，会出现mashup开发人员面临的另一种集成问题。 如前一部分所述，派生解析和获取工具以及数据模型需要大量的逆向工程工作。 即使在可以创建这些工具和模型的最佳情况下，所要做的只是重构源站点如何显示其内容（或封存和放弃）以破坏集成过程并导致mashup应用程序失败。

组件挑战

与传统的整页刷新相比，Web开发的Ajax模型可以提供更丰富，更无缝的用户体验，但同时也带来一些困难。 从根本上讲，Ajax要求将浏览器的客户端脚本功能与其DOM结合使用，以实现一种内容传递的方法，而浏览器的设计师并未完全想到这种方法。 （也许Ajax的这种类似hack的特性吸引了它的吸引力。）但是，这使基于Ajax的应用程序遇到了自Microsoft创建Internet Explorer以来困扰Web设计师的相同浏览器兼容性问题。 例如，Ajax引擎利用XMLHttpRequst对象与远程服务器异步交换数据。 在Internet Explorer 6中，此对象是使用ActiveX而不是本机JavaScript实现的，这要求启用ActiveX。

一个更基本的要求是Ajax要求在用户的浏览器中启用JavaScript。 对于大多数人来说，这可能是一个合理的假设，但是肯定会有一些用户使用不支持JavaScript或未启用JavaScript的浏览器或自动工具。 其中一组工具是机器人，蜘蛛和Web搜寻器，它们为Internet和Intranet搜索引擎聚合信息。 如果没有适当的降级，基于Ajax的mashup应用程序可能会发现自己在少数用户群以及搜索引擎可见性上都缺失。

使用JavaScript异步更新页面内的内容还会导致用户界面问题。 由于内容不再必须链接到浏览器地址栏中的URL，因此用户在使用浏览器的“后退”按钮或“书签”功能时可能不会体验到通常期望的功能。 而且，尽管Ajax可以通过请求增量内容更新来减少等待时间，但是糟糕的设计实际上会阻碍用户体验，例如，当更新的粒度足够小时，更新的数量和开销就会使可用资源饱和。 另外，在界面加载或内容更新时，请小心支持用户（例如，使用视觉反馈，例如进度条）。

与任何分布式，跨域应用程序一样，mashup开发人员和内容提供者同样也需要解决安全问题。 身份概念可以证明是一个棘手的话题，因为传统的Web主要是为匿名访问而构建的。 单点登录是一个理想的功能，但是有许多竞争技术（从Microsoft Passport到Liberty Alliance），因此创建了必须同时集成的脱节身份空间。 内容提供商可能会在其API中采用身份验证和授权方案（要求使用安全身份或可安全识别属性的概念）来实施涉及付费订阅或敏感数据的业务模型。 敏感数据也可能需要机密性（即加密），并且在与其他来源混搭数据时，请务必小心，不要将其置于危险之中。 身份对于审核和监管合规性也至关重要。 此外，随着服务器和客户端上都发生数据集成，从用户到mashup服务的身份和凭据委派可能成为必需条件。

社会挑战

除了上一节中描述的技术挑战之外，随着混搭变得越来越流行，社会问题已经（或将要出现）。

混搭开发人员面临的最大社会问题之一是知识产权保护和消费者隐私与合理使用和信息自由流通之间的权衡。 疏忽大意的内容提供者（屏幕抓取的目标），甚至暴露API以促进数据检索的内容提供者也可能会确定其内容正在以他们不赞成的方式使用。 要对Web聚合和法规进行良好的审查，请参阅参考资料 。

mashup Web应用程序类型仍处于起步阶段，业余爱好者的开发人员在业余时间制作了许多mashup。 这些开发人员可能不了解（或关心）诸如安全性的问题。 此外，内容提供商只是开始看到为基于机器的内容访问提供API的价值，而且许多人并不认为它们是核心业务重点。 这种结合可能会产生较差的软件质量，因为诸如测试和质量保证之类的优先事项会在概念验证和创新方面倒退。 整个社区必须共同努力，以组装开放标准和可重用工具包，以促进成熟的软件开发流程。

在mashup可以从凉爽的玩具过渡到复杂的应用程序之前，必须提炼大量的标准，协议，模型和工具包，这需要做很多工作。 为此，主要的软件开发行业领导者，内容提供商和企业家将不得不在mashup中找到价值，这意味着可行的业务模型。 API提供者将需要确定是否对其内容收费，以及是否收费（例如，通过订阅或按使用）。 也许他们将提供不同级别的服务质量。 某些市场提供商（例如eBay或Amazon）可能会发现，免费使用其API会增加产品移动。 混搭开发人员可能会寻找基于广告的收入模型，或者可能会构建旨在被收购的有趣的混搭应用程序。

摘要

混搭无疑是Web应用程序令人兴奋的新类型。 源自语义Web域的数据建模技术与松耦合的，面向服务的，与平台无关的通信协议的成熟，最终提供了开始开发可以利用和集成大量信息的应用程序所需的基础架构。在网络上可用。 随着mashup应用程序获得更高的可见性，有趣的是，该流派如何影响诸如合理使用和知识产权之类的社会问题以及跨组织边界集成数据的其他应用程序域，例如网格计算和企业对企业工作流程管理。

要深入了解mashup开发，请继续关注developerWorks上一系列新教程的发布，这些教程将教您如何构建自己的mashup。 实际上， 该系列甚至将教您如何使用语义Web技术和本体来使其他人创建自己的混搭。

翻译自: https://www.ibm.com/developerworks/web/library/x-mashups/index.html

hadoop混搭