性能2：同址计算 即使故障得以解决，在原始性能和一致性上仍然存在问题，这里我们将详述性能上的3个实验和结果。实验应用在一个合适的集群上，拥有11台搭载SSD的主机，每台主机配备了两个志强E5处理器以及128GB内存。在讲义的右上角显示了两个数字，第一个是实验初始时的平均响应时间，另一个则是进行改进后的响应时间，平均请求时间来自20万个记录上做随机的键值查询。 使用HBase，用户可以在大的Portfolio文件上做拆分，并且分配到集群中的多个主机上进行处理。这也是为什么要托管备用的region服务器以应对故障——如果请求发送到每个服务器，其中一个服务器在1分钟或者更多的时间内没有反应，很明显这个服务器已经出现问题，一个服务器产生故障将拖累集群中所有作业的处理时间。 因此，下一个需要着重对待的就是分配和并行。第一个工作就是如何平均的将作业拆分：在一个指定的大数据集上，集群中每台机器获得的chunk大小都是相同的？理想状态中，对1000行的数据进行拆分，每台服务器都应该获得100行。然而在一个简单的架构中，这点根本无法实现：如果原始键是债券名+XXX，那么所有IBM债券将放在同一个region中，同时，IBM将比其他债券更经常得到访问，这种现象也被称为hotspotting。 解决方案是使用HBase提供的特性来弥补。HBase中的数据总会通过原始键进行物理划分，如果原始键本身已经被哈希，同时这种哈希被作为一个前缀，随后行则会以不同的方式进行分配。想象一下，如果原始键是security+year+month+field，取它的MD5，并将之作为一个前缀，那么IBM这个债券分配到任何服务器上的可能性都会相同。 在一个完美的分配中，我们将获得一个完美的并行性：集群中11个节点都会做相同数量的作业。每个工作不只是负责相同的工作量，在每个请求上也会同样平均。毫无疑问，这里需要做的是尽可能地提升系统并行性。 解决这个问题的一个方法就是在每台主机上运行尽量多的region服务器，因此需要尽量提升主机的性能。这将提升总的region服务器数量，从而提升并行性的等级，随之显著的减少响应时间。 讲义中的图表显示了这个实验的结果。如果11台服务器上每个只搭建一个region，总计11个，平均响应时间是260毫秒。当region数量提升到每台主机3个时，也就是总计33台主机，平均响应时间将下降到185毫秒。每台主机上5个region服务器将提升到160毫秒。但是如果每台主机上的region服务器提升到10个时，响应时间反而会提高，为什么？ 出现这种问题后，首先想到的可能就是负载是否超过了服务器的性能；每台服务器同时运行10个region服务器进程，每个都拥有多个线程，显然核心数量会不足。但是，根据研究，这个并还不足以作为影响系统的原因，真实的答案非常有意思，但是在揭开它之前，我们先看一下同址计算。 大数据的原理之一就是让计算尽可能的靠近数据，这么做的理由非常简单。举个例子，如果你想知道一个大数据集表格中究竟有多少行，你可能需要将每一行都取到本地客户端，然后循环访问并进行计算，如果使用的是传统数据库环境，你还可以使用“select count(*) from…”，后者显然是更加有效的。 说永远比做容易。许多问题使用这个途径是无法解决的，即使在许多已知的情况下，许多框架都会出现问题。在海量数据分析上，2013年National Research Council（国家研究委员会）提出了7个大型并行计算问题，希望对分布式计算系统进行良好的分类，比较有意思的是，根据测算结果，Hadoop并不适合所有类型。 幸运的是，我们有一个简单的可用的用例，它可以再次减半响应时间。 现在的情况是，这里有数据的多个源，Barclays、Merrill Lynch和多个公司都提供了债券计价数据。相同债券同一天的数据也可能出现在其他源中，但是价格可能不一致。每个客户有不同的优先顺序，每个请求都包含了某个源应该用在某个订单的顺序。尝试从第一个数据源中获取所有数据，如果发现丢失，则会尝试下一个源。通常情况下，发现所有数据需要访问5个这样的数据源。 在分离数据库世界中，不同的源都处于不同的地理位置中，这就意味着尝试第一个数据库，取得所有的数据，查询丢失了什么，构成一个新的请求，并发布下一个任务。 对于HBase，我们仍然可以获得物理分类的优势，支持上千万列，并通过协同处理器进行同址计算。 通过将源和字段列与security和date整合，它们将被混搭在相同的region服务器上 。协同处理器的逻辑将变为“为指定行发现第一个源，并进行security和date匹配”。 在一个只包含一些行的小协同处理器上，平均响应时间将降到85毫秒。 性能3：同步中断 继续上文的话题，增加region服务器数量降低性能给我们留下的谜题：为什么响应时间在开始时有改善，而随后则会变得更糟糕？问题的答案涉及到两个方面——Java和所有高fan out分布式系统一些常见的问题。 一个涉及到不止1个fan out的请求中，服务器访问越高，fan out的程度就越高。那么，在一个有fan out的请求中，响应时间该如何计算？ 答案就是，响应的时间由最慢的反应者决定，当给11台主机每个都配备10个region服务器时，每个请求需要fan out 110个进程。如果其中109个是1毫秒完成，1个请求是170毫秒，那么响应时间将高达170毫秒。 这里的罪魁祸首毫无疑问就是Java的垃圾回收机制，它会冻结一个机器直到回收结束。Fan-out的程度越高，其中一个region服务器在做垃圾回收的可能性就越大。当region数量达到110个时，可能性已经开始接近1。 这里的解决方案非常的简单。既然在垃圾回收过程中所有的服务器都会被冻结，那么为什么不让这些region服务器同时做垃圾回收？这种情况下，请求将需要更多的时间，但是毫无疑问的是，在处理的过程中，没有region服务器会做垃圾回收。为此，我们编写了不能再简单的代码进行测试——system.gc()以及30秒会调用一次这个方法的定时器。 通过这个操作，我们首次将相应时间从85毫秒降低到60毫秒。 Java垃圾回收机制这个诟病已经被广泛认知，这也是Jeff Dean归纳为Synchronized Disruption中的一个问题。任何并行系统中的请求都需要遭受最慢者的摧残，因此影响个体机器的问题将同时影响到整个系统。想获得更多详情，推荐阅读“Achieving Rapid Response Times in Large Online Services”，你将获得更多关于高fan out计算系统的使用经验。 这就意味着，Java当下已经成为很多高fan out计算系统的基础，其中包括Hadoop、HBase、Spark、SOLR等，同步进行垃圾回收将解决非常大的问题。 原文链接： The Big Problem Is Medium Data （翻译/童阳） |
