在这个世界上，大多数分析产品都侧重于ad-hoc分析，这需要查询灵活性而没有保证延迟，或具有有限查询能力的低延迟分析。在这篇博客中，我们将探索如何使用Apache Pinot和Presto获得两个世界上最好的。

今天的妥协：延迟与灵活性

让我们暂停一步，看看我们如何分析具有不同权衡的数据。

灵活性需要时间

> Salvador Dali, The Persistence of Memory (1931)

让我们假设你的原始数据托管在可使用Spark / Hadoop计算作业或SQL引擎的数据湖中托管。

在这种情况下，用户可以充分灵活地访问所有数据，选择他们想要的任何数据，并应用他们需要的任何计算。

但是，检索结果需要很长时间，因为从数据湖（S3 / HDFS 等）读取原始数据，并且计算按需推出（以ad-hoc方式）启动。

在Presto上拍摄这个简单的例子：电子商务业务有一个用户信息的维度表（100k行，格式 <customer_id, name, gender, country, state, city, …>）以及用户订单的事实表（10亿使用格式 <order_id, date, customer_id, items, amount>）行。

要查找加利福尼亚州所有女性客户的月销售，我们需要编写一个SQL查询来联结两个表，然后聚合结果。

此查询执行有4个阶段：

表扫描阶段扫描来自两个表的数据：使用列的表订单上的一个完整扫描：<date, customer_id, amount> 以及表客户的另一个完整扫描，以获取所有匹配的<customer_id，city>给定谓词<state = ‘California’ AND gender = ‘Female’>。连接阶段根据Customer_ID从两个表中shuffles数据。逐个阶段再次基于<orders.date, customers.city>，然后汇总订单金额的数据库数据。减少阶段收集所有组的结果，并使最终结果呈现。

数据shuffling阶段主要贡献到查询延迟，包括数据分区，序列化，网络I / O，反序列化。

ETL为低查询时间交易数据新鲜度

为了优化查询性能，ETL可以被使用。在ETL作业中，用户可以将事实表预连接到维度表，然后在ETL之后的表上查询它。

预先联结的表

在上面的示例中，我们可以将Users表和Orders表预连接到新表user_orders_joined（它与schema转换为1亿行：<order_id, date, customer_id, amount, gender, state, city>）。

然后可以直接在此表上写入上述查询：

在这种情况下，我们可以计算与订单金额相关的度量，并在用户尺寸（如性别，位置和时间）上进行切片和切割。例如，洛杉矶男性客户每月订单的平均订单数量是多少。

预先联结表的缺点是查询时间仍然与扫描的行总数成比例。在上面的例子中，如果有100万行与WHERE state = ‘California’ AND gender = ‘Female’ 匹配，那么返回1百万最终结果。

预汇聚表

来自上述方法的明显改进是预聚合我们要查询的结果，例如，我们可以创建一个新的表User_orders_aggregated，其中包含字段：<date, gender, state, city, sum_amount, sum_sold_items, avg_amount, …>。假设每月有100万个独特的日期/性别/位置组合，预聚合后的记录总数可能会减少到1200万行（一年的数据）。

在这种情况下，我们基于用户维度（性别，位置等）和订单日期进行预聚合数据。然后，对于每个组合，我们还计算所有对应的度量标准。

所以我们可以重写上述查询：

在此查询中，我们所做的添加数量只是此表中的日期数。

与以前的方法相比，预聚合减少了很多运行时查询工作负载。但是，它仍然需要一些运行时聚合。扫描的记录数量与表中的非组的基数乘法成比例（谓词之后）。

立方体表

Pre-cubing是实现常量查询延迟的解决方案。用户可以根据所有尺寸组合预先计算我们对我们感兴趣的所有指标，因此对于任何查询，它将始终是一个确切的行来回答它。对于上面的示例，我们可以创建一个新表user_orders_cubed（带字段的100万行：<date, month, gender, state, city, sum_amount, avg_amount, …>）

所以可以重写上述查询：

