你好,游客 登录
背景:
阅读新闻

大数据高速处理的解决方案

[日期:2014-05-16] 来源:译语网  作者:译者: passerby98 原作者:Michael Stonebraker [字体: ]

  “大速度”的意思是“对着高压水龙头饮水”,即吸收高速涌进的数据。例子很多,包括华尔街市场数据馈送、大型多人游戏的状态更新、网站访问日志、网页广告投放、传感器数据收集系统如用于交通拥堵、车险记录等等。

  我们马上就能把高速领域分成两类。第一类需要实时处理馈送,第二类则允许我们收集大量报文(message)以便批处理。鉴于批处理技术众多,本帖只考虑需要实时处理的。例如,系统必须在若干毫秒内决定在网页上投放哪些广告;同样地,华尔街数据馈送引发的电子交易也必须快速完成。从总体而言,整个世界正走向“实时”,故我预计愿意从事批处理的公司会逐渐减少。因此,在本帖其余部分,我假设对大量实时报文处理的响应时间必须是在一秒钟以内。

  看来,有两种案例值得注意,特以华尔街金融交易来说明。第一个案例涉及识别触发电子交易的模式。尽管操控交易系统的法则被认为是“业内机密”,我们仍可用一个例子来说明简单案例。假设股票X和股票Y被认为有关联性。那么,其中一种升或跌,则应购入(或卖空)另一种。广而言之,系统等候此类更复杂的模式;例如:X股价上升后10毫秒内Y股价下跌。由此可见交易应用系统通过寻找一系列模式来处理快速涌入的交易数据,找到一个匹配的模式后,采取相应的行动。

  第二例涉及在全球各地(例如:东京、纽约、伦敦、法兰克福等)设有本地交易引擎的电子交易公司。各交易系统独立运行,公司总部则需要保持整个公司的实时全球部位(译注:position,亦称“头寸”),即把所有证券的多、空部位累加。假如某个部位过大,则需启动相应的纠正措施。如此,世界任一处的每一笔交易,都会有一条报文发至总部的数据库,在该系统中,公司的部位“状态”得到实时更新。

  第一个应用基本无需保持状态、而把注意力集中在复杂的模式识别上,第二种则主要是在维护状态、对每条报文重复同一步骤。故前者是“大模式、小状态”、后者则是“小模式、大状态”。这两类用例由极其不同的软件系统来处理。需要根据自己的用例类型来确定方向。

  第一个用例是复杂事件处理(CEP)系统的“拿手好戏”,例如:Esper、StreamBase、Tibco、UC4等。这些产品提供易用的工作流体系,通过工作流来制定复杂模式、以实现实时发现。

  第二个用例很像高性能的在线交易处理(OLTP)。在此领域,通常有三种选择方案:传统的关系型数据库系统(RDBMS)、NoSQL引擎、NewSQL系统。我们逐个讨论。RDBMS遗留产品,如DB2、Oracle、SQLServer,是多年前设计的通用数据库系统,各类应用通吃。如此,面对高速实时报文涌入,其性能几乎肯定不足,在吞吐量和延迟双方面均是如此。需要高速应用处理的用户可直接否决RDBMS。这类用户经常转向NoSQL方案来寻求更好的性能。有大约75个NoSQL引擎试图提供更好的性能,其手段是放弃高级语言(SQL)、选用每次处理一条记录的低级界面、放弃事务(译注:transaction,是业内术语,“是数据库管理系统执行过程中的一个逻辑单位,由一个有限的数据库操作序列构成”,引自《维基百科》)。

  四十年的数据库系统研究,已经明确显示了高级数据语言的优势,即数据独立性更佳、代码维护更好、代码更易懂、无性能损失等等。因此,我认为NoSQL供应商相信低级符号语言产生更佳性能是误入歧途。有趣的是:两个主要的NoSQL供应商(MongoDB、Cassandra)正在投资于酷似SQL的高级语言。有鉴于此,我倾向于认为NoSQL实际上意思是“还没有SQL”。

  NoSQL产品的第二个要点是放弃ACID(译注:ACID“是指数据库管理系统在写入/异动资料的过程中,为保证事务正确可靠所必须具备的四个特性:原子性、一致性、隔离性、持久性”,摘引自《维基百科》)事务来换取性能。如文献[1]所示,这确实如此。然而,大家日益意识到ACID一致性是个好东西。连“否定ACID”的旗手谷歌公司看来都在重新考虑其反对意见[2]。无法保证ACID,意味着应用设计师将不得不花费大量代码来确保其所需的任何数据一致性。反对ACID的另外一个理由涉及可获性(availability),出自著名的CAP定理[3],我在以往一篇BLOG@CACM博文中曾讨论过[4]。高可获性(特别是在广域网环境下)将可通过复制数据最终一致来实现,而不是通过ACID复制。然而,应该明确注意的是,最终一致性(eventual consistency)实际上意味着数据库里有非可换更新时产生的垃圾或带来完整性的约束。文献[2]对此有进一步的讨论。故最终一致性仅对一部分应用适用。如果你的应用不在其内,那么,决定使用非ACID数据库系统将令你后悔莫及。由此可见,NoSQL产品以放弃ACID为代价来获得好一些的性能和可获性。假如你目前或将来需要ACID,这些产品多半不是好选择。

  第三个选择是NewSQL系统,产品有MemSQL、NuoDB、SolidDB、TimesTen、VoltDB等等。这类供应商保留了SQL和ACID事务,通过选择极不相同的架构,比传统关系型数据库系统性能大幅提升。NewSQL引擎经常讲明了是“内存数据库”,大部分采用与动态锁不同的并发控制机制。另外,某些产品还使用逻辑(命令)日志而不是传统的数据日志,经常依赖于单线程架构以避免锁存共享数据结构(如“B树”)的开销。因此,此类产品是另一个选项:在保留ACID和SQL的同时大幅改善性能。

  总而言之,假如你能容忍高延迟(能容忍的人将日益减少),那么有很多高速处理的解决方案。否则,你应该考虑CEP或OLTP系统。对后者来说,传统的RDBMS产品注定不适用于高速“有状态”的应用;NewSQL和NoSQL产品能否胜任还有待观察。

猜您喜欢:

  1.大数据应用案例解析:商业智能管理

  2.大数据应用案例

  3.大数据视频分析:看视频的都是哪些人?





收藏 推荐 打印 | 录入: | 阅读:
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款