分布式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那样迅速消失，它们在已经存在的许多现有数据体系结构中都无法很好地发挥作用，并且与大多数最新技术无缝集成。让我们来看看未来会怎样。

大数据时代发展历程是什么？

大数据技术发展史：大数据的前世今生

今天我们常说的大数据技术，其实起源于Google在2004年前后发表的三篇论文，也就是我们经常听到的“三驾马车”，分别是分布式文件系统GFS、大数据分布式计算框架MapReduce和NoSQL数据库系统BigTable。

你知道，搜索引擎主要就做两件事情，一个是网页抓取，一个是索引构建，而在这个过程中，有大量的数据需要存储和计算。这“三驾马车”其实就是用来解决这个问题的，你从介绍中也能看出来，一个文件系统、一个计算框架、一个数据库系统。

现在你听到分布式、大数据之类的词，肯定一点儿也不陌生。但你要知道，在2004年那会儿，整个互联网还处于懵懂时代，Google发布的论文实在是让业界为之一振，大家恍然大悟，原来还可以这么玩。

因为那个时间段，大多数公司的关注点其实还是聚焦在单机上，在思考如何提升单机的性能，寻找更贵更好的服务器。而Google的思路是部署一个大规模的服务器集群，通过分布式的方式将海量数据存储在这个集群上，然后利用集群上的所有机器进行数据计算。这样，Google其实不需要买很多很贵的服务器，它只要把这些普通的机器组织到一起，就非常厉害了。

当时的天才程序员，也是Lucene开源项目的创始人Doug Cutting正在开发开源搜索引擎Nutch，阅读了Google的论文后，他非常兴奋，紧接着就根据论文原理初步实现了类似GFS和MapReduce的功能。

两年后的2006年，Doug Cutting将这些大数据相关的功能从Nutch中分离了出来，然后启动了一个独立的项目专门开发维护大数据技术，这就是后来赫赫有名的Hadoop，主要包括Hadoop分布式文件系统HDFS和大数据计算引擎MapReduce。

当我们回顾软件开发的历史，包括我们自己开发的软件，你会发现，有的软件在开发出来以后无人问津或者寥寥数人使用，这样的软件其实在所有开发出来的软件中占大多数。而有的软件则可能会开创一个行业，每年创造数百亿美元的价值，创造百万计的就业岗位，这些软件曾经是Windows、Linux、Java，而现在这个名单要加上Hadoop的名字。

如果有时间，你可以简单浏览下Hadoop的代码，这个纯用Java编写的软件其实并没有什么高深的技术难点，使用的也都是一些最基础的编程技巧，也没有什么出奇之处，但是它却给社会带来巨大的影响，甚至带动一场深刻的科技革命，推动了人工智能的发展与进步。

我觉得，我们在做软件开发的时候，也可以多思考一下，我们所开发软件的价值点在哪里？真正需要使用软件实现价值的地方在哪里？你应该关注业务、理解业务，有价值导向，用自己的技术为公司创造真正的价值，进而实现自己的人生价值。而不是整天埋头在需求说明文档里，做一个没有思考的代码机器人。

Hadoop发布之后，Yahoo很快就用了起来。大概又过了一年到了2007年，网络和阿里巴巴也开始使用Hadoop进行大数据存储与计算。

2008年，Hadoop正式成为Apache的顶级项目，后来Doug Cutting本人也成为了Apache基金会的主席。自此，Hadoop作为软件开发领域的一颗明星冉冉升起。

同年，专门运营Hadoop的商业公司Cloudera成立，Hadoop得到进一步的商业支持。

这个时候，Yahoo的一些人觉得用MapReduce进行大数据编程太麻烦了，于是便开发了Pig。 Pig是一种脚本语言，使用类SQL的语法，开发者可以用Pig脚本描述要对大数据集上进行的操作，Pig经过编译后会生成MapReduce程序，然后在Hadoop上运行。

编写Pig脚本虽然比直接MapReduce编程容易，但是依然需要学习新的脚本语法。于是Facebook又发布了Hive。 Hive支持使用SQL语法来进行大数据计算，比如说你可以写个Select语句进行数据查询，然后Hive会把SQL语句转化成MapReduce的计算程序。