Pre-cubing解决方案的缺点是数据集大小是所有尺寸基数的乘法。如果我们添加具有10的基数的新维度，那么行数将是十次。这种方法不会与数据尺寸的有机生长和尺寸的数量扩展。

如何使用Apache Pinot进行权衡

Apache Pinot是LinkedIn构建的OLAP数据存储，用于低延迟分析。

这里，低延迟本身指的是低摄入延迟以及低查询延迟。

对于低摄取延迟，Pinot可以直接从流数据源（Apache Kafka / Kinesis）中消耗，并且事件将立即查询。除了Kafka之外，Pinot可以使用HDFS，Amazon S3，Google云存储和Azure Datake存储等BLOB商店本身批量加载数据。Hadoop和Spark作业周围还有库，用于使用外部计算资源进行数据引导或常规摄取。

Pinot已经实现了多个索引技术，如排序索引，反相索引，布隆过滤器，星形树索引，以加快低查询延迟的查询。

Pinot也被Uber，Weibo等许多公司广泛采用，用于用户面向用户的应用，业务分析和异常检测用例。

在生产环境中，Pinot处理每秒数百万个事件的工作量，并每秒提供数千个查询，并具有毫秒级别延迟。

Apache Pinot提出了一种创意解决方案，通过引入星形树索引来优化上述部分中的方案3，这允许用户配置扫描的最大行以应答查询（超出哪个结果是预聚合的）。因此，用户可以在执行时间和存储空间要求之间找到良好的平衡[1]。

资源

接下来，我们将讨论如何集成Presto和Pinot以解决与Presto和Apache Pinot的实时分析中的这个问题。此外，随身携带跳转到Pinot Kubernetes QuickStart [2]在实践中部署Presto和Pinot。

请访问Apache Pinot网站和文档以获取更多信息和教程。

请加入Apache Pinot Slack for News，问题和讨论。

请加入Apache Pinot Meetup组，以获取未来的事件和技术会谈！

第二部分实现最佳：Presto Pinot连接器

从本系列的第一部分继续，我们现在将专注于Presto Pinot连接器。下图显示了Presto和Pinot之间的延迟与灵活性折衷。

> Latency vs. Flexibility vs. Throughput

在Presto中，用户越来越希望支持灵活性：全面的SQL支持，能够进行多路联接。但是，查询可能需要几秒钟才能从延迟角度返回，具体取决于数据量。

在世界的另一边，Pinot用户可以从原始数据存储到预先加速/预聚合的，甚至与高级索引技术一起加速查询。Pinot查询引擎可针对那些分析查询模式进行优化，如聚合/群组。Pinot提供切片和切割的灵活性，同时保持低查询延迟。但是，由于缺乏完整的SQL支持，Pinot不够灵活。

需要加速presto查询速度的需求，并支持更多功能的Pinot用户是完美的匹配。这是Presto Pinot连接器诞生的主要动机。这个完整的系统涵盖了分析的整个景观，我们可以利用Presto和Pinot的最佳部分。此新解决方案使Uber的运营团队能够具有基本的SQL知识，以构建仪表板以进行快速分析，并在不花费与数据建模或建筑数据管道上的工程师一起使用的额外时间，导致本公司的额外时间。

从那时起，Presto和Pinot社区贡献了许多功能，使解决方案灵活且可扩展。

例如。，

数组类型支持和函数推动时间戳/日期型中等和谓词下推支持Pinot GRPC服务器进行段级别查询追逐光亮：聚合下推

为了完全了解Pinot的能力，我们实现了聚合下推功能，它允许Presto Pinot连接器尽力为Pinot支持的聚合函数，例如计数/总和/最大/最大/不同/近似计数等。

以上图描述了聚合下推的工作原理。

Presto协调器获取查询并将其解析为查询计划。Presto Pinot Connector实现了一个计划优化器，用于说明此查询是一个聚合（组乘语）查询和推送能够PINOT。Presto查询计划优化器将查询计划与推动率标记重写。在物理计划执行阶段，Presto仅创建一个拆分包含聚合（组）查询和Pinot Broker Endpoint。一个Presto Worker获取拆分并查询Pinot Broker在拆分内部设置，以便通过结果询问聚合组。Pinot响应被包裹为PinotBrokerPageSource并由Presto Worker处理以获取进一步的执行。

