没有合适的资源?快使用搜索试试~ 我知道了~
首页Bloomberg的中数据处理:突破TB级挑战与高效设计
Bloomberg的中数据处理:突破TB级挑战与高效设计
1 下载量 66 浏览量
更新于2024-08-27
收藏 235KB PDF 举报
"勿谈大数据的宏大概念,而是关注Bloomberg如何应对中数据处理的复杂现实。中数据是指数据规模介于单服务器能处理的范围与PB级大数据集群之间,通常在TB级别。Bloomberg面临的是这种规模的挑战,特别是在时间序列数据分析中,如债券价格、交易量等数据,对实时性和性能有极高要求。 在企业级场景下,Bloomberg发现传统的Hadoop和Spark系统在低延迟处理中并不理想,尽管现代硬件如高核心数、SSD和大内存变得普遍。现有的大数据平台未能充分利用这些硬件优势,尤其是在处理当天数据的写入和历史数据的批量更新时,两者的需求和性能差距显著。例如,当天数据系统需要频繁写入,历史数据则涉及大量搜索,这导致系统设计复杂且效率不高。 一个具体的例子是债券时间序列数据,其中需要快速响应,响应时间需控制在5毫秒内,每日被访问数十亿次,高峰期甚至每秒高达50万次。这对系统的稳定性和性能提出了严峻考验。 PortfolioAnalytics等应用可能同时需要处理大规模数据,如数万个债券的归因计算,涉及到大量数据点。即使使用高效的缓存,仍有大量未命中的情况,这可能导致磁盘I/O密集,特别是当用户请求大量增加时,对价格历史系统的压力倍增。 总结来说,Bloomberg面临的中数据处理挑战在于如何在满足实时性、高性能和海量数据管理的同时,优化硬件资源利用,降低延迟,并应对不断增长的业务需求。这需要创新的架构设计和数据处理技术,以应对不同于传统大数据的中等规模数据处理问题。"
资源详情
资源推荐
勿谈大,且看勿谈大,且看Bloomberg的中数据处理平台的中数据处理平台
中数据意味着数据体积已经超越单服务器处理的上限,但也无需使用数千台节点组成的集群——通常是TB级,而不是PB级
的。这里,我们不妨走进Bloomberg的用例,着眼时间序列数据处理上的数据和体积挑战。
以下为译文以下为译文
在Bloomberg,我们并不存在大数据挑战。取而代之,系统正在遭遇“中数据(Medium data)”的威胁,而当下许多行业的机
构基本上都面临着这种威胁。对Bloomberg来说,在企业级低延时场景下,Hadoop和Spark这样的系统既没有效率,也难以维
护。时至今日,高核心数、SSD以及海量内存已并不稀奇,但是当下的大数据平台(通过搭建商用服务器集群)却并不能完
全利用这些硬件的优势,存在的挑战也不可谓不大。同时,当下很多分布式组件也深受Java的影响,很难达到预期的低延时
性能。
一个实际用例一个实际用例
债券时间序列数据通常包括一个债券(比如IBM)、一个字段(比如price)、一个时间和一个值。
通常情况下,数据会被拆分成两个部分:当天数据和历史数据——处理当天数据的系统通常会捕获一天中的所有行为,而处理
历史数据的系统需要负责前一段时间所积累的数据。在过去,统一这两种数据是不可能实现的,因为他们有着不同的性能需
求:当天数据的处理系统必须可以承受大量的写入操作,而历史数据处理系统通常是每天一次的批量更新,但是数据体积更
大,而且搜索次数也更多。
在债券时间序列数据上,在总量为一年的数据上,某个字段的响应时间需要控制在5毫秒。同时,这些数据每天会被访问数十
亿次,峰值期间大约50万每秒。对于Bloomberg来说,这个系统非常重要,一旦发生故障,很可能就会扰乱到资本市场。
问题随之而来,类似Portfolio Analytics等应用往往会同时需求大量的数据。一个债券组合很可能包括数以万计的债券,而类似
归因(attribution)这种计算往往需要每个源每天40个字段的数据。从而,在多年数据上计算一个债券组合的归因需要上千万
的数据点(datapoint)。因此,即使在命中率为99.9%的高效缓存中,仍然存在大量缓存未命中的情况。这样一来,如果底层
系统使用磁盘介质的话,这个操作往往会造成成千上万的磁盘寻道。同时,基于用户的数量,系统中存在着大量的请求。因
此,不难想象,这会给现有价格历史系统造成什么样的挑战。
数年前,解决这个问题的途径是将一切都放到内存和固态硬盘上,同时将高度压缩的blobs分割到多个数据库中。这是一个巨
大的飞跃,系统速度提升了2到3个数量级,然而这并不是我们想要的——跨多数据库压缩blobs分割是非常麻烦的。
时间序列数据通常会转化为非常极端的并行问题,往往会出现这样一个情况:当为一个组合取数以千万计的数据点时,工作可
以根据需求被任意拆分到数以千万的主机上。这样看来,并行似乎是最好的解决方案。而在单主表的分布式处理上,理论中
HBase应该是个非常契合的计算框架。
当然从理论上讲,理论和实践应该是一致的,然而在实践中往往并不是一直如此。数据集确实可以达到一定的效果,但是在性
能、效率、期满及弹性上都存在一定的障碍。这样一来,问题就在于如何移除这些障碍。
当一个节点发生故障后,数据并不会丢失——因为数据已经通过HDFS备份到多个节点上。但是这里仍然存在一个非常大的缺
点,在任何给定时间,到给定region的读写操作只被一个region服务器控制。如果这个region挂掉,故障将会被发现,故障转
移会自动的进行。但是,直到这个故障被处理前,它负责的任何读写都不可能继续进行。
在故障转移上,HBase社区的发展可以说是日新月异,需求的时间也是愈来愈少,但是这里仍然存在一个巨大的漏洞。分布式
系统中的故障往往通过设置期满判定,通过心跳或者其他机制来感知。这样一来,如果超时被设置的太短,很可能就会产生误
报,但是如果时间被设置太长,则会造成更长时间的不可用。
在Bloomberg用例下,SLA是毫秒级的。但是,超时的设置却是秒级的,这样一来,即使故障被侦测后的处理时间无限接近于
0,HBase故障转移所造成的延时完全不可行。
在与多个Hadoop提供商交流后,我们也得到了几个可行的解决方案,其中大部分是通过给数据库做多个备份来解决问题。鉴
于Bloomberg系统可以应对整个数据中心丢失的大方针,使用这个途径无疑需要给每个数据库配置多个同时运行的副本,在我
下载后可阅读完整内容,剩余3页未读,立即下载
weixin_38689027
- 粉丝: 5
- 资源: 888
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- C++多态实现机制详解:虚函数与早期绑定
- Java多线程与异常处理详解
- 校园导游系统:无向图实现最短路径探索
- SQL2005彻底删除指南:避免重装失败
- GTD时间管理法:提升效率与组织生活的关键
- Python进制转换全攻略:从10进制到16进制
- 商丘物流业区位优势探究:发展战略与机遇
- C语言实训:简单计算器程序设计
- Oracle SQL命令大全:用户管理、权限操作与查询
- Struts2配置详解与示例
- C#编程规范与最佳实践
- C语言面试常见问题解析
- 超声波测距技术详解:电路与程序设计
- 反激开关电源设计:UC3844与TL431优化稳压
- Cisco路由器配置全攻略
- SQLServer 2005 CTE递归教程:创建员工层级结构
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功