中数据意味着数据体积已经超越单服务器处理的上限，但也无需使用数千台节点组成的集群——通常是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系统可以应对整个数据中心丢失的大方针，使用这个途径无疑需要给每个数据库配置多个同时运行的副本，在我们看来这么做太复杂了。最终，我们对这个替代方案并不满意，并决定尝试修改。 如果故障转移检测和恢复过程不能被加速，那么某个region服务器发生故障后，这里必须存在可以立刻被查询的备用节点。根据这个思路，我们拟定了短期解决方案：数据必须在多个不同的地方进行存储，虽然在传输上可能会存在一定的延时，但是在这种存在大量批处理更新场景的类似价格历史日结系统中却完全可行——在备用region服务器上使用这个策略可以保证事件接收的顺序，提供了时间序列上的一致性，即使延时很高。 时间序列一致性备份region服务器被作为JIRA-10070的一部分添加到HBase中。 结论和下一步 除下故障转移，HBase还存在大量其他的问题。仔细地检查了瓶颈的来源，进行了大量的优化后（比如使用同步垃圾回收机制），系统性能得到了显著提升：
通过HBase实验，我们将运行时响应时间缩短到原来的四分之一，并为将来提升留下了足够的发展空间。同时，更快的机器也有利于缩短响应时间。通过使用开源平台，我们认真思索来自多个提供商的意见，在中型数据处理上，我们可以看到很大的发展空间。 更重要的是，我们的收获不只是性能一个特性，我们更可以通过开源技术连接到一个更广泛的发展空间。 附录：HBase分配图解 性能1：分布和并行 |
