分布式SQL大数据查询引擎的发展

2020-11-26 15:51:11从高层的角度来看，许多数据和分析解决方案已经以相同的方式构建了许多年。简而言之，它由各种集成过程组成，可将所有数据加载到一个中央位置，这是即将到来的数据建模和分析用例的唯一事实来源。

介绍

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

集权

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

首先，没有什么可反对的。事实上，恰恰相反，在一个地方以清晰，新鲜的状态构建包含所有数据的海量数据仓库或数据湖通常是确保一致性的唯一方法，因此每个人使用相同的定义。在这方面，尤其是云数据湖服务，例如Microsoft的Azure>服务器，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。

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”这个名字终于首次被创造出来。

数据湖引擎

数据湖引擎的技术方法没有太大不同。毕竟，它仅仅是数据虚拟化和合并来自不同来源的数据。它们通常在提供更多有关数据建模，数据转换，数据行数和数据安全性的功能方面有所不同。通常，它们也更趋向于云，并且可能会认为它们同时具有丰富的用户界面，从而为非技术用户带来了一种数据自助服务理念。这种方法可以充分利用公共云中的数据集中性，并且由于云的价格弹性而可以以较低的成本进行交互式分析，而没有任何锁定风险。>

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

结论

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

国内做分布式数据库开发的现状如何？

应该说，现在是国产分布式数据库发展的利好时期。在讨论发展前景前，首先要先看看分布式数据库的发展方向。

大家把传统关系型数据库称作oldSQL，给人感觉要被淘汰似的。但其实数据量不是很大或者事务处理的场景夏，关系型数据库的还是占优的。

关系型数据库的主要问题在于：

性能瓶颈，

单一模型（关系模型），只适合OLTP

应对业务的灵活性不够，

弹性扩充能力不够，

两地三中心和双活等问题上不足。

随着互联网和手机的飞速发展，无论从用户规模、使用频率、还是场景多样性都使得这些问题浮出水面。其实Oracle在92年就开始尝试转向分布式，还当时引起了业界的巨大争论，最后失败。更何况过去CPU、内存、存储、带宽的高成本导致分布式数据库的性价比并不高，只能停留在学术阶段，限制了分布式的发展。

新分布式数据库首先是要避免和传统关系型数据库的竞争，这是明智的选择，能够轻装上阵。因此从几个方面入手，应对海量数据处理、分析、缓存、流式处理、开发模式等等。相对应列式，KV，Document等多种存储数据结构。

所有这些都被称为NoSQL数据库，放弃ACID和事务能力还换取性能。然而，NoSQL又收到了大量的批评反对意见，主要是说把数据库应该处理的问题交还给了开发是种发展的倒退。这些问题包括，索引、版本、SQL支持、事务支持等等。市场上超过90%的开发员都需要SQL，而且SQL也是非常有效和成熟。于是大家无论底层是什么存储结构又开始支持SQL，形成了NewSQL。

这里插一句题外话，在硅谷已经不再用SQL、NoSQL、NewSQL来划分数据库了。理由很简单，SQL是一种语言，从来没有SQL数据库的说法，自然也不应该有NoSQL数据库的说法。 NewSQL数据库就更不合理，用的SQL并非什么“New“的新东西。所以专业上用关系型和非关系型数据库来划分，分布式数据库主要都是非关系型数据库。

回过头来看国内分布式数据库市场需求，中小企业不满足mysql的性能，分库分表又很难搞，也不彻底；大型企业被Oracle等垄断支付高额成本，而且又不解决实际碰到的瓶颈问题。因此，用户都在寻找新的解决方案。小型用户、云计算的用户、大型企业都需要对应的分布式数据库产品。

再加上国产自主和去IOE浪潮，更加推动了国产分布式数据库的发展利好。值得注意的是，数据库研发是个严肃的事情，没法短平快。

MPP计算引擎Presto介绍

Presto是一个专为低延迟分析而生的分布式SQL查询引擎，属于MPP计算引擎的一种。以下是关于Presto的详细介绍：

综上所述，Presto以其高效的内存计算、多源数据无缝查询以及优化的架构设计等特点，在大数据处理和分析领域发挥着重要作用。

NewSQL分布式数据库发展策略讨论

作者石默研

本文对新一代NewSQL分布式数据库发展策略中的普遍困扰进行讨论，包括云原生（Cloud Native）与本地部署(On Premise)、HTAP进展方向、分布式与单机需求等分布式数据库商业与技术发展中难以决策的问题。

1. 困扰