在这种情况下，Pinot从Presto节省数据传输和计算时间，这显着降低了查询响应时间。一般来说，我们在此处看到延迟改善了大约10到100倍。

没有妥协灵活性：流式连接器

自然而然地跟进问题是，那些无法下推的查询到Pinot以进行处理。答案也非常简单。我们从Pinot获取所有请求的列数据，让Presto进行工作。

由于数据量可能是巨大的，因此查询Pinot Broker因此是不可扩展的。因此，我们需要进一步进入所有Pinot服务器和查询Pinot段的步骤，以获取我们想要的数据。

上面是关闭聚合下推功能时的示例。

Presto协调器获取查询并将其解析为查询计划。计划优化器决定此查询不能逐推，然后它获取了用于生成Presto Pinot Splits的路由表。假设我们有100个Pinot段，具有每个Presto分割的查询10个Pinot段的配置。每个presto查询将生成10个presto查询拆分，每个presto拆分包含10个查询的Pinot段。Presto Workers基于路由表获取分割并查询相应的Pinot服务器。通常，查询正在选择某些谓词的列。Pinot响应被包裹为PinotSegionPageSource，然后由Presto Worker处理以获取进一步的执行。

接线Presto的第一次迭代到Pinot并不高效，因为Pinot需要缓存所有查询响应，然后将其发送回一个数据块。当查询扫描小数据大小时，性能是可接受的。但是，对于大型桌子扫描而言，它成为一个问题，因为它很快应用服务器内存并经常导致GC上的GC。

为了使内存使用更可持续，社区对Presto和Pinot侧面进行了两种重大变化。

Apache Pinot已经实现了一种基于GRPC的流式Query Server [2] [3]，允许用户以流式方式查询Pinot。新的Presto Pinot连接器已实现流客户端[4]，并允许presto通过块从Pinot Streaming Server Chunk直接获取数据，这会使内存使用情况平滑。Presto Pinot连接器查询性能基准设置

我们使用AWS M4.4xlarge机器对Presto Pinot连接器进行了基准测试。

3个Pinot控制器，每个容器上，具有4个核心的资源，16GB内存5个Pinot经纪人，每个容器都有4个核心，7GB内存4个Pinot Server，每个容器上，具有15个核心的资源，内存为54GB1个Presto协调员，每个容器都有4个核心，7GB内存4个Presto Worker，每个Worker都在容器上，资源为4个核心，记忆16GB

该表包含10亿个随机生成的复杂网站（架构，表配置）数据集。

聚合查询的基准结果

低于测试基于查询模式：

我们可以根据谓词匹配不同数量的行。

以下是高选择性谓词的延迟图。由于每个查询扫描小数据，因此Pinot和Presto查询引擎对延迟编号贡献最多。

以下是低选择性谓词的延迟图。查询需要扫描更多数据，并且延迟与扫描的文档数量成比例。对于大数据扫描，Presto需要获取从清真机进程所需的所有数据。额外的成本和时间消耗是对黑比数据序列化，网络传输和Presto数据反序列化的。

Qualities对聚合组的基准结果

低于测试基于查询模式：

我们可以根据谓词匹配不同数量的行。

延迟趋势类似于聚合查询。

与Presto相比，为了扫描大量数据，比率增加了比比。从5500万行到500万行，Pinot Livency增加了2.2倍，而Presto增加了6.3倍。

上述延迟图表明聚合下降打开了用于分析的大门，并完全允许用户使用灵活的查询能力享受实时分析。

参考

[1]在优步的Apache Pinot上的工程SQL支持

[2]星形树索引：在Pinot上为快速聚合供电

[3] Pinot Kubernetes QuickStart

(本文由闻数起舞翻译自Xiang Fu的文章《Real-time Analytics with Presto and Apache Pinot — Part I/Part II》，转载请注明出处，原文链接： )