这样，熟悉数据库的数据分析师和工程师便可以无门槛地使用大数据进行数据分析和处理了。 Hive出现后极大程度地降低了Hadoop的使用难度，迅速得到开发者和企业的追捧。据说，2011年的时候，Facebook大数据平台上运行的作业90%都来源于Hive。

随后，众多Hadoop周边产品开始出现，大数据生态体系逐渐形成，其中包括：专门将关系数据库中的数据导入导出到Hadoop平台的Sqoop；针对大规模日志进行分布式收集、聚合和传输的Flume；MapReduce工作流调度引擎Oozie等。

在Hadoop早期，MapReduce既是一个执行引擎，又是一个资源调度框架，服务器集群的资源调度管理由MapReduce自己完成。但是这样不利于资源复用，也使得MapReduce非常臃肿。于是一个新项目启动了，将MapReduce执行引擎和资源调度分离开来，这就是Yarn。 2012年，Yarn成为一个独立的项目开始运营，随后被各类大数据产品支持，成为大数据平台上最主流的资源调度系统。

同样是在2012年，UC伯克利AMP实验室（Algorithms、Machine和People的缩写）开发的Spark开始崭露头角。当时AMP实验室的马铁博士发现使用MapReduce进行机器学习计算的时候性能非常差，因为机器学习算法通常需要进行很多次的迭代计算，而MapReduce每执行一次Map和Reduce计算都需要重新启动一次作业，带来大量的无谓消耗。还有一点就是MapReduce主要使用磁盘作为存储介质，而2012年的时候，内存已经突破容量和成本限制，成为数据运行过程中主要的存储介质。 Spark一经推出，立即受到业界的追捧，并逐步替代MapReduce在企业应用中的地位。

一般说来，像MapReduce、Spark这类计算框架处理的业务场景都被称作批处理计算，因为它们通常针对以“天”为单位产生的数据进行一次计算，然后得到需要的结果，这中间计算需要花费的时间大概是几十分钟甚至更长的时间。因为计算的数据是非在线得到的实时数据，而是历史数据，所以这类计算也被称为大数据离线计算。

而在大数据领域，还有另外一类应用场景，它们需要对实时产生的大量数据进行即时计算，比如对于遍布城市的监控摄像头进行人脸识别和嫌犯追踪。这类计算称为大数据流计算，相应地，有Storm、Flink、Spark Streaming等流计算框架来满足此类大数据应用的场景。流式计算要处理的数据是实时在线产生的数据，所以这类计算也被称为大数据实时计算。

在典型的大数据的业务场景下，数据业务最通用的做法是，采用批处理的技术处理历史全量数据，采用流式计算处理实时新增数据。而像Flink这样的计算引擎，可以同时支持流式计算和批处理计算。

除了大数据批处理和流处理，NoSQL系统处理的主要也是大规模海量数据的存储与访问，所以也被归为大数据技术。 NoSQL曾经在2011年左右非常火爆，涌现出HBase、Cassandra等许多优秀的产品，其中HBase是从Hadoop中分离出来的、基于HDFS的NoSQL系统。

我们回顾软件发展的历史会发现，差不多类似功能的软件，它们出现的时间都非常接近，比如Linux和Windows都是在90年代初出现，Java开发中的各类MVC框架也基本都是同期出现，Android和iOS也是前脚后脚问世。 2011年前后，各种NoSQL数据库也是层出不群，我也是在那个时候参与开发了阿里巴巴自己的NoSQL系统。

事物发展有自己的潮流和规律，当你身处潮流之中的时候，要紧紧抓住潮流的机会，想办法脱颖而出，即使没有成功，也会更加洞悉时代的脉搏，收获珍贵的知识和经验。而如果潮流已经退去，这个时候再去往这个方向上努力，只会收获迷茫与压抑，对时代、对自己都没有什么帮助。

但是时代的浪潮犹如海滩上的浪花，总是一浪接着一浪，只要你站在海边，身处这个行业之中，下一个浪潮很快又会到来。你需要敏感而又深刻地去观察，略去那些浮躁的泡沫，抓住真正潮流的机会，奋力一搏，不管成败，都不会遗憾。