分布式NewSQL数据库近年来蓬勃兴起，其原因显而易见：切中了业务与数据量不断增长的用户对关系型数据库RDBMS需求，这在传统RDBMS到大数据的发展阶段中，有相当一段时间是空白。同时，随着互联网技术的不断发展与普及，用云计算模式满足IT需求似乎已经成为未来社会产业互联网发展的明确趋势，也就是说，有一种共识：不久的将来，绝大多数产业的IT服务是从公共的、行业的或者私有的、混合的云计算中心提供的。这一共识又带来了云原生（Cloud Native）概念与技术的兴起，而分布式NewSQL数据库自然也应该是云原生的，这决定了其相当多的产品设计决策应以符合这一趋势为原则。然而，在当今的现实中，满足业务与数据量不断增长的RDBMS需求的用户，与云原生的用户，除了互联网企业外，大多数情况下，并不重合，需要On-Premise部署的用户仍然占有很大比重，这就带来了第一个困扰：云原生（Cloud Native）与本地部署(On Premise)对产品发展要求的矛盾。

另一个困扰，是关于HTAP，即交易与分析混合负载。 HTAP是当今非常火的一个概念与技术，在交易库上直接进行分析，而不再是将“数据从交易库搬下来，挪到另一个数据库中去”这样的繁琐过程。可以毫不夸张的说：历史上规模性企业IT复杂度的相当一部分，都来自于“搬数据”，这导致了数据采集、实时采集、全增量合并、数据传输、数据加载、数据建模、数据质量、数据标准、企业级元数据管理等繁杂多样的技术环节的产生，导致了企业数据分布、数据流向、数据模型、主数据、基础数据平台、ODS/数据仓库/数据集市、数据治理等复杂的数据架构设计优化领域，导致了由于多系统大规模数据搬迁而带来的如数据交换平台之类的复杂调度工程......。咋眼一看，感觉该企业的数据技术好厉害，相关各领域的技术产品好丰富，技术人员的相关技能也好受欢迎。但如果在交易库就能直接满足分析需求而不影响生产效能的话，这些复杂高级的技术环节不都成了“自己给自己造了一座山，还说自己爬的好辛苦”？然而，现实却是，问题并不这么简单，除了在交易库中进行分析会影响业务效能外，还有很多原因导致这一现象产生：交易库并不需要存储那么长的历史数据，而分析往往是需要建立在大量历史数据之上的；交易库的模型往往并不适合分析需求，多数情况下需要重要建模，如非常流行且价值不菲的各行业数仓主题模型；用于交易的OLTP数据库与用于分析的OLAP数据库，其技术体系完全不同；以及大型企业已固化的内部业务结构并没有留给交易/分析整合可实施的可行空间......等等。由于，历史积累的企业级数据体系相当复杂，HTAP的发明者迄今为止都没有系统表达完全替代数据分析需求、自顶而下重构企业数据体系的架构级策略，而是将产品重点定位在技术优化层面：在交易库上直接完成实时统计分析，满足高并发需求且不影响业务效能；或者是为实时分析统计/查询而建设的数据服务中间平台。然而，即使是暂时没有这种策略性的意向，在面向AP的产品具体研发中，又会发现明确的界限确实不好把握，随着一个个具体功能的不断完善，似乎假以时日，技术上也不是没有完全替代纯OLAP平台的可能性。那么，HTAP究竟如何定位呢？

再者就是规模化的分布式需求，与小规模的单机数据库需求（这里指逻辑上的单机）之间的矛盾：分布式数据库，自然而然是要应对规模化的数据管理需求的，长尾的小规模需求当然不应在产品设计考虑之列，同时，大炮轰苍蝇经常还打不好；然而，分布式NewSQL数据库又应该是云原生的，如果把云原生的业务含义理解为“全自助”，它应该以支持什么样的需求为主呢？现实看来，小规模长尾业务对云原生数据库的需求最起码应该是占据相当大的比重的。显而易见，如果是大规模的数据管理需求，即使是部署在云上，DBPaaS的“全自助”是其核心需求吗？这种规模化的业务，如果是云上的On-Premise又需要做出哪些方面的改变？从互联网与云计算发展的历史来看，“云自助”，其最核心的商业动机当然包括给用户侧的运维带来了方便，但更重要的可能是给云服务运营商应对海量长尾客户的安装与运维带来了极大的成本优势。这正如银行的小微及个人消费贷款都要走互联网线上模式，而重客、大客甚至中小企业信贷仍然是以线下为主的策略一样，本质是成本问题，而不是客户方便性问题。于是，矛盾显而易见：分布式是面向规模客户的，起码是中、大型客户，而云原生却有可能、最起码相当一段时间内是要以长尾客户为主要服务对象的。

以上困扰实质上，都涉及到了NewSQL分布式数据库的产品发展策略问题。

2. 讨论

