我们如何实现高带宽连接用BI工具吗

通过Bogdan Ionut Ghit,Juliusz Sompolski,普里昂和雷诺鑫

2021年8月11日, 在工程的博客

分享这篇文章

商业智能(BI)工具,如画面和微软权力BI是出了名的慢提取大型查询结果与传统的数据仓库,因为他们通常在一个线程获取数据通过SQL端点成为数据传输瓶颈。数据分析师可以连接他们的BI工具砖SQL端点查询数据表通过ODBC / JDBC协议集成在我们辛巴司机。与云取回,我们发布的砖8.3运行时,辛巴ODBC 2.6.17司机,我们引入一个新的机制来获取数据并行通过AWS S3和Azure等云存储数据湖存储数据更快的BI工具。在我们的实验中使用云取回,我们观察到一个10 x加速由于并行提取性能。

动力和挑战

BI工具在大型组织变得越来越受欢迎,因为它们提供大数据可视化数据分析师运行分析应用程序而隐藏查询执行的复杂性。BI工具与SQL通信端点通过一个标准ODBC / JDBC协议执行查询和提取结果。之前引入云取回,砖采用类似的方法使用Apache火花™。在这种背景下,端到端提取性能通常是由时间单线程的SQL端点将结果返回给您的BI工具。

云之前取回,如图1所示的数据流是相当简单的。BI工具连接到SQL端点支持的集群并行查询执行在计算槽。查询结果都是收集SQL端点,充当协调者节点之间的通信的客户端和集群。为大量数据没有达到SQL端点的资源限制,我们上启用disk-spilling SQL端点,结果超过100 MB的存储在一个本地磁盘。当所有结果收集和潜在disk-spilled, SQL端点准备结果返回给BI服务客户请求它。服务器没有返回整个数据,而是它切割成多个小块。

数据流的n概述单线程BI摘录一个典型的数据仓库。 — 图1所示。概述数据流的单线程BI摘录一个典型的数据仓库。

我们确定了两个主要的可伸缩性问题,使这个数据流效率低下,并把SQL端点的风险成为一个瓶颈时提取数百MB:

多租户。有限的出口带宽可能由多个用户访问同一个共享SQL端点。随着并发用户数量的增加,每个人将会提取数据和降解性能。

缺乏并行性。尽管集群并行执行查询,从执行者收集查询结果并返回给BI工具在单线程执行。虽然客户端获取结果顺序几MB的块存储和服务结果由一个线程瓶颈在SQL端点。

云计算获取架构

为了解决这些局限性,我们修改了数据提取架构以这样一种方式,写作和阅读的结果是并行完成的。高层,每个查询分为多个任务运行在所有可用的计算资源,这些任务写作结果湖存储Azure数据,AWS S3,或者谷歌云存储。SQL端点发送一个文件列表pre-signed url到客户端,以便客户机可以直接从云存储并行下载数据。

数据布局。查询任务流程的各个分区输入数据并生成箭头序列化结果。Apache箭头最近成为柱状内存数据分析的实际标准,并已通过大量的开源项目。每个查询任务写数据云存储在20 MB的块使用箭头流格式。在每个文件中,可能有多个箭头批次由一个固定的行数和字节。我们进一步应用LZ4压缩的块来解决用户上传抓取带宽限制设置。

结果集合。而不是收集MBs或GBs的查询结果,SQL端点现在存储云存储的链接,这样内存占用和disk-spilling开销都显著降低。我们的实验表明,云获取提供超过2 x吞吐量提高查询结果大小超过1 MB。然而,上传结果小于1 MB到云存储很容易遭受不小延迟。因此,我们设计了一个混合的获取机制,允许我们要么内联结果和避免延迟小查询结果或上传结果和提高吞吐量大查询结果。我们确定了三种可能的场景当收集SQL端点的结果:

所有任务返回箭头批次和他们的总大小是小于1 MB。这是一个很短的查询对延迟敏感的和为获取通过云存储并不理想。我们这些结果直接返回给客户通过上述单线程机制。
所有任务返回箭头批次和他们的总大小是高于1 MB或任务返回箭头的批次和云文件。在这种情况下我们剩下的箭头批量上传到云存储从SQL端点使用相同的数据布局任务和存储的结果列表文件。
所有任务返回云文件的链接。在这种情况下,我们的云存储链接内存并将它们返回给客户机获取请求。

获取请求。SQL端点上的数据可用时,BI工具可以通过按顺序开始抓取请求小块。获取请求时,SQL端点获取文件对应于当前抵消并返回一组pre-signed url到客户机。这样的url是方便BI云提供商的客户,因为他们是不可知论者,可以使用一个基本的HTTP客户端下载。并行BI工具下载返回的文件,解压缩他们的内容,从箭批次提取单个行。

实验结果。我们执行数据提取实验合成数据集组成的400万列和行总量为3.42 GB。启用了云取回我们观察到12 x提高提取吞吐量相比,单线程的基线。