实时预测大规模使用湖和δ缓存

视频记录

——好吧,欢迎在2020年引发+人工智能峰会。我的名字叫Jatinder Assi博士。我在GumGum管理数据工程团队。我的co-speaker Rashmina梅农。她是一个GumGum数据工程师。今天我们将讨论实时预测大规模使用湖和δ缓存。

好了,那么我们开始吧。只是对GumGum简单介绍。所以我们是一个AI公司。我们位于圣莫尼卡,加利福尼亚州。

我们的分歧

所以我们的分歧是广告,我们利用计算机视觉和NLP技术检测到不安全的文本和图像,允许我们在一个品牌提供广告和上下文相关的环境安全。

我们的第二个词的目标是运动估值,我们帮助营销人员和媒体持有人获取完整的媒体价值的赞助在广播电视、流媒体和社交媒体。

我们今天将覆盖的议程是一个程序化的库存介绍高水平概述、程序化的库存看起来和我们讨论的范围。然后我们将讨论架构实时预测。然后我们将讨论数据抽样方法。然后Rashmina将接管。她会谈论搜索和预测应用程序中,数据缓存与三角洲和预测精度。

编程库存介绍。所以让我们来谈谈什么是广告库存。

房地产广告目录显示潜在的广告发布者页面

这是一个房地产展示潜在广告发布者页面。一个广告可以不同的形式和不同的格式和似乎在不同的格式像移动,桌面和web浏览器。

程序化的广告生态系统

所以让我们来谈谈编程广告生态系统。这是一个技术生态系统自动买卖目标实时在线广告。

所以频谱的一边,我们有出版商。这是一些与我们合作的出版商或产生高质量的内容。

另一方面,我们有广告商。这是我们工作的一些品牌,谁正在寻找符合成本效益的方式,地方媒体购买。

所有的广告商与需求方集成。这些需求方面的合作伙伴。bob体育外网下载这是一些流行的GumGum作品的需求方面的合作伙伴。bob体育外网下载这些合作伙伴会参与投标代表广bob体育外网下载告。

所有的需求方与广告合作交流。GumGum实际上是我们交易所拍卖将会发生。

所以在拍卖期间,出版商将提供库存拍卖,所有的需求方投标库存。无论谁赢得了竞标,将会显示广告。

为什么预测库存?

好吧,那么让我们谈谈为什么预测库存。所以我们的卖家正在试图建立广告活动有一定的目标规则和想知道GumGum出版商网络有足够的库存来满足它。我们也想提供更快的响应时间将允许我们的卖家进行迭代,建议和销售广告更快。

让我们看看一些场景。这是一个场景,我们想要预测库存可用在美国城市洛杉矶和圣地亚哥从高端网站在接下来的30天。这是一个场景。另一个场景可能是预测库存在美国和加拿大或页面相关的体育和娱乐类别,针对25 - 40岁的男性。

大规模库存预测

所以让我们来谈谈。

正如我提到的,为了预测库存,我们的目标是能够建立成功的运动通过生成实时预测的库存。

所以我们这里讨论的是规模大约每天得到300亿+编程库存。我提到我们有程序化的生态系统。这相当于每天约25 tb压缩数据。

我们的目标是能够提供预测的平均响应时间为30秒。

现在让我们进入架构。

好吧,那么所有的数据库存坐在S3的原始格式。所有这些数据在Avro格式。第一个模块是数据变换。这是一个火花模块,我们会阅读每一天,25 + tb的数据应用。Azure应用转换,这是非常清洁,准备,然后应用业务规则来转换这些数据。转换完成后,我们将实际运行采样算法在分布式时尚的火花。我们将大大降低的数据量。

下一个模块将浓缩。所以从每天我们有样品后,我们将丰富的样品。丰富的数据通过DynamoDB和MySQL数据集。提供浓缩,所有的数据都缩小到抽样浓缩后,数据被减少到每天大约1.5演出在三角洲格式将所有数据存储在三角洲湖每天。Rashmina将细节为什么我们选择三角洲格式,和三角洲湖。

体系结构

所有这些都是封装在一个每日数据管道。这些模块都是火花模块和他们每天运行在气流。