问题是客观而又普遍的，但分析与应对策略往往包含主观因素：人们的一个决定与决策，很多情况下并不由严格推理而来，而是心中已经有一个答案，再来找理由支持它。这里的讨论或许也并不能例外。

首先，来看看Cloud Native与On Premise。云原生本应是数据库即服务，然而目前真正有规模化数据增长需求的NewSQL应用相当多的情况下却是付费On Premise与免费On Premise区别，很多互联网企业的应用也可能只是部署在云基础设施上而已，真正的云原生更多是一些实验性、尝试性的需求。但云原生数据库在公有云、行业云以及大型私有云上已经逐渐在形成一种意识上的共识，其商业前景不可限量。也就是说，未来的数字化转型进程中，产业互联网的数据库部署，会逐渐向云基础设施迁移，长在云上。它可能是公有云，也可能是行业云，也可能是私有云，它们都是被定义为云原生NewSQL数据库的市场范围。当然，肯定还会有相当一部分数据库长在云下，这也不用纠结，将其排除在云原生市场战略目标之外即可，就是说，不需要考虑这部分客户需求对产品规划的影响，因为前一部分的份额已经足够大了。这样看来，以云原生为目标进行产品规划的逻辑没有问题，不过，还是要明确一点：长在云上的数据库是不是一定符合我们对“云原生”的既有理解？这里认为，即使未来，在云上形成了产业互联网数据库市场的主体，需要“全自助”的数据库即服务可能也是以面向长尾客户最为迫切、必不可少并且是核心本质，而对中大型以上的需求，“全自助”的意义相对有限，同时比较而言商业模式的转变或者更关键些。那么，如果是以“长在云上”为市场目标，似乎可以将其定义为“广义的云原生”，同时，只要是“长在云上”，那么“云原生”概念中高弹性、高可用、低成本、快速迭代、存算分离等技术优势也都能方便获得。而对“云原生”策略中“云原生”一词的理解不同，对产品规划决策的影响也应该有所不同：一是目前被认为是On Premise的客户需求，或许也就是未来“云原生”主体市场的需求；二是NewSQL数据库关于云原生服务的产品策划，对用户侧“自助”水平的决策或许可以更灵活实用。高水平自助确实可以减轻客户对IT的依赖程度，但这里认为，云原生与用户自行在云上购买资源进行On-Premise部署相比，最关键的价值在于商业模式的改变，能自助多少，不一定是最重要的，因为成为云服务商后，运营运维的工作只会更多，责任可能会更大，甚至有时连IaaS的运维也需要PaaS服务商兜底。但从一个个客户的本地服务，变成集中化云服务，就已经是本质性的模式转变了。总之，需要就事论事，回到原点，仔细分析后决策，而不是用概念教条的判断，因为概念本身的定义并不见得准确对应实际的业务需求。

再来看看HTAP，对这个问题，正如在其它文章中表达过的一样，本文的观点较为明确。一是随着计算能力与架构的升级，从技术上讲，AP与TP的界限会越来越模糊；另外特别是在云原生的新世界里，数据库的这一特性又犹为重要，因为云原生的重要作用之一就是要让客户尽量摆脱对IT运维的依赖，将越来越多的精力集中到自己的业务发展上来；同时端到端的能力提升对云原生商业模式的贯彻也至关重要（需要仔细分析下目前DBPaaS的技术要求是否完全符合这一原点的、本质性的动力），过去与纯OLAP数据库的优势比较纠结在这里也可以得到正面支持；再者，既然架构上已经走向了AP，就很难做到在产品规划上时刻厘清纯AP与混合负载的需求后，再将前者排除在外。于是，以“混合负载满足部分AP需求”应该是由于投入与阶段性市场策略导致的阶段性产品规划，而长远来讲，以一套技术架构满足大多数需求，应该是云原生NewSQL数据库的追求。

接下来，就是关于规模化分布式与小规模单机需求的矛盾了。现在看来，经过上面的讨论，这一点已经不是什么问题了：因为“长在云上”、从分散服务向集中服务的商业模式转变就是指广义的云原生，而不一定要以小微的、迫切需要全自助的长尾为主流，那么，云原生NewSQL数据库仍然应以规模化分布式为其主体的需求方向，而小规模单机则暂时可以不做为重点来考虑。

最后指出一点，希望也能引发进一步的思考：我们所批判的主机，也声称自己是分布式架构，暂且不论其是否客观，但在现实中主机需要被替代的核心问题并不是有没有分布式，而是：一、扩展不灵活带来成本问题：“我只需要扩展一个节点，你却让我再买一台主机”；二、不自主可控；三、往往是软硬件结合的设计策略，包括内存、网络、存储与IO上的软硬融合设计，而这一点，是否需要云原生数据库从广义的定义出发进行学习参考，也是需要进一步讨论的。