在商业智能 (bi) 领域, 查询性能一直是一个问题, 许多 bi 用户会很乐意让他们的报告加载并更快地呈现。传统上, 实现此性能的最佳方法 (除了购买更大的数据库) 是在不同级别生成和维护聚合表, 以拦截某些查询组, 从而防止重复查询相同的原始数据。此外, 许多 bi 工具将数据库中的数据从它们自己的内存中提取到某种类型的 “多维数据集” 中, 并对这些数据提取进行分析。
聚合和多维数据集的缺点
这两种方法都有一个主要缺点, 即需要在新数据到达时维护聚合或多维数据集。过去, 这是每天都会发生的事情, 但现在大多数仓库都是近实时的流料。每次新行到达或更新历史行时, 连续重建聚合表或内存中的多维数据集是不实际的。
进入 hadoop。问题解决了吗？不。
当 hadoop 和数据湖成为大数据的常见存储时, 查询性能问题就变得更加成为一个问题。虽然这些系统的查询引擎随着时间的推移而改进, 但它们并不总是能够提供可接受的响应时间, 特别是在数据量越来越大和查询并发性增加的情况下。此外, 除了 kudu 之外, hadoop 和数据湖还没有以一种能够立即查询的方式发展出干净的方法来获取实时数据流, 特别是难以查询后期到达或重述的历史数据。
输入专有中间件。问题解决了吗？还是没有。
在大数据的世界中, 许多公司试图通过引入位于 bi 工具和 hadoop 系统或数据湖之间的自定义中间件来解决查询响应和并发问题。datameer、platfora、atscale、jethro 等产品旨在提高离散查询性能, 但它们为堆栈引入了另一层, 您必须选择、购买、管理和维护这些堆栈。您还必须将这些产品与堆栈中的其他产品 (如下面的数据库和下面的 bi 缓存) 分开调整和担心这些产品。
现代数据仓库 + 现代智能救援
最近, 出现了云原生数据仓库的快速采用, 如 amazon redshift、google bigquery、quoble 和二片。如今, 我们在数据仓库空间中与之交谈的几乎每个人都在使用、测试或考虑尝试使用云原生数据库来处理他们的一些数据仓库工作负载。
这对 bi 和查询性能意味着什么？嗯, 这在某种程度上使事情变得更容易, 因为这些云原生系统能说一口流利的 sql, 并且具有类似于传统数据仓库系统的特点, 但其速度、可扩展性和成本配置比传统的 mpp 都要高得多仓库或大多数基于 Hadoop-based 的系统。其中一些云系统在很大程度上依赖于分区的性能, 包括微分区, 它与 zoomdata 独特的微查询和对大数据的数据锐化支持完全匹配。其他可用作云服务的数据库主要使用内存中的方法, 如 sap hana 和 memsql, 或者是本地数据库技术的重新打包版本。
现代物化景观
虽然微查询和微分区为交互式数据探索提供了很大的性能提升, 但当成千上万的仪表板使用者都同时要求类似 (但不完全相同) 的仪表板时, 经典的周一上午问题仍可能出现时间。在这种情况下, 聚合表对于将某些负载从原始基础数据中移出仍然非常有用。
但如上所述, 面对不断出现的数据, 很难维护持久聚合表虽然传统数据库在相当长的时间内提供了实例化视图, 并且下面的许多建议也适用于这些后端, 但最近的创新允许使用一个 sql 命令来定义这些视图, 然后由即使在极端的规模和速度下, 新数据也会不断到达。
即使数据到达较晚、不正常或历史数据更新/重新设置, 现代物化视图也可以处理它。即使在数据插入和更新率高、数据量大、查询并发度几乎无限的情况下, 现代物化视图也能持续而不受影响地进行卡车运输。
如何确定要创建的物化视图
无论是使用云原生数据库、内存中数据库还是更传统的本地数据仓库, 实例化视图都有一定的维护成本, 它们确实占用了一定的存储空间 (尽管通常远远低于完整细节原始数据)。因此, 最好查看最常用的仪表板, 查看它们正在命中的表和正在执行的任何联接, 并构建实例化视图, 以便能够为这些仪表板提供服务。然后, 您可以让那些经常使用的星期一上午的仪表板从实例化视图中运行, 但仍有指向更详细的仪表板和报告的链接, 供希望深入了解详细信息的用户使用。