假设一个用户准备预测定位技巧。所以他们会去我们内部仪表板。内部内部仪表板将搜索查询。它是一组火花模块将基于用户搜索样品卡地亚或通过365天。搜索模块将样品过去365天。一旦我们得到过滤器样品,然后我们将应用预测模型。这是一个基于“增大化现实”技术的模型运行在火花司机,这意味着我将去详细你最终用于时间序列预测模型。一旦我们应用预测模型,我们将得到预测结果,我们将显示用户在内部仪表板。

所以端到端实时预测此体系结构中,我们能够在30秒内得到响应时间在25 tb的数据我们每天过程减少到1.5演出并运行这个预测过去365天。我们可以在30秒内响应时间。

好了,现在让我们来谈谈数据抽样。

为什么抽样?

那么,为什么样品吗?这是一个很明显的问题。所以我们不想浪费很多计算处理的所有库存过去365天,将北九pb的数据。也很难达到30秒的预测响应时间即使是最预测模型进行了优化。

所以,我们可以预处理,使用经销商的印象每天抽样的方法来捕捉最相关子集库存数量。所以我的意思是这里的大圆是实际库存和小圆是捕获所有相关子集的库存和样本数据集。

抽样的方法

因此采样方法。

假设我们的用户想要查询一个数据,通常一个样本的方法,你将去一个基础数据,查询基础数据和你会得到准确的结果。在抽样的情况下,我们将生成一个样本数据是基于从这里使用抽样算法。因此,当用户想要查询,查询样例数据。

一旦用户查询样例数据,我们将使用一个估计量是一个扩大的因素也是生成作为样本数据的一部分。您将使用这个规模估计结果返回到原始数据集。因此用户查询样例数据,我们使用规模估计结果。所以结果接近准确的结果,但我们会得到近似的结果将接近准确的结果。

类型的抽样

所以让我们来谈谈类型的抽样。所以最常见的抽样是均匀采样。这就是有一个平等的概率选择任何特定项目。这里的问题是,它将会偏向常见物品所以这不是伟大的频率上限。

频率上限的一个关键因素是GumGum服务广告,我们经常不显示广告相同的用户。

我们的标准可能是一组频率上限后一个小时,一天一次。我们不确定相同的用户并添加超过一天一次或超过一次一个小时的频率上限。所以我们最终使用稍微修改版本,这是不同的项目抽样。在这种方法中,我们仍将样品均匀但从不同的项目来支持频率上限的用例。所以在这种情况下,不同的项目在我们的用例,将是,我们可以识别不同的用户的用户ID散列的用户。

这里算法我使用是增强min-hash抽样截然不同的项目,我们将< =米不同的物品或样本。

AMIND取样日常工作

好吧,那么让我们谈谈抽样日常工作。

抽样是瘫痪单独每一个小时,然后单独的时间结合形成日常样品。让我们看看它的样子。

我们有所有这些橙色桶作为我们的原始数据。我们坐在S3真实数据。然后在火花,我们会耗尽所有这些并行处理所有这些小时并生成样本小时。所以所有的红桶都是实际样本数据每一小时米不同的散列值。

然后我们将在所有这些团体,我们真正的样本的散列值并生成pre-daily样本。

一旦我们pre-daily样品,然后我们将排序最小的散列值并单击到米每天生成一个样本。我们也将使用这种算法生成一个扩大的因素将在后面使用相关样本的结果回原始数据集。

AMIND取样日常工作并行宠物haus和每小时的样品相结合

好了,那么下一步将Rashmina。她会谈论搜索和预测应用。

——由于Jatinder。博士所以我要忙于搜索和预测应用。

让我们看一看(模糊)。

搜索和预测

某些预测的应用程序从左到右。我们在左边,有一个用户提交一个请求预期从仪表板。有一层薄薄的API,它连接用户搜索和预测应用。这个API层的功能是将火花工作使用砖工作的API,让火花的结果返回工作,还给用户。让我们来谈谈搜索和预测应用。

因此,搜索和预报应用软件,顾名思义,有两个组成部分。搜索应用程序和预测应用。我将详细讨论这些应用程序。但是搜索应用程序和预测应用程序放在一起在30秒内完成。SLA,我们一定会实现。让我们放大搜索应用程序。

这个应用程序的目标是读过去365天的样本数据以及用数据。

搜索应用程序

