介绍从高层次的角度来看，许多数据和分析解决方案多年来一直以相同的方式构建。简而言之，它由各种集成过程组成，这些过程将所有数据加载到一个中央位置，这是即将到来的数据建模和分析用例的单一事实来源。虽然在早期这些中心位置大多是昂贵且不灵活的紧密耦合的硬件/软件系统，但如今它们通常利用云和分布式架构，包括计算和存储的分离。然而，尽管近年来技术取得了巨大进步，但集中数据的整体方法仍然是最有效地利用数据并进行适当数据管理的最明显方法。集中化那么，这种集中化的方法有什么问题呢？首先，它与分布式查询引擎有什么关系？首先，没有人反对它。事实上，恰恰相反，构建海量数据仓库或数据湖，将所有数据以干净、新鲜的状态保存在一个地方，通常是确保一致性的唯一方法，因此每个人都使用相同的定义。在这方面，特别是云数据湖服务，例如Microsoft的AzureDataLakeStorage或AmazonWebServices的S3，呈现出一种有趣的变化，因为它们以非常灵活且廉价的方式存储任何领域的大量数据，从而实现了集中化的进一步优势。类型。注意事项但是，由于多种原因，集中所有数据变得越来越困难。数据源的数量在增加，数据集的多功能性也在不断增加，以满足依赖该数据的不同业务领域数量不断增加的需求。通常，业务用户越来越接近需要更大灵活性的数据，而不是静态的预建数据集。高级分析用例也是如此，通常需要对原始和未转换的数据应用方法。而且，在某些情况下，由于任何内部或外部法规，组织甚至被禁止迁移数据。在其他情况下，管道仍然存在于集中数据之上，可以进一步加载到任何下游系统以满足所有分析需求。反过来，这甚至可能导致与传统本地系统相同的锁定。或者没有足够的集中数据来证明所涉及工作的用例，或者数据太大以至于移动时间太长的用例。等等……那么遇到这种情况怎么办？Federated今天，在分析解决方案及其数据管理方面有很多选择。不仅包括他们的产品的不同供应商，而且技术的多样性是压倒性的，技术进步的步伐比以往任何时候都快。也没有明显的赢家，毫无疑问，它们将有助于将更多的数据卡路里转化为有用的东西。然而，确实有一个明显的趋势是基于SQL的分布式查询引擎有助于应对数据爆炸。这也证实了现有数据和分析服务提供商的产品阵容及其最新发展。他们都试图无缝集成那些具有成本效益的云存储，并允许使用完全相同的查询引擎对其进行交互式SQL查询。因此，它们可以填补上述缺失的空白，并允许成熟的企业实施扩展的大数据功能，同时通过维护核心真理来维护组织和平台的稳定性。数据虚拟化分布式查询引擎背后的基本思想无非就是数据虚拟化，并试图创建一个抽象层来提供跨不同数据源的数据访问。与传统数据虚拟化软件（LinkedServer、DBLink等）的不同之处在于，您可以以横向扩展的方式将关系数据和非关系数据一起查询，以提高查询性能。因此，术语分布式不仅指查询本身，还指计算和存储。它们基本上是为密集型OLAP查询而设计的，因此在性能方面并没有那么脆弱和不一致。用于此目的的SQL-on-Hadoop技术最初或仍然经常被称为SQL-on-Hadoop-on-Hadoop，它依赖于MPP（大规模并行处理）引擎。它允许使用熟悉的类似SQL的语言查询和分析存储在HDFS（Hadoop分布式文件系统）上的数据，以隐藏MapReduce/Tez的复杂性并使数据库开发人员更容易访问它。Hive可以说是Hadoop上的第一个SQL引擎，由于其多年的发展，至今仍被广泛用于批处理式数据处理，并被证明非常强大。Hive将SQL查询转换为阶段并将中间结果存储到磁盘。同时，在Hadoop生态中原生开发了Impala等其他专用工具，也支持使用HBase作为数据源。与Hive相比，它利用内存和缓存技术，并且比长时间运行的批处理作业更适合交互式分析——该类别的另一个例子是SparkSQL。所有这些都需要预先完成的元数据定义，也称为读取模式，例如视图或外部表。此定义存储在集中式存储中，例如Hive元存储。随着技术的发展，SQL-on-Anything需要更加开放，并且不严格依赖于Hadoop，而是以松散耦合的方式支持许多其他类型的其他数据库。这样，查询引擎就可以在大量数据上实现即插即用发现，而无需大量先决条件和准备工作。此外，还提供了标准的ANSISQL作为接口，使数据分析人员和开发人员更容易访问它。同时，不再需要预先定义schema，有些引擎甚至可以通过下推查询（如Drill）在原始存储层自动解析。这个领域的另一个先驱工具是Presto，它甚至可以从Kafka和Redis查询实时流数据。Presto是Facebook专门针对这种需求开发的内存分布式SQL查询引擎，能够在不同的数据集上进行交互式分析。对于像Netflix、Twitter、Airbnb或Uber这样的公司来说，这对他们的日常业务至关重要，否则他们将无法处理和分析PB级的数据。Presto可以与许多不同的BI工具一起使用，包括PowerBI、Looker、Tableau、Superset或任何其他ODBC和JDBC兼容工具。在这种情况下，“SQL-on-Anything”这个名字终于第一次被创造出来了。数据湖引擎数据湖引擎的技术方法没有太大区别。毕竟，这只是数据虚拟化和合并来自不同来源的数据。它们通常在提供有关数据建模、数据转换、数据行数和数据安全性的更多特性方面有所不同。通常，它们也更面向云，并且可能会争辩说它们还具有丰富的用户界面，为非技术用户带来数据自助服务的感觉。这种方法可以充分利用公共云中的数据中心性，并以较低的成本进行交互式分析，而不会因云的价格弹性而存在锁定风险。DataLakeEngines也不一定支持更多的数据源，但由于延迟的到来，它们可以从头开始利用最新的技术。例如，Databricks最近发布了SQLAnalytics，它由其Delta引擎提供支持，可以直接查询数据湖上的DeltaLake表。此外，它还提供了用于数据探索的SQL本机接口，并且仪表板可以相互共享。在这方面，另一个非常有前途的工具也是我最喜欢的工具之一是Dremio，它基本上是开源的，但得到一家同名公司的支持，该公司提供具有一些附加功能的商业企业版。与传统的多层架构相反，Dremio正在BI工具和被查询的数据源系统之间建立直接的桥梁。幕后使用的主要技术是Drill、Arrow、Calcite和parquet。这种组合为各种数据源提供无模式的SQL，以及具有下推能力的列式内存分析执行引擎，可以轻松实现查询以提高查询性能。顺便说一句，Arrow被认为是内存分析的事实标准。结论最后，是否以物理方式集中数据完全取决于用例，此类引擎通过查询数据实际存在的位置为您提供替代解决方案。此外，即使这样的查询引擎似乎适合所有解决方案，但仍有一些用例无法开箱即用，仍然需要数据集成过程和适当的数据建模，更不用说基于微服务架构的时态数据了。同样重要的是要注意，较旧的分布式查询引擎不会像Hive那样迅速消失，它们不能很好地与许多已经存在的现有数据体系结构配合使用，也不能与大多数最新技术无缝集成。让我们看看未来会怎样。
