基于SQL的查询引擎简介，包括指向数据仓库和数据湖的链接

> Photo by NASA on Unsplash

介绍

从高层的角度来看，许多数据和分析解决方案已经以相同的方式构建了许多年。 简而言之，它由各种集成过程组成，可将所有数据加载到一个中央位置，这是即将到来的数据建模和分析用例的唯一事实来源。 虽然在较早的日子里，这些中心位置大多是昂贵的且不灵活的紧密耦合的硬件/软件系统，但如今通常会利用云和分布式架构，包括计算和存储的分离。 然而，尽管近年来取得了巨大的技术进步，但集中数据的整体方法仍然是最有效地利用其数据并进行适当的数据管理的最明显方法。

集权

那么，这种集中化方法有什么问题呢？首先它与分布式查询引擎有什么关系？

首先，没有什么可反对的。事实上，恰恰相反，在一个地方以清晰，新鲜的状态构建包含所有数据的海量数据仓库或数据湖通常是确保一致性的唯一方法，因此每个人使用相同的定义。在这方面，尤其是云数据湖服务，例如Microsoft的Azure Data Lake Storage或Amazon Web Service的S3，通过启用集中化的更多优势而呈现出有趣的变化，这归因于其非常灵活且廉价的方式来存储大量任何类型的数据。

注意事项

但是，有很多原因使集中所有数据变得越来越困难。数据源的数量正在增长，满足依赖该数据的越来越多的不同业务领域所需的数据集的多功能性也在不断增长。通常，与静态预建数据集相反，业务用户越来越接近需要更高灵活性的数据。高级分析用例也是如此，通常需要对原始和未转换的数据应用方法。而且，在某些情况下，由于任何内部或外部法规，甚至禁止组织迁移数据。在其他情况下，在集中式数据之上仍然存在管道，可将其进一步加载到任何下游系统中，以满足所有分析要求。反过来，这甚至可能导致与传统本地系统相同的锁定。或集中数据不足以证明所涉及的工作合理的用例，或者数据太大而移动所需的时间太长的用例。依此类推…

那么在这种情况下该怎么办？

联邦

如今，在分析解决方案及其数据管理方面有很多选择。不仅包括其报价的不同提供商，而且种类繁多的技术都势不可挡，技术进步的步伐比以往更快。也没有一个明确的赢家，他们无疑将帮助将更多的数据卡路里转化为有用的东西，这毫无疑问。但是，基于SQL的分布式查询引擎确实确实存在明显的趋势，有助于应对数据爆炸。这也证实了现有数据和分析服务提供商的产品阵容及其最新发展。他们都试图无缝集成那些具有成本效益的云存储，并允许使用完全一样的查询引擎在其上进行交互式SQL查询。因此，它们可以填补上述缺失的空白，并允许成熟的企业通过保持核心事实，在保持组织和平台稳定性的同时实现扩展的大数据功能。

数据虚拟化

分布式查询引擎背后的基本思想无非就是数据虚拟化以及创建抽象层的尝试，该抽象层提供了跨不同数据源的数据访问。与传统的数据虚拟化软件（链接服务器，DBLink等）的区别在于，您可以横向扩展方式一起查询关系和非关系数据，以提高查询性能。因此，分布式一词不仅指查询本身，还指计算和存储。它们基本上是针对密集型OLAP查询而设计的，因此在性能方面并不是那么脆弱和不一致。

Hadoop上的SQL

用于此目的的技术最初或仍然经常被称为基于Hadoop的SQL-on-Hadoop，它依赖于MPP（大规模并行处理）引擎。它允许使用熟悉的类似于SQL的语言查询和分析存储在HDFS（Hadoop分布式文件系统）上的数据，以隐藏MapReduce / Tez的复杂性，并使数据库开发人员更易于访问。 Hive可以说是Hadoop上的第一个SQL引擎，并且由于多年来的发展已被证明具有非常强大的功能，因此Hive仍被广泛用于批处理式数据处理。 Hive将SQL查询转换为多个阶段，并将中间结果存储到磁盘中。同时，在Hadoop生态系统中原生开发了其他专用工具，例如Impala，还支持将HBase用作数据源。与Hive相比，它利用了内存和缓存技术，与长期运行的批处理作业相比，它更适合用于交互式分析-此类别中的另一个示例是SparkSQL。所有这些都需要预先完成的元数据定义，也称为读取模式，例如视图或外部表。此定义存储在集中存储中，例如Hive metastore。