正所谓在历史前进的逻辑中前进，在时代发展的潮流中发展。通俗的说，就是要在风口中飞翔。

上面我讲的这些基本上都可以归类为大数据引擎或者大数据框架。而大数据处理的主要应用场景包括数据分析、数据挖掘与机器学习。数据分析主要使用Hive、Spark SQL等SQL引擎完成；数据挖掘与机器学习则有专门的机器学习框架TensorFlow、Mahout以及MLlib等，内置了主要的机器学习和数据挖掘算法。

此外，大数据要存入分布式文件系统（HDFS），要有序调度MapReduce和Spark作业执行，并能把执行结果写入到各个应用系统的数据库中，还需要有一个大数据平台整合所有这些大数据组件和企业应用系统。

图中的所有这些框架、平台以及相关的算法共同构成了大数据的技术体系，我将会在专栏后面逐个分析，帮你能够对大数据技术原理和应用算法构建起完整的知识体系，进可以专职从事大数据开发，退可以在自己的应用开发中更好地和大数据集成，掌控自己的项目。

希望对您有所帮助！~

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

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

大家把传统关系型数据库称作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浪潮，更加推动了国产分布式数据库的发展利好。值得注意的是，数据库研发是个严肃的事情，没法短平快。

CockroachDB: 弹性、地理分布式SQL 数据库

现代 OLTP 负载正迅速地跨越地域分布，这使得跨国公司必须构建可扩展的应用系统并根据法律法规细粒度地控制数据存放位置。在这种背景下，CockroachDB（CRDB）应运而生，它是一个可扩展的 SQL 数据库管理系统，旨在支持全球性的 OLTP 负载的同时，保持高可用性和强一致性。

CRDB 从头构建，支持在普通商用硬件上实现跨地域的分布式事务，并且能够像蟑螂一样抵御灾难。其创新的事务模型、容错机制和高性能特性使其成为跨国公司理想的选择。此外，CRDB 还提供了 SQL 接口和自动根据数据库集群规模进行伸缩的能力，以满足数据存储和管理的需求。

为了满足跨国公司的需求，CRDB 重点关注以下几个特性：合规性、容错性和高性能。它具有前沿的查询优化器和分布式 SQL 执行引擎，支持在线模式更改、备份和恢复、快速导入、JSON 支持以及与外部分析系统的集成等功能。此外，CRDB 的源码已入驻 GitHub，且从 BSL 许可转为 Apache 开源 2.0 协议，用户无需依赖第三方 SQL 扩展专利或受制于云供应商宕机风险，避免了供应商锁定问题。

本文将详细介绍 CRDB 的各个组成部分，包括架构、复制和数据分布机制、事务模型、时间戳排序、SQL 数据模型、执行和模式变化、性能评估和案例学习、经验总结、相关著作以及结论与展望。接下来，我们将从系统架构角度深入剖析 CRDB 的设计与实现。

系统架构概述

CRDB 使用无共享架构（share-nothing），所有的节点都同时提供存储和计算能力，集群可以包含任意数量的节点，这些节点可以在同一数据中心或分布于全球。客户端可以连接集群中的任何一个节点。

CRDB 的架构可以分为以下几层：

SQL 层

最顶层是 SQL 层，它是所有用户与数据库交互的接口。它包括解析器、优化器和 SQL 执行引擎，该引擎将高级 SQL 语句转换为底层 key-value (KV) 存储的低级读写请求。

通常，SQL 层并不了解数据是如何分区或分布的，因为下面的层抽象了一个单体的 KV 存储。然而，在第 5 节中，我们将详细介绍某些查询如何打破这种抽象，以实现更高效的分布式 SQL 计算。

事务 KV 层

来自 SQL 层的请求被传递到事务 KV 层，该层确保跨越多个 KV 对的原子性更改。它在很大程度上对 CRDB 的隔离保障负有责任。这些原子性和隔离保证将在第 3 节和第 4 节中详细描述。

数据分布层

这一层抽象了按 key 排序的单体逻辑键空间。在这个键空间中，所有数据都是可寻址的，无论是系统数据（用于内部数据结构和元数据）还是用户数据（SQL 表和索引）。

