这是一个来自simsim Simeonov的博客，他是Swoop的创始人兼首席技术官综合项目管理人工智能.预聚合是高性能分析工具箱中的一种常用技术。例如，每小时100亿行的网站访问数据可以减少到1000万行访问计数，按常见查询中使用的维度超集进行聚合，数据处理量减少1000倍，处理成本和等待任何查询结果的等待时间也相应减少。进一步的改进可以通过计算更高级别的聚合来实现，例如，按时间维度中的日或按站点而不是按URL计算。在本博客中，我们介绍了开源库spark alchemy的高级超日志功能，并探讨了它如何在规模上解决数据聚合难题。但首先，让我们来探讨一些挑战。重新聚集的挑战预聚合是一种强大的分析技术…只要计算的度量是可重新聚集的。在字典中，聚合有聚合，所以把可重聚合发明为具有聚合可以进一步重新聚合的属性是一个小小的扩展。计数用和重新聚集，最小值用最小值，最大值用最大值，等等。奇数是不同的计数，不可重新聚集。例如，由于重复计算，每个站点的不同访问者计数之和通常不等于所有站点的不同访问者计数：同一访问者可能访问多个站点。不同计数的不可再聚集性具有深远的影响。计算不同计数的系统必须能够访问最细粒度的数据。此外，返回不同计数的查询必须接触每一行粒度数据。当涉及到大数据时，不同的计数带来了另一个挑战：在计算过程中，它们需要与被计数的所有不同值的大小成比例的内存。近年来，大数据系统（如apachespark）和面向分析的数据库（如Amazon Redshift）引入了使用HyperLogLog（HLL）概率数据结构进行近似离散计数（即基数估计）的功能。要在Spark中使用近似的非重复计数，请将COUNT（distinct x）替换为approach_COUNT_distinct（x[，rsd]）。可选的rsd参数是允许的最大估计误差。默认值为5%。Databricks的HLL性能分析表明，只要最大估计误差为1%或更高，Spark的近似离散计数可以使聚合的运行速度比使用精确计数时快2-8倍。然而，如果我们需要一个较低的估计误差，近似的不同计数实际上可能比精确的不同计数需要更长的时间来计算。查询执行时间减少2-8倍本身就是一个实质性的改进，但是它的代价是估计误差为1%或更高，这在某些情况下可能是不可接受的。此外，与通过预聚集获得的1000倍增益相比，不同计数的2-8倍减少增益相形见绌。我们能做些什么？重温超日志答案在于HyperLogLog算法的核心。在分区的MapReduce伪代码中，Spark处理HLL的方式如下：地图（每个分区）初始化HLL数据结构，称为HLL草图将每个输入添加到草图发射草图减少将所有草图合并为"聚合"草图完成从聚合草图计算近似的非重复计数请注意，HLL草图是可重新聚集的：当它们在reduce操作中合并时，结果是HLL草图。如果我们将草图序列化为数据，我们可以在预聚合中持久化它们，并在以后计算近似的不同计数，从而获得1000倍的收益。这太大了！还有另一个更微妙但同样重要的好处：我们不再受实际要求的约束，即估计误差不超过1%。当预聚合允许1000倍的增益时，我们可以很容易地用非常非常小的估计误差来构建HLL草图。如果在查询时有1000倍的增益，那么预聚合作业的运行速度会慢2-5倍，这是很少见的问题。这是我们在大数据业务中所能得到的最接近免费午餐的地方：在大多数用例中，从业务的角度来看，这是一个巨大的成本/性能改进，而没有负面的权衡。介绍火花炼金术：HLL本地函数由于Spark不提供此功能，因此Swoop开源了一套丰富的原生（高性能）HLL功能，作为Spark炼金术库的一部分。看看HLL文档，其中有很多示例。据我们所知，这是最丰富的大数据超日志处理功能，甚至超过了BigQuery的HLL支持。下图演示了spark alchemy如何处理初始聚合（通过hll_init_agg）、重新聚合（通过hll_merge）和表示（通过hll_基数）。如果您想知道HLL草图的存储成本，简单的经验法则是HLL基数估计精度的2倍提高需要HLL草图的大小增加4倍。在大多数应用程序中，行数的减少远远超过由于HLL草图而增加的存储量。错误以字节表示的草图大小0.005437020.01109330.0227410.0313770.046930.053530.063530.071810.081810.091810.196超日志互操作性从精确到近似的不同计数的转换以及将HLL草图保存为一列数据的能力消除了在最终查询时处理每一行粒度数据的需要，但我们仍然需要一个隐含的要求，即使用HLL数据的系统必须能够访问所有粒度数据。原因是没有针对HLL数据结构序列化的行业标准表示。大多数实现，如BigQuery的，使用未记录的不透明二进制数据，这些数据不能在系统间共享。这种互操作性挑战大大增加了交互式分析系统的成本和复杂性。交互式分析系统的一个关键要求是非常快的查询响应时间。这并不是Spark或BigQuery等大数据系统的核心设计目标，这就是为什么交互式分析查询通常由一些关系数据库或（在某些情况下）NoSQL数据库执行。如果没有数据级别的HLL草图互操作性，我们将回到原点。为了解决这个问题，在spark alchemy中实现HLL功能时，我们特意选择了一个HLL实现，该实现具有已发布的存储规范，并内置了对Postgres兼容数据库甚至JavaScript的支持。这使得Spark可以作为一个通用的数据预处理平台，用于需要快速查询周转时间的系统，例如门户和仪表板。此体系结构的好处非常显著：99%以上的数据仅通过Spark管理，没有重复在预聚集期间，99%以上的处理通过Spark进行交互式查询运行得非常快，需要的资源也少得多摘要总之，我们展示了如何使用超日志数据结构将常用的预聚合技术有效地扩展到不同的计数，这样不仅可以在处理速度上获得1000倍的潜在收益，还可以让我们在Apache Spark、rdbms甚至JavaScript之间实现互操作性。很难相信，但我们可能已经在一篇大数据博客文章中获得了两次免费午餐，这一切都是因为HLL草图的强大威力和Spark强大的可扩展性。高级HLL处理只是火花炼金术的优点之一。看看接下来会有什么，告诉我们清单上哪些项目对你很重要，还有哪些项目你还想看。最后，但绝对不是最不重要的，Swoop的数据工程和数据科学团队要感谢Databricks的工程和支持团队与我们合作，重新定义Apache Spark的可能性。你真厉害！免费试用Databricks。今天就开始吧