在数据库里试试这个笔记本介绍apachespark速度很快，但是诸如初步数据探索之类的应用程序需要更快，并且愿意牺牲一些准确性来获得更快的结果。从1.6版开始，Spark实现了一些常见任务的近似算法：计算一个集合中不同元素的数量，找出元素是否属于集合，计算大量数字的一些基本统计信息。来自Collective的尤金·朱列涅夫（Eugene zulenev）已经在这些页面上发表了关于近似计数在广告业务中的使用的博客。以下算法已针对数据帧和数据集实现，并已提交到Apache Spark的branch-2.0中，因此它们将在Apache Spark 2.0 for Python、R和Scala中使用：approxCountDistinct：返回不同元素数的估计值approxQuantile：返回数值数据的近似百分位数研究人员已经研究了这些算法很长时间了。Spark致力于实现确定性的近似算法（它们不依赖随机数来工作），并且已经证明了理论上的误差边界：对于每个算法，用户可以指定一个目标误差界，并且结果被保证在这个范围内，无论是精确的（确定性的误差边界）或是非常高的置信度（概率误差界）。另外，对于Spark社区中丰富的用例来说，该算法运行良好也是很重要的。在这个博客中，我们将详细介绍approxCountDistinct和approxQuantile算法的实现，并在Databricks笔记本中展示其实现。不同元素的近似计数在古代，想象一下，波斯和巴比伦的皇帝居鲁士，刚刚完成了对整个帝国的普查，他幻想着知道在他的帝国里有多少不同的名字，于是他让他的大臣来完成这项任务。大臣知道他的主人很不耐烦，他想尽快得到答复，即使只是一个大概的答复。不过，有一个问题，一些名字，如大流士，阿图萨或阿尔杜曼尼什很受欢迎，经常出现在人口普查记录上。简单地计算一下帝国内居住着多少人，答案很糟糕，皇帝也不会被愚弄。然而，维齐尔有一些现代而深刻的数学知识。他召集宫里所有的仆人，说："仆人，你们各人要从人口册上取一块泥版。对于刻有在石碑上的每个名字，您将取名字的前3个字母，称为l1、l2和l3，并计算以下数字：N=l1+31*l2+961*l3例如，你将得到达里乌斯=340，例如A=340。这将为每个平板电脑的名称提供一个编号。对于每个数字，您将计算结束此数字的0数。以侯赛因（N=17739）为例，这不等于零。当你们每个人都为他或她的平板电脑上的每个名字做了这些之后，你们会召集起来告诉我你们观察到的最大的0数是多少。现在你要急忙行事，不要计算错误，免得你受我的忿怒！"早上结束时，一个仆人回来，说他们发现了一个有4个0的数字，这是他们在所有人口普查记录中观察到的最大的一个。维齐尔随后向他的主人宣布，他是一个拥有1.3*10^4=13000个不同名字的人口的主人。皇帝对此印象非常深刻，他问大臣他是如何完成这一壮举的。维齐尔只说了一个字："超级日志日志"。HyperLogLog算法（及其在Spark中实现的HyperLogLog++变体）依赖于一个巧妙的观察：如果数字在一个范围内均匀分布，那么不同元素的计数可以从数字的二进制表示中最大数量的前导零近似。例如，如果我们观察到一个数字的二进制形式为0…（k次）…01…1，那么我们就可以估计集合中有2^k个元素的顺序。这是一个非常粗略的估计，但可以用草图算法精确到很高的精度。从上面的维齐尔和他的仆人的例子来看，这个算法不需要执行洗牌，只需要映射（每个仆人在一个平板上工作）和合并（仆人可以配对并决定哪个拥有最多的数量，直到只有一个仆人为止）。不需要到处移动数据，只需要对每个数据块进行小的统计，这使得它在诸如Spark这样的大型数据集设置中非常有用。现在，在现代，当数据集大得多，服务被替换为Spark集群时，这种技术的工作效果如何？我们考虑了一个由一家在线零售供应商提供的2500万条在线评论的数据集，并着手估算这些评论背后的客户数量。因为客户写了多个评论，所以它很适合近似的不同计数。以下是如何获得PySpark中用户的近似计数，在真实值的1%以内，并且概率很高：用户：数据帧[用户：字符串]用户。选择（approxCountDistinct（"用户"，rsd=0.01））.show（）此图（图1）显示了不同客户的数量如何随误差幅度而变化。正如预期的那样，随着所请求的误差范围的减小，答案变得越来越精确。图1计算需要多长时间？对于上述分析，此图（图2）显示了相对于要求精度的近似计数的运行时间。对于超过1%的错误，运行时间只是计算准确答案的一小部分。然而，对于精确答案，运行时间增加得非常快，最好直接计算精确答案。图2总之，在使用approxCountDistinct时，应记住以下几点：当请求的结果误差很高（>1%）时，近似离散计数非常快，返回的结果只需计算精确结果的一小部分。实际上，对于20%或1%的目标误差，性能基本相同。对于更高的精度，该算法遇到了困难，开始比精确计数花费更多的时间。近似分位数分位数（百分位数）在很多情况下都很有用。例如，当一个web服务正在执行大量请求时，了解诸如请求延迟之类的性能细节是很重要的。更一般地说，当面对大量的数字时，人们通常会对一些聚合信息感兴趣，比如平均值、方差、最小值、最大值和百分位数。另外，只需有极值分位数也是很有用的：前1%，0.1%，0.01%，等等。Spark实现了一种源于流数据库社区的健壮的著名算法。与HyperLogLog一样，它在每个节点中计算一些统计信息，然后在Spark驱动程序上聚合它们。Spark中的当前算法可以进行调整，以牺牲计算时间和内存的精确度。基于与前面相同的示例，我们查看每个评论中的文本长度。大多数评论者用几句话来表达自己的观点，但也有一些客户是多产的作者：数据集中最长的评论超过1500字，而有几千篇单字评论，语法自由度各不相同。我们在这里绘制（图3.）回顾的中值长度（第50百分位）以及更极端的百分位。这张图显示很少有非常长的评论，而且大多数评论都在300个字符以下。图3近似分位数的行为与HyperLogLog相同：当要求在精确答案的百分之几以内进行粗略估计时，该算法比精确计算要快得多（图4）。为了得到更精确的答案，有必要进行精确的计算。图4结论我们演示了approxCountDistinct和approxQuantile算法的实现细节。虽然Spark的速度很快，但有时探索性数据应用程序需要更快的结果，而牺牲了准确性。这两种算法的执行速度更快。ApacheSpark2.0将包含一些最先进的近似算法，以获得更快的结果。用户将能够在快速、不精确的答案和较慢、准确的答案之间进行选择。你想看看其他的近似算法吗？告诉我们。这些算法现在在Databricks笔记本中实现。要亲自尝试，请在这里注册一个Databricks帐户。进一步阅读使用Spark和HyperLogLog进行交互式受众分析apachespark笔记本中的近似分位数免费试用Databricks。今天就开始吧