过滤器根据用户输入样本数据,然后生成时间序列的形式每天印象。但数量的印象是数量的样本印象倍。这是一个重要的问题,搜索应用程序读取数据从哪里来的呢?这需要我们下一张幻灯片,数据缓存。

缓存来缓存?

重要的问题是我们是否应该缓存数据缓存数据?如果我们确实是缓存数据,我们应该使用的技术是什么?

假设我们不缓存数据,假设每一个预测的要求,我们正在阅读数据直接从S3,当然可以。我们不会有太多的过去,但这是非常缓慢的。我们不能保证SLA。所以我们需要缓存数据。我们正在引发,所以我们都知道火花作品在内存缓存。这是闪电快但是你这里的目标是,我们需要一个庞大的集群缓存整个数据在内存中,特别是对于我们在扩大。还记得,每天采样管道运行一次。所以我们必须每天刷新这在内存中缓存,这有点乏味。我们有备用的选择是什么?显而易见的选择是讨论。 This as we know is cheaper than memory. Using discussion also means that we could utilize memory for compute. Which is great. But coming to the point, it’s not very efficient. This so, that if we were to use disk cache, we will at least need 35C for direct slash nodes. The question is, can we do better? Can we reduce the number of instances so that we can reduce the cost? Now similar to in-memory caching, disk cache also needs daily refresh. So let’s come to the question, can we do better than discussion? The answer is yes. Although this is (indistinct) with Delta cache.

三角洲湖

刷新一下三角洲湖。三角洲湖是一个开源存储层ACID事bob下载地址务引发。基本的想法是,流应用程序和批处理应用程序可以编写三角洲湖。您可以使用云存储,无论你使用,可能你使用AWS S3和分析和机器学习应用程序可以无缝地从三角洲湖读取,而不必担心LinkedIn的ACID属性。三角洲湖工作事务日志的概念。所以在三角洲湖保持事务日志的记录每一个三角洲湖上发生的事务。所以当采样数据管道写三角洲湖,表已经意识到已经有新数据可用,它会自动刷新底层表,这是伟大的。

三角洲湖(续)。

三角洲湖是非常简单。一般来说,当我们写数据帧,我们正在使用指定的格式选项,是否会包JSON tsp。我们为三角洲湖做同样的事情。我们指定三角洲作为一种格式。现在我们知道我们使用的格式,让我们来这个问题,什么是缓存层,我们可以使用?我们将使用的缓存层是δ缓存数据砖。

三角洲缓存

三角洲缓存数据砖基本上是磁盘缓存但它支持加速数据速率通过创建本地存储的远程文件复制节点使用一个快速的中间格式。这快中间格式是速度比磁盘缓存。

i3三角洲缓存是默认启用。超大实例,我们使用我们的用例。现在,当我们开始使用一个集群,三角洲启用缓存,我们从三角洲湖开始阅读。我们可以看到有趣的统计数据在存储选项卡下在聚光灯下。我们可以看到多少从S3读取数据,我们可以看到多少数据读取到缓存,多少数据是反复阅读等等。所有这些参数以后帮我们调优应用程序。

让我们看得到的常用命令用于创建表和使δ缓存。所以创建一个增量表是非常简单的。我们可以使用CREATE TABLE语句。我们可以点到S3位置和完成。我们有样品数据表创建。

现在缓存三角洲湖到集群中,我们使用缓存命令,其次是select语句。示例样本中缓存数据,我们得到了在过去的365天,因此“阶级”这个词。

刷新缓存相关的表,我们使用refresh table语句。

现在让我们看看我们使用的常用命令运行维护操作延迟。

所有重要的命令是优化命令。现在所有人的火花,我们知道是多么重要的文件大小正确。是多么重要的文件数量正确。为这个特定的用例优化命令是非常方便,因为命令将文件解压缩到一个紧凑GB文件大小。我们也可以指定ZORDER将搭配相同的信息在同一组文件。

现在已经删除压缩文件,我们可以运行备份命令。

分析表的命令也是同样重要的。分析表命令将帮助查询分析器收集统计信息的表将帮助查询被执行。现在你怎么经常运行这些命令取决于你的用例,但是对我们来说,我们每一天运行这些命令。

缓存不Ta缓存吗?zz