> Photo by Simplilearn

SQL-on-Anything

随着技术的发展，需要更多的开放性，并且不严格与Hadoop捆绑在一起，而是以松散耦合的方式支持许多其他种类的其他数据库。这样，查询引擎无需大量的先决条件和准备工作即可在大量数据上实现即插即用发现。此外，还提供了标准ANSI SQL作为接口，使数据分析人员和开发人员可以更轻松地访问它。同时，不再需要预先定义架构，某些引擎甚至可以通过下推查询（例如Drill）在原始存储层自动解析它。该领域的另一个开拓性工具是Presto，它甚至可以查询来自Kafka和redis的实时流数据。 Presto是Facebook专门为满足此需求而开发的一种内存中分布式SQL查询引擎，可在不同的数据集中进行交互式分析。对于Netflix，Twitter，Airbnb或Uber等公司而言，这对于他们的日常业务至关重要，否则它们将无法处理和分析PB级的数据。 Presto可以与许多不同的BI工具一起使用，包括Power BI，Looker，Tableau，Superset或任何其他符合ODBC和JDBC的工具。在这种情况下，" SQL-on-Anything"这个名字终于首次被创造出来。

> Photo by DataWorks Summit

数据湖引擎

数据湖引擎的技术方法没有太大不同。毕竟，它仅仅是数据虚拟化和合并来自不同来源的数据。它们通常在提供更多有关数据建模，数据转换，数据行数和数据安全性的功能方面有所不同。通常，它们也更趋向于云，并且可能会认为它们同时具有丰富的用户界面，从而为非技术用户带来了一种数据自助服务理念。这种方法可以充分利用公共云中的数据集中性，并且由于云的价格弹性而可以以较低的成本进行交互式分析，而没有任何锁定风险。 Data Lake Engines也不一定支持更多的数据源，但是由于延迟到来，它们可以从头开始利用最新技术。例如，Databricks最近发布了SQL Analytics，该数据库由其Delta引擎提供支持，可直接查询数据湖上的Delta Lake表。此外，它为数据浏览提供了SQL本机接口，并且仪表板可以彼此共享。在这方面，另一个非常有前途的工具也是我最喜欢的工具之一是Dremio，它基本上是开源的，但是得到了同名公司的支持，该公司提供了具有一些附加功能的商业化企业版。

> Photo by Dremio (Edited by Author)

与传统的多层体系结构相反，Dremio正在BI工具和查询的数据源系统之间建立直接的桥梁。幕后使用的主要技术是Drill，Arrow，Calcite和parquet。这种组合提供了适用于各种数据源的无模式SQL，以及具有下推功能的柱状内存分析执行引擎，并且可以轻松实现查询以提高查询性能。顺便说一句，Arrow被视为内存分析的事实上的标准。

结论

最后，是否在物理上集中数据完全取决于用例，此类引擎通过查询数据实际存在的位置为您提供了替代解决方案。 同样，即使这样的查询引擎似乎可以适应所有解决方案，但仍然存在无法即时解决的用例，仍然需要数据集成过程和适当的数据建模，更不用说 基于微服务架构的时间数据。 还需要注意的是，较早的分布式查询引擎不会像Hive那样迅速消失，它们在已经存在的许多现有数据体系结构中都无法很好地发挥作用，并且与大多数最新技术无缝集成。 让我们来看看未来会怎样。

(本文由闻数起舞翻译自24 Followers的文章《The Evolution of Distributed SQL-based Query Engines for Big Data》，转载请注明出处，原文链接：https://patrickpichler.medium.com/the-evolution-of-distributed-sql-based-query-engines-for-big-data-dfcb68102060)