CRDB 对 key 进行范围分区，将数据分成连续有序的，大小约为 64MB 的块，我们把这些块叫做“Ranges”。这些 Ranges 之间的排序由一个两层索引结构维护，保存在一系列系统级别 Rranges 里面，并被预缓存以支持快速的按 key 查询。本层负责确定查询的某个子集应该由哪个 Range 处理，并合理路由。

64MB 的 Range 足够小，可以允许快速迁移，又足够大，足以保存一块连续的经常一起被访问的数据。 Ranges 的初始状态为空，随着尺寸变化，经历分割、合并。 Ranges 分割还可以根据负载进行，以减少 CPU 热点与资源不平衡。

数据复制层

默认情况下，每个 Range 保存 3 个副本，每个副本存储在不同的节点上。在第 2.2 节中，我们将描述复制层如何使用基于共识的复制确保修改的持久性。

存储层

这是最底层，代表一个本地磁盘支持的 KV 存储。它提供了高效的写和范围扫描，以支持高性能的 SQL 执行。在撰写本文时，我们依赖的是 RocksDB，它在其他地方有详细的记录，本论文中将其作为黑盒处理。

容错和高可用性

使用RAFT复制

一个 Range 的所有副本组成一个 Raft group，其中一个副本是持久的 leader，协调所有发给这个 Raft group 的写操作，其他副本是 follower。复制的单元是命令，代表要存储层处理的一个编辑序列。 Raft 在每个 Range 的所有副本范围内，维护一个一致的、排序的更新日志，每个副本各自按顺序在其本地存储引擎里应用那些已经声明被提交的日志。

CRDB 使用 Range 层面上的租约，其中一个副本（通常是 Raft group leader）承担 leaseholder 角色，因此是唯一允许提供权威最新读取或提交写请求给 Raft group leader 的副本。所有写操作都经过了 leaseholder，因此所有的读都可以在不牺牲一致性的情况下绕过 Raft 所需的网络往返成本。

用户级 Ranges 的租约和 leaseholder 所在节点的存活性绑定，存活性通知通过节点每 4.5 秒发送一个特殊心跳到系统级 Range 实现。系统级 Range 转而使用基于到期的租约，必须每 9 秒更新一次。如果某个节点探测到 leaseholder 不存活了，它就尝试自己获取租约。

为了确保每个时间点只有一个副本拥有租约，租约获取在现有的 Raft 框架内完成，提交一个特殊的获取租约日志记录。每个租约获取请求包含一个它在请求时认为合法的租约数据，两个副本的请求内的租约不重叠就可以达成这个保证。在第 4 节中，我们还会讨论租约不重叠是 CRDB 隔离机制的前提。

成员变化与自动负载（再）平衡

集群运行中，节点可能加入或离开该集群，也可能暂时或永久失败。 CRDB 使用相同的方法应对这些场景：在最新的存活节点中间重新分配负载。

节点短暂失败，而多数节点仍然可用的情况下，CRDB 可以持续运行。如果失败的是 Raft group 的 leader，Raft 保证新 leader 的选举。失败节点上先后可以重新加入原来的 group，同伴们帮它追赶错失的更新操作。方法包括：1）发送全量 Range 数据快照给它 2）发送错失的 Raft log 记录集合给它。具体选择根据该副本节点不可用期间错失的操作量作出。

节点长时间失败，CRDB 自动根据存活的副本为复制等级不够的 Ranges 创建出新的足够的副本。其存放位置由下一节描述选择。决策依赖的相关数据比如，存活节点信息、集群监测指标使用点对点的 Gossip 协议分发。

副本存放

支持手动和自动选择。

手动选择需要用户为每个节点配置属性，比如节点特性（特殊硬件、RAM、硬盘类型...）、节点位置（国家、地区、可用 zone...）。还可以在表模式里指定限制、偏好，比如指定 region 列，可以用来帮助分区，和把分区映射到特定地理区域。

自动选择根据用户制定的规则和不同的启发式算法自动跨失败域分布副本，容错不同程度的失败（硬盘级、机架级、数据中心级、区域级别）。