所以回来的问题,是否缓存缓存,我们有一个答案。我们使用的是三角洲湖,三角洲缓存。因为δ缓存到磁盘缓存,但增加性能类似,我们得到一个机会利用内存计算。这也是我们确定最便宜的选择。记得要提醒你,我们使用磁盘缓存35 c直接削减节点。现在,湖和δ缓存,我们可以减少到20 ITF削减节点。所以从成本的角度来看,这个伟大的工作。在一个警告是热身查询可以花费更多的时间如果你不刷新缓存。

搜索应用程序(续)

这是基本的搜索应用程序体系结构的样子。火花等应用程序商店,读取数据缓存集群。缓存层基本上是δ缓存数据砖。我们使用的数据格式是三角洲湖三角洲湖数据存储在S3。

让我们重新审视整个工作流再次搜索和搜索应用程序。

所以第一步是过滤用户发票的样本数据。所以基本输入的日期选择器提供了一个产品和数据分区键为S3数据。这里做第一级过滤通过应用所使用的部分,应用过滤用户输入基于分区键。

第二步是根据其他用户进一步过滤数据输入。例子将国家、BrowserType第三方部分,页面类别等等。我们有15到16用户输入,用户可以输入通过仪表板。

最后一步是聚合,生成时间序列数据。如果存在频率上限,可以在频率的印象卷数量差距。后,我们总该数据建立时间序列的形式每天印象。

我们把样本数量的印象与乘数预计印象。这是所有的搜索应用程序。让我们继续下一个搜索和预测应用程序的一部分,这是一个预测的应用程序。

预测的应用

预测的目标应用程序预测的时间序列N天基于时间序列的趋势在过去的365天。所以我们知道搜索应用程序吐出一个时间序列在过去的365天。我们的目标是生成预测下N的天数。

预测应用程序(续)

我们的时间序列预测模型是用R和我们用ARIMA作为基础模型。华宇电脑只不过是自回归综合移动平均线。这是一个非常受欢迎的和共同的时间序列预测模型。它是用于描述数据的自相关。和我们使用的是一个非季节性的变体。但这里有一个重要的问题。形式的目标规则,用户可以输入活动将不同的前一天活动b,那么我们如何使用相同的ARIMA模型进行不同的趋势?

所以,我们试图回答的问题是,我们如何为不同的用户输入,生成不同的ARIMA模型在不同的时间序列结果。为此,我们使用汽车ARIMA。所以汽车ARIMA发现最好的给定时间序列ARIMA模型。所以对于一个给定的时间序列X,如果目标路线是完全不同的从另一个时间序列y我们得到不同的模型,因为汽车ARIMA找到不同的参数来适应这个时间序列。

让我们看看其它模型,我们使用我们的预测。对我们所有人来说,一个应用程序,我们知道,从季度季度趋势非常显著活跃。内容对我们来说是非常重要的是季度趋势,数据我们或交通趋势,第一季度我们是完全不同于主要竞争第四季度的数据。所以季度趋势是非常重要的。我们捕获的季度趋势使用正弦曲线。我们还捕捉到副总裁使用正弦曲线趋势。

汽车ARIMA,每周趋势,季度趋势放在一起结合了我们使用的基本预测模型。我们司机节点上运行预测模型和平均预期执行时间小于2秒。你可以想象在第32 SLA,所采取的大部分时间搜索应用程序因为自己预测的应用程序是非常快,即使它只运行在司机节点上。

假设这里的黑线代表实际的和蓝线代表一个预测。我们怎么知道如果预测实际上是不够好。当然,我们必须衡量预测的准确性。

衡量预测的准确性

我们计算预定义的预测的平均绝对百分误差要求。正如我前面所提到的,我们有50到60定位工具,用户可以输入通过仪表板。所以我们很难生成所有的排列组合输入,用户可以输入。所以我们预定义的某些预测请求从自己这是非常普遍的。我们计算这些预测的平均绝对百分误差请求时间。因此,平均绝对百分误差在实际被定义为一个错误。所以在这里代表实际,F代表预测。我们计算实际-预测,这是错误的,我们除以实际得到的平均水平和观察,平均绝对百分比误差。所以我们每天计算平均绝对百分比误差为这些预定义的预测要求。我们确保这不会超过阈值,我们想要达到的目的。 And for now, we have been, we have never got alerts for the longest time, so we know that the model is really functioning well. So that’s all about our forecasting application.

谢谢你聆听我们的演讲。