From b0b7a5ebff58dddb3edc077a79932d244d3b53ae Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Mon, 16 Mar 2020 14:14:25 +0800 Subject: [PATCH 01/46] Update tidb-architecture.md --- session1/chapter1/tidb-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter1/tidb-architecture.md b/session1/chapter1/tidb-architecture.md index e3f59fb1b7..2e1f8616f7 100644 --- a/session1/chapter1/tidb-architecture.md +++ b/session1/chapter1/tidb-architecture.md @@ -1,6 +1,6 @@ # 第1章 TiDB 整体架构 -当今时代，企业的数据越来越庞大，应用的规模也越来越复杂，在这个背景之下，传统的单机数据库已经在很多场景下表现的力不从心，为了解决海量数据平台的扩展性的问题，TiDB 分布式数据库应运而生。 +近年来，随着移动互联网、云计算、大数据和人工智能等技术的飞速发展，给各行业带来了深刻的影响和变革，使得企业的数据量越来越庞大，应用的规模也越来越复杂。在这个背景之下，传统的单机数据库已经在很多场景下表现的力不从心，为了解决海量数据平台的扩展性的问题，TiDB 分布式数据库应运而生。 TiDB 是当今开源 NewSQL 数据库领域的代表产品之一，相比传统的单机数据库，TiDB 有以下的一些优势： * 纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容 From 02de1254fb24bcc35730df5a4aecf84066f83a31 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Mon, 16 Mar 2020 14:43:59 +0800 Subject: [PATCH 02/46] Update tidb-architecture.md --- session1/chapter1/tidb-architecture.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/session1/chapter1/tidb-architecture.md b/session1/chapter1/tidb-architecture.md index 2e1f8616f7..9eacf16a4e 100644 --- a/session1/chapter1/tidb-architecture.md +++ b/session1/chapter1/tidb-architecture.md @@ -4,10 +4,10 @@ TiDB 是当今开源 NewSQL 数据库领域的代表产品之一，相比传统的单机数据库，TiDB 有以下的一些优势： * 纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容 -* 支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，大多数场景下是可以直接替换 MySQL -* 默认支持高可用，在部分节点失效的情况下，数据库本身自动进行数据修复和故障转移，对业务透明 +* 支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL +* 默认支持高可用，在少数节点失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明 * 支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账 -* 有丰富的工具链生态，覆盖数据迁移、同步、备份等场景 +* 具有丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景 本书会专注于 TiDB 4.0 的实操与最佳实践，详细介绍 TiDB 的使用和一些相关的原理。 @@ -21,6 +21,6 @@ TiDB 分布式数据库最初的设计受到 Google 内部开发的知名分布 1. TiDB (tidb-server, [https://github.com/pingcap/tidb](https://github.com/pingcap/tidb)): SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，客户端的连接可以均匀的分摊在多个 TiDB 实例上以达到负载均衡的效果。tidb-server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储层 TiKV。 -2. TiKV (tikv-server, [https://github.com/pingcap/tikv](https://github.com/pingcap/tikv)) : 分布式 KV 存储，类似 NoSQL 数据库，作为 TiDB 的默认分布式存储引擎，支持完全弹性的扩容和缩容，数据分布在多个 TiKV 存储节点中，系统会动态且自动地进行均衡，绝大多数情况下不需要人工介入。与普通的 NoSQL 系统不一样的是，TiKV 的 API 原生支持在 KV 键值对层面的分布式事务，默认提供了 SI （Snapshot Isolation）的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心，上面提到的 TiDB SQL 层做完 SQL 解析后，会将 SQL 的执行计划变成实际的 TiKV 的 KV API 调用。所以实际上数据都是存储在 TiKV 中。另外，TiKV 中的数据都会自动维护多副本（默认为 3），天然支持高可用和自动故障转移。TiFlash 是一类特殊的存储节点，和普通 TiKV 节点不一样的是，在 TiFlash 内部数据是以列式的形式存储，主要的功能是为分析型的场景加速。后面的章节会详细介绍。 +2. TiKV (tikv-server, [https://github.com/pingcap/tikv](https://github.com/pingcap/tikv)) : 分布式 KV 存储，类似 NoSQL 数据库，作为 TiDB 的默认分布式存储引擎，支持完全弹性的扩容和缩容，数据分布在多个 TiKV 存储节点中，系统会动态且自动地进行均衡，绝大多数情况下不需要人工介入。与普通的 NoSQL 系统不一样的是，TiKV 的 API 能够在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI （Snapshot Isolation）的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心，上面提到的 TiDB SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为实际对 TiKV API 的调用。所以实际上数据都是存储在 TiKV 中。另外，TiKV 中的数据都会自动维护多副本（默认为 3），天然支持高可用和自动故障转移。TiFlash 是一类特殊的存储节点，和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。后面的章节会详细介绍。 -3. Placement Driver (pd-server，简称 PD，[https://github.com/pingcap/pd](https://github.com/pingcap/pd)): 整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 Dashboard 管控界面，并为分布式事务分配事务 ID。PD 不仅仅是单纯的元信息存储，同时 PD 会根据实时的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的「大脑」，另外 PD 本身也是由至少 3 个对等节点构成，拥有高可用的能力。 +3. Placement Driver (pd-server，简称 PD，[https://github.com/pingcap/pd](https://github.com/pingcap/pd)): 整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 Dashboard 管控界面，并为分布式事务分配事务 ID。PD 不仅仅是单纯的元信息存储，同时 PD 会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的「大脑」，另外 PD 本身也是由至少 3 个对等节点构成，拥有高可用的能力。 From 446f2c36d8eb1ff20c8683d96ee0ea5bebcd3dd7 Mon Sep 17 00:00:00 2001 From: kissmydb Date: Mon, 16 Mar 2020 16:53:11 +0800 Subject: [PATCH 03/46] Update session1/chapter1/tidb-architecture.md --- session1/chapter1/tidb-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter1/tidb-architecture.md b/session1/chapter1/tidb-architecture.md index 9eacf16a4e..1ed2ec1d50 100644 --- a/session1/chapter1/tidb-architecture.md +++ b/session1/chapter1/tidb-architecture.md @@ -5,7 +5,7 @@ TiDB 是当今开源 NewSQL 数据库领域的代表产品之一，相比传统 * 纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容 * 支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL -* 默认支持高可用，在少数节点失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明 +* 默认支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明 * 支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账 * 具有丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景 From 06e4817474b8f87dfb49a12bf2d7ace953706aa1 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 17 Mar 2020 13:31:44 +0800 Subject: [PATCH 04/46] Update tidb-metadata-management.md --- session1/chapter3/tidb-metadata-management.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/session1/chapter3/tidb-metadata-management.md b/session1/chapter3/tidb-metadata-management.md index 1ac93cf7e7..01e51cb4a1 100644 --- a/session1/chapter3/tidb-metadata-management.md +++ b/session1/chapter3/tidb-metadata-management.md @@ -2,4 +2,6 @@ 上节介绍了表中的数据和索引如何映射为 (Key, Value) 键值对，本节介绍一下元信息的存储。TiDB 中每个 `Database` 和 `Table` 都有元信息，也就是其定义以及各项属性，这些信息也需要持久化，TiDB 也将这些信息存储在了 TiKV 中。 -每个 `Database`/`Table` 都被分配了一个唯一的 ID，这个 ID 作为唯一标识，并且在编码为 Key-Value 时，这个 ID 都会编码到 Key 中，再加上 `m_` 前缀。这样可以构造出一个 Key，Value 中存储的是序列化后的元信息。除此之外，还有一个专门的 (Key, Value) 键值对用于存储当前所有表结构信息的最新版本号（TiDB 使用 Google F1 的 Online Schema 变更算法，有一个后台线程在不断的检查 TiKV 上面存储的表结构信息的版本号是否发生变化，并且保证在一定时间内一定能够获取版本的变化）。 +每个 `Database`/`Table` 都被分配了一个唯一的 ID，这个 ID 作为唯一标识，并且在编码为 Key-Value 时，这个 ID 都会编码到 Key 中，再加上 `m_` 前缀。这样可以构造出一个 Key，Value 中存储的是序列化后的元信息。 + +除此之外，还有一个专门的 (Key, Value) 键值对用于存储当前所有表结构信息的最新版本号，这个键值对是全局的，每次 DDL 操作的状态改变时这个版本号都会加1。目前，TiDB 在实现时把这个键值对存放在 pd-server 内置的 etcd 中，其Key 为"/tidb/ddl/global_schema_version"，Value 是类型为 int64 的版本号值。 TiDB 使用 Google F1 的 Online Schema 变更算法，有一个后台线程在不断的检查 etcd 中存储的表结构信息的版本号是否发生变化，并且保证在一定时间内一定能够获取版本的变化。 From 82d9d77ac00593b9beca275b434ddcdedde894dc Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 17 Mar 2020 14:03:01 +0800 Subject: [PATCH 05/46] Update tidb-sql-layer-summary.md --- session1/chapter3/tidb-sql-layer-summary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter3/tidb-sql-layer-summary.md b/session1/chapter3/tidb-sql-layer-summary.md index 0be07e5fc7..5aae594b11 100644 --- a/session1/chapter3/tidb-sql-layer-summary.md +++ b/session1/chapter3/tidb-sql-layer-summary.md @@ -1,6 +1,6 @@ ## 3.3 SQL 层简介 -TiDB 的 SQL层，即 tidb-server，跟 Google 的 [F1](https://dbdb.io/db/google-f1) 比较类似，负责将 SQL 翻译成 KV 操作，转发给共享的分布式 KV 存储层 TiKV，并组装返回结果，最终返回查询结果。 +TiDB 的 SQL层，即 tidb-server，跟 Google 的 [F1](https://dbdb.io/db/google-f1) 比较类似，负责将 SQL 翻译成 KV 操作，转发给共享的分布式 KV 存储层 TiKV，并组装 TiKV 返回的结果，最终将查询结果返回给客户端。 这一层的节点都是无状态的节点，本身并不存储数据，节点之间完全对等。 From 6c7d68bf20dd24bf3da1b803b2a0f8d839b97444 Mon Sep 17 00:00:00 2001 From: kissmydb Date: Wed, 18 Mar 2020 22:59:09 +0800 Subject: [PATCH 06/46] Update session1/chapter1/tidb-architecture.md --- session1/chapter1/tidb-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter1/tidb-architecture.md b/session1/chapter1/tidb-architecture.md index 1ed2ec1d50..ce720a4add 100644 --- a/session1/chapter1/tidb-architecture.md +++ b/session1/chapter1/tidb-architecture.md @@ -3,7 +3,7 @@ 近年来，随着移动互联网、云计算、大数据和人工智能等技术的飞速发展，给各行业带来了深刻的影响和变革，使得企业的数据量越来越庞大，应用的规模也越来越复杂。在这个背景之下，传统的单机数据库已经在很多场景下表现的力不从心，为了解决海量数据平台的扩展性的问题，TiDB 分布式数据库应运而生。 TiDB 是当今开源 NewSQL 数据库领域的代表产品之一，相比传统的单机数据库，TiDB 有以下的一些优势： -* 纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容 +* 纯分布式架构，拥有良好的扩展性，支持弹性扩缩容 * 支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL * 默认支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明 * 支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账 From 2b7bc8ec432438ca1bb37ae8b1f939e9aa1d2256 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Thu, 19 Mar 2020 10:04:08 +0800 Subject: [PATCH 07/46] Update tidb-architecture.md --- session1/chapter1/tidb-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter1/tidb-architecture.md b/session1/chapter1/tidb-architecture.md index ce720a4add..1ed2ec1d50 100644 --- a/session1/chapter1/tidb-architecture.md +++ b/session1/chapter1/tidb-architecture.md @@ -3,7 +3,7 @@ 近年来，随着移动互联网、云计算、大数据和人工智能等技术的飞速发展，给各行业带来了深刻的影响和变革，使得企业的数据量越来越庞大，应用的规模也越来越复杂。在这个背景之下，传统的单机数据库已经在很多场景下表现的力不从心，为了解决海量数据平台的扩展性的问题，TiDB 分布式数据库应运而生。 TiDB 是当今开源 NewSQL 数据库领域的代表产品之一，相比传统的单机数据库，TiDB 有以下的一些优势： -* 纯分布式架构，拥有良好的扩展性，支持弹性扩缩容 +* 纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容 * 支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL * 默认支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明 * 支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账 From d8a324d4cc116d4dae347f41ca2da35c7feeab39 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 31 Mar 2020 13:39:04 +0800 Subject: [PATCH 08/46] Update scheduling-overview.md --- session1/chapter4/scheduling-overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/session1/chapter4/scheduling-overview.md b/session1/chapter4/scheduling-overview.md index 40da6012e1..400ef1d241 100644 --- a/session1/chapter4/scheduling-overview.md +++ b/session1/chapter4/scheduling-overview.md @@ -1,5 +1,5 @@ # 4 讲调度 -任何一个复杂的系统，用户感知到的都只是冰山一角，数据库也不例外。前两篇文章介绍了 TiKV、TiDB 的基本概念以及一些核心功能的实现原理，这两个组件一个负责 KV 存储，一个负责 SQL 引擎，都是大家看得见的东西。在这两个组件的后面，还有一个叫做 PD（Placement Driver）的组件，虽然不直接和业务接触，但是这个组件是整个集群的核心，负责全局元信息的存储以及 TiKV 集群负载均衡调度。 +任何一个复杂的系统，用户感知到的都只是冰山一角，数据库也不例外。前两节介绍了 TiKV、TiDB 的基本概念以及一些核心功能的实现原理，这两个组件一个负责 KV 存储，一个负责 SQL 引擎，都是大家看得见的东西。在这两个组件的后面，还有一个叫做 PD（Placement Driver）的组件，虽然不直接和业务接触，但是这个组件是整个集群的核心，负责全局元信息的存储以及 TiKV 集群负载均衡调度。 ## 4.1 调度概述 本篇文章介绍一下这个神秘的模块。这部分比较复杂，很多东西大家平时不会想到，也很少在其他文章中见到类似的东西的描述。我们还是按照前两篇的思路，先讲我们需要什么样的功能，再讲我们如何实现，大家带着需求去看实现，会更容易的理解我们做这些设计时背后的考量。 @@ -122,4 +122,4 @@ Raft 协议要求读取和写入都通过 Leader 进行，所以计算的负载 PD 不断的通过 Store 或者 Leader 的心跳包收集信息，获得整个集群的详细数据，并且根据这些信息以及调度策略生成调度操作序列。每次收到 Region Leader 发来的心跳包时，PD 都会检查这个 Region 是否有待进行的操作，然后通过心跳包的回复消息，将需要进行的操作返回给 Region Leader，并在后面的心跳包中监测执行结果。注意这里的操作只是给 Region Leader 的建议，并不保证一定能得到执行，具体是否会执行以及什么时候执行，由 Region Leader 自己根据当前自身状态来定。 ### 4.1.7 总结 -本篇文章讲的东西，大家可能平时很少会在其他文章中看到，每一个设计都有背后的考量，希望大家能了解到一个分布式存储系统在做调度的时候，需要考虑哪些东西，如何将策略、实现进行解耦，更灵活的支持策略的扩展。 \ No newline at end of file +本篇文章讲的东西，大家可能平时很少会在其他文章中看到，每一个设计都有背后的考量，希望大家能了解到一个分布式存储系统在做调度的时候，需要考虑哪些东西，如何将策略、实现进行解耦，更灵活的支持策略的扩展。 From 80c65b7d8ff75b08b34d059aea5796dcf6e55c23 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 31 Mar 2020 13:40:14 +0800 Subject: [PATCH 09/46] Update scheduling-overview.md --- session1/chapter4/scheduling-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter4/scheduling-overview.md b/session1/chapter4/scheduling-overview.md index 400ef1d241..51a703dd34 100644 --- a/session1/chapter4/scheduling-overview.md +++ b/session1/chapter4/scheduling-overview.md @@ -2,7 +2,7 @@ 任何一个复杂的系统，用户感知到的都只是冰山一角，数据库也不例外。前两节介绍了 TiKV、TiDB 的基本概念以及一些核心功能的实现原理，这两个组件一个负责 KV 存储，一个负责 SQL 引擎，都是大家看得见的东西。在这两个组件的后面，还有一个叫做 PD（Placement Driver）的组件，虽然不直接和业务接触，但是这个组件是整个集群的核心，负责全局元信息的存储以及 TiKV 集群负载均衡调度。 ## 4.1 调度概述 -本篇文章介绍一下这个神秘的模块。这部分比较复杂，很多东西大家平时不会想到，也很少在其他文章中见到类似的东西的描述。我们还是按照前两篇的思路，先讲我们需要什么样的功能，再讲我们如何实现，大家带着需求去看实现，会更容易的理解我们做这些设计时背后的考量。 +本节将介绍一下这个神秘的模块。这部分比较复杂，很多东西大家平时不会想到，也很少在其他文章中见到类似的东西的描述。我们还是按照前两篇的思路，先讲我们需要什么样的功能，再讲我们如何实现，大家带着需求去看实现，会更容易的理解我们做这些设计时背后的考量。 ### 4.1.1 为什么要进行调度 在第一篇文章提到的一些信息，TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为单位进行复制和管理，每个 Region 会有多个 Replica（副本），这些 Replica 会分布在不同的 TiKV 节点上，其中 Leader 负责读/写，Follower 负责同步 Leader 发来的 raft log。了解了这些信息后，请思考下面这些问题： From 4c73f0a3a500e303dbb743d6ed9c49a4c9033b67 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 31 Mar 2020 13:41:20 +0800 Subject: [PATCH 10/46] Update scheduling-overview.md --- session1/chapter4/scheduling-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter4/scheduling-overview.md b/session1/chapter4/scheduling-overview.md index 51a703dd34..b47dd37168 100644 --- a/session1/chapter4/scheduling-overview.md +++ b/session1/chapter4/scheduling-overview.md @@ -2,7 +2,7 @@ 任何一个复杂的系统，用户感知到的都只是冰山一角，数据库也不例外。前两节介绍了 TiKV、TiDB 的基本概念以及一些核心功能的实现原理，这两个组件一个负责 KV 存储，一个负责 SQL 引擎，都是大家看得见的东西。在这两个组件的后面，还有一个叫做 PD（Placement Driver）的组件，虽然不直接和业务接触，但是这个组件是整个集群的核心，负责全局元信息的存储以及 TiKV 集群负载均衡调度。 ## 4.1 调度概述 -本节将介绍一下这个神秘的模块。这部分比较复杂，很多东西大家平时不会想到，也很少在其他文章中见到类似的东西的描述。我们还是按照前两篇的思路，先讲我们需要什么样的功能，再讲我们如何实现，大家带着需求去看实现，会更容易的理解我们做这些设计时背后的考量。 +本节将介绍一下这个神秘的模块。这部分比较复杂，很多东西大家平时不会想到，也很少在其他文章中见到类似东西的描述。我们还是按照前两篇的思路，先讲我们需要什么样的功能，再讲我们如何实现，大家带着需求去看实现，会更容易的理解我们做这些设计时背后的考量。 ### 4.1.1 为什么要进行调度 在第一篇文章提到的一些信息，TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为单位进行复制和管理，每个 Region 会有多个 Replica（副本），这些 Replica 会分布在不同的 TiKV 节点上，其中 Leader 负责读/写，Follower 负责同步 Leader 发来的 raft log。了解了这些信息后，请思考下面这些问题： From 26e2a2227ccf587040433f62515a17cc60a15a80 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 31 Mar 2020 13:42:01 +0800 Subject: [PATCH 11/46] Update scheduling-overview.md --- session1/chapter4/scheduling-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter4/scheduling-overview.md b/session1/chapter4/scheduling-overview.md index b47dd37168..a22edafb26 100644 --- a/session1/chapter4/scheduling-overview.md +++ b/session1/chapter4/scheduling-overview.md @@ -2,7 +2,7 @@ 任何一个复杂的系统，用户感知到的都只是冰山一角，数据库也不例外。前两节介绍了 TiKV、TiDB 的基本概念以及一些核心功能的实现原理，这两个组件一个负责 KV 存储，一个负责 SQL 引擎，都是大家看得见的东西。在这两个组件的后面，还有一个叫做 PD（Placement Driver）的组件，虽然不直接和业务接触，但是这个组件是整个集群的核心，负责全局元信息的存储以及 TiKV 集群负载均衡调度。 ## 4.1 调度概述 -本节将介绍一下这个神秘的模块。这部分比较复杂，很多东西大家平时不会想到，也很少在其他文章中见到类似东西的描述。我们还是按照前两篇的思路，先讲我们需要什么样的功能，再讲我们如何实现，大家带着需求去看实现，会更容易的理解我们做这些设计时背后的考量。 +本节将介绍一下这个神秘的模块。这部分比较复杂，很多东西大家平时不会想到，也很少在其他文章中见到类似东西的描述。我们还是按照前两节的思路，先讲我们需要什么样的功能，再讲我们如何实现，大家带着需求去看实现，会更容易的理解我们做这些设计时背后的考量。 ### 4.1.1 为什么要进行调度 在第一篇文章提到的一些信息，TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为单位进行复制和管理，每个 Region 会有多个 Replica（副本），这些 Replica 会分布在不同的 TiKV 节点上，其中 Leader 负责读/写，Follower 负责同步 Leader 发来的 raft log。了解了这些信息后，请思考下面这些问题： From 76907923600e4b61cfb6431c8536aee8f2c519ae Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 31 Mar 2020 13:44:39 +0800 Subject: [PATCH 12/46] Update scheduling-overview.md --- session1/chapter4/scheduling-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter4/scheduling-overview.md b/session1/chapter4/scheduling-overview.md index a22edafb26..3d2c5cf1af 100644 --- a/session1/chapter4/scheduling-overview.md +++ b/session1/chapter4/scheduling-overview.md @@ -5,7 +5,7 @@ 本节将介绍一下这个神秘的模块。这部分比较复杂，很多东西大家平时不会想到，也很少在其他文章中见到类似东西的描述。我们还是按照前两节的思路，先讲我们需要什么样的功能，再讲我们如何实现，大家带着需求去看实现，会更容易的理解我们做这些设计时背后的考量。 ### 4.1.1 为什么要进行调度 -在第一篇文章提到的一些信息，TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为单位进行复制和管理，每个 Region 会有多个 Replica（副本），这些 Replica 会分布在不同的 TiKV 节点上，其中 Leader 负责读/写，Follower 负责同步 Leader 发来的 raft log。了解了这些信息后，请思考下面这些问题： +在前面介绍TiKV的提到，TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为单位进行复制和管理，每个 Region 会有多个 Replica（副本），这些 Replica 会分布在不同的 TiKV 节点上，其中 Leader 负责读/写，Follower 负责同步 Leader 发来的 raft log。了解了这些信息后，请思考下面这些问题： * 如何保证同一个 Region 的多个 Replica 分布在不同的节点上？更进一步，如果在一台机器上启动多个 TiKV 实例，会有什么问题？ * TiKV 集群进行跨机房部署用于容灾的时候，如何保证一个机房掉线，不会丢失 Raft Group 的多个 Replica？ From 0d20b3ef7912e967b0a9855a010688526288864b Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 31 Mar 2020 13:45:03 +0800 Subject: [PATCH 13/46] Update scheduling-overview.md --- session1/chapter4/scheduling-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter4/scheduling-overview.md b/session1/chapter4/scheduling-overview.md index 3d2c5cf1af..6316b94e76 100644 --- a/session1/chapter4/scheduling-overview.md +++ b/session1/chapter4/scheduling-overview.md @@ -5,7 +5,7 @@ 本节将介绍一下这个神秘的模块。这部分比较复杂，很多东西大家平时不会想到，也很少在其他文章中见到类似东西的描述。我们还是按照前两节的思路，先讲我们需要什么样的功能，再讲我们如何实现，大家带着需求去看实现，会更容易的理解我们做这些设计时背后的考量。 ### 4.1.1 为什么要进行调度 -在前面介绍TiKV的提到，TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为单位进行复制和管理，每个 Region 会有多个 Replica（副本），这些 Replica 会分布在不同的 TiKV 节点上，其中 Leader 负责读/写，Follower 负责同步 Leader 发来的 raft log。了解了这些信息后，请思考下面这些问题： +在前面介绍 TiKV 时提到，TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为单位进行复制和管理，每个 Region 会有多个 Replica（副本），这些 Replica 会分布在不同的 TiKV 节点上，其中 Leader 负责读/写，Follower 负责同步 Leader 发来的 raft log。了解了这些信息后，请思考下面这些问题： * 如何保证同一个 Region 的多个 Replica 分布在不同的节点上？更进一步，如果在一台机器上启动多个 TiKV 实例，会有什么问题？ * TiKV 集群进行跨机房部署用于容灾的时候，如何保证一个机房掉线，不会丢失 Raft Group 的多个 Replica？ From 0f99d1b23b6fbba2a6b2d463eb9c3c553eaae867 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 31 Mar 2020 13:48:35 +0800 Subject: [PATCH 14/46] Update scheduling-overview.md --- session1/chapter4/scheduling-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter4/scheduling-overview.md b/session1/chapter4/scheduling-overview.md index 6316b94e76..96d3fb3b21 100644 --- a/session1/chapter4/scheduling-overview.md +++ b/session1/chapter4/scheduling-overview.md @@ -10,7 +10,7 @@ * 如何保证同一个 Region 的多个 Replica 分布在不同的节点上？更进一步，如果在一台机器上启动多个 TiKV 实例，会有什么问题？ * TiKV 集群进行跨机房部署用于容灾的时候，如何保证一个机房掉线，不会丢失 Raft Group 的多个 Replica？ * 添加一个节点进入 TiKV 集群之后，如何将集群中其他节点上的数据搬过来? -* 当一个节点掉线时，会出现什么问题？整个集群需要做什么事情？如果节点只是短暂掉线（重启服务），那么如何处理？如果节点是长时间掉线（磁盘故障，数据全部丢失），需要如何处理？假设集群需要每个 Raft Group 有 N 个副本，那么对于单个 Raft Group 来说，Replica 数量可能会不够多（例如节点掉线，失去副本），也可能会 过于多（例如掉线的节点又回复正常，自动加入集群）。那么如何调节 Replica 个数？ +* 当一个节点掉线时，会出现什么问题？整个集群需要做什么事情？如果节点只是短暂掉线（重启服务），那么如何处理？如果节点是长时间掉线（磁盘故障，数据全部丢失），需要如何处理？假设集群需要每个 Raft Group 有 N 个副本，那么对于单个 Raft Group 来说，Replica 数量可能会不够多（例如：节点掉线，失去副本），也可能会过于多（例如：掉线的节点又恢复正常，自动加入集群）。那么如何调节 Replica 个数？ * 读/写都是通过 Leader 进行，如果 Leader 只集中在少量节点上，会对集群有什么影响？ * 并不是所有的 Region 都被频繁的访问，可能访问热点只在少数几个 Region，这个时候我们需要做什么？ * 集群在做负载均衡的时候，往往需要搬迁数据，这种数据的迁移会不会占用大量的网络带宽、磁盘 IO 以及 CPU？进而影响在线服务？ From 11f334a1d48c944a67cdd3e226bf9530bf7feaba Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 31 Mar 2020 13:51:55 +0800 Subject: [PATCH 15/46] Update scheduling-overview.md --- session1/chapter4/scheduling-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter4/scheduling-overview.md b/session1/chapter4/scheduling-overview.md index 96d3fb3b21..d0ef140ff6 100644 --- a/session1/chapter4/scheduling-overview.md +++ b/session1/chapter4/scheduling-overview.md @@ -15,7 +15,7 @@ * 并不是所有的 Region 都被频繁的访问，可能访问热点只在少数几个 Region，这个时候我们需要做什么？ * 集群在做负载均衡的时候，往往需要搬迁数据，这种数据的迁移会不会占用大量的网络带宽、磁盘 IO 以及 CPU？进而影响在线服务？ -这些问题单独拿出可能都能找到简单的解决方案，但是混杂在一起，就不太好解决。有的问题貌似只需要考虑单个 Raft Group 内部的情况，比如根据副本数量是否足够多来决定是否需要添加副本。但是实际上这个副本添加在哪里，是需要考虑全局的信息。整个系统也是在动态变化，Region 分裂、节点加入、节点失效、访问热点变化等情况会不断发生，整个调度系统也需要在动态中不断向最优状态前进，如果没有一个掌握全局信息，可以对全局进行调度，并且可以配置的组件，就很难满足这些需求。因此我们需要一个中心节点，来对系统的整体状况进行把控和调整，所以有了 PD 这个模块。 +这些问题单独拿出可能都能找到简单的解决方案，但是混杂在一起，就不太好解决。有的问题貌似只需要考虑单个 Raft Group 内部的情况，比如根据副本数量是否足够多来决定是否需要添加副本。但是实际上这个副本添加在哪里，是需要考虑全局的信息。整个系统也是在动态变化的，Region 分裂、节点加入、节点失效、访问热点变化等情况会不断发生，整个调度系统也需要在动态中不断向最优状态前进。如果没有一个掌握全局信息，可以对全局进行调度，并且可以配置的组件，就很难满足这些需求。因此我们需要一个中心节点，来对系统的整体状况进行把控和调整，所以有了 PD 这个模块。 ### 4.1.2 调度的需求 上面罗列了一大堆问题，我们先进行分类和整理。总体来看，问题有两大类： From 5547442febd01b85359de48c408f129a12a17672 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 31 Mar 2020 13:56:08 +0800 Subject: [PATCH 16/46] Update scheduling-overview.md --- session1/chapter4/scheduling-overview.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/session1/chapter4/scheduling-overview.md b/session1/chapter4/scheduling-overview.md index d0ef140ff6..c1be6be16d 100644 --- a/session1/chapter4/scheduling-overview.md +++ b/session1/chapter4/scheduling-overview.md @@ -30,8 +30,9 @@ **作为一个良好的分布式系统，需要优化的地方，包括：** * 维持整个集群的 Leader 分布均匀 -* 维持每个节点的储存容量均匀 -* 维持访问热点分布均匀控制 Balance 的速度，避免影响在线服务 +* 维持每个节点的存储容量均匀 +* 维持访问热点分布均匀，尽量不要集中在某个或某几个节点上 +* 控制 Balance 的速度，避免影响在线服务 * 管理节点状态，包括手动上线/下线节点，以及自动下线失效节点 满足第一类需求后，整个系统将具备多副本容错、动态扩容/缩容、容忍节点掉线以及自动错误恢复的功能。满足第二类需求后，可以使得整体系统的负载更加均匀、且可以方便的管理。 From 55118a3f1488c853adcf1340d6069aa1661b1ced Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 31 Mar 2020 13:57:05 +0800 Subject: [PATCH 17/46] Update scheduling-overview.md --- session1/chapter4/scheduling-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter4/scheduling-overview.md b/session1/chapter4/scheduling-overview.md index c1be6be16d..c5ca555430 100644 --- a/session1/chapter4/scheduling-overview.md +++ b/session1/chapter4/scheduling-overview.md @@ -35,7 +35,7 @@ * 控制 Balance 的速度，避免影响在线服务 * 管理节点状态，包括手动上线/下线节点，以及自动下线失效节点 -满足第一类需求后，整个系统将具备多副本容错、动态扩容/缩容、容忍节点掉线以及自动错误恢复的功能。满足第二类需求后，可以使得整体系统的负载更加均匀、且可以方便的管理。 +满足第一类需求后，整个系统将具备多副本容错、动态扩容/缩容、容忍节点掉线以及自动错误恢复的功能。满足第二类需求后，可以使得系统整体的负载更加均匀、且可以方便的管理。 为了满足这些需求，首先我们需要收集足够的信息，比如每个节点的状态、每个 Raft Group 的信息、业务访问操作的统计等；其次需要设置一些策略，PD 根据这些信息以及调度的策略，制定出尽量满足前面所述需求的调度计划；最后需要一些基本的操作，来完成调度计划。 From 5aecbe536af492fb49d079d0e9557ed57199f86c Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 31 Mar 2020 13:57:33 +0800 Subject: [PATCH 18/46] Update scheduling-overview.md --- session1/chapter4/scheduling-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter4/scheduling-overview.md b/session1/chapter4/scheduling-overview.md index c5ca555430..ac643f6cb8 100644 --- a/session1/chapter4/scheduling-overview.md +++ b/session1/chapter4/scheduling-overview.md @@ -35,7 +35,7 @@ * 控制 Balance 的速度，避免影响在线服务 * 管理节点状态，包括手动上线/下线节点，以及自动下线失效节点 -满足第一类需求后，整个系统将具备多副本容错、动态扩容/缩容、容忍节点掉线以及自动错误恢复的功能。满足第二类需求后，可以使得系统整体的负载更加均匀、且可以方便的管理。 +满足第一类需求后，整个系统将具备多副本容错、动态扩容/缩容、容忍节点掉线以及自动错误恢复的功能。满足第二类需求后，可以使得系统整体的负载更加均匀，并且可以方便的管理。 为了满足这些需求，首先我们需要收集足够的信息，比如每个节点的状态、每个 Raft Group 的信息、业务访问操作的统计等；其次需要设置一些策略，PD 根据这些信息以及调度的策略，制定出尽量满足前面所述需求的调度计划；最后需要一些基本的操作，来完成调度计划。 From cde0dd543a6baf762ef267658ac4a6504abad9db Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 31 Mar 2020 14:08:12 +0800 Subject: [PATCH 19/46] Update scheduling-overview.md --- session1/chapter4/scheduling-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter4/scheduling-overview.md b/session1/chapter4/scheduling-overview.md index ac643f6cb8..b0e111dc03 100644 --- a/session1/chapter4/scheduling-overview.md +++ b/session1/chapter4/scheduling-overview.md @@ -123,4 +123,4 @@ Raft 协议要求读取和写入都通过 Leader 进行，所以计算的负载 PD 不断的通过 Store 或者 Leader 的心跳包收集信息，获得整个集群的详细数据，并且根据这些信息以及调度策略生成调度操作序列。每次收到 Region Leader 发来的心跳包时，PD 都会检查这个 Region 是否有待进行的操作，然后通过心跳包的回复消息，将需要进行的操作返回给 Region Leader，并在后面的心跳包中监测执行结果。注意这里的操作只是给 Region Leader 的建议，并不保证一定能得到执行，具体是否会执行以及什么时候执行，由 Region Leader 自己根据当前自身状态来定。 ### 4.1.7 总结 -本篇文章讲的东西，大家可能平时很少会在其他文章中看到，每一个设计都有背后的考量，希望大家能了解到一个分布式存储系统在做调度的时候，需要考虑哪些东西，如何将策略、实现进行解耦，更灵活的支持策略的扩展。 +本节所介绍的内容，大家可能平时很少会在其他文章中看到，每一个设计都有背后的考量，希望大家能了解到一个分布式存储系统在做调度的时候，需要考虑哪些东西，如何将策略、实现进行解耦，更灵活的支持策略的扩展。 From 68126f24682f532e54bdf09bcb7b7ef3dd0ffeeb Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Thu, 2 Apr 2020 14:26:20 +0800 Subject: [PATCH 20/46] Update tiflash-intro.md --- session1/chapter9/tiflash-intro.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/session1/chapter9/tiflash-intro.md b/session1/chapter9/tiflash-intro.md index e69de29bb2..e178c30346 100644 --- a/session1/chapter9/tiflash-intro.md +++ b/session1/chapter9/tiflash-intro.md @@ -0,0 +1,7 @@ +# 第9章 TiFlash 简介与 HTAP 实战 + +近年来，随着企业数字化转型的不断深入和发展，数据逐渐成为企业最重要的资产。对于每一个企业来说，从数据的产生、存储、分析到利用，并发挥其巨大的价值，需要关注数据的全生命周期。此外，随着企业之间竞争的不断加剧，对数据的产生到数据发挥价值的时间延迟要求越来越短。 + +作为存储和处理数据最重要的基础软件——数据库系统，一般可以按照负载类型分成 OLTP 型数据库和 OLAP 数据库。在一个企业中，这两种类型的数据库通常是并存的，分别支撑这两种负载类型的应用系统。目前，很多企业的这两种类型的系统之间是通过较为复杂的ETL过程“打通的”，数据在时效性上具有比较大的T+N延时。这越来越难以满足企业在数据处理和分析上对时效性的要求。 + +近几年，HTAP 是比较热的一个概念，它是最有希望解决目前问题的方法。从字面意义上看 HTAP 是混合 OLTP 和 OLAP 业务，能够同时处理这种两种负载的系统。2014年 Garnter 公司给出了严格的定义：混合事务/分析处理( HTAP )是一种新兴的应用体系结构，它打破了事务处理和分析之间的 “墙” 。它支持更多的信息和 “实时业务” 的决策。 From 000bd5609255cca630d4bae82be58c0779641177 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Thu, 2 Apr 2020 14:50:55 +0800 Subject: [PATCH 21/46] Update tiflash-intro.md --- session1/chapter9/tiflash-intro.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/session1/chapter9/tiflash-intro.md b/session1/chapter9/tiflash-intro.md index e178c30346..043fcd728c 100644 --- a/session1/chapter9/tiflash-intro.md +++ b/session1/chapter9/tiflash-intro.md @@ -1,7 +1,9 @@ # 第9章 TiFlash 简介与 HTAP 实战 -近年来，随着企业数字化转型的不断深入和发展，数据逐渐成为企业最重要的资产。对于每一个企业来说，从数据的产生、存储、分析到利用，并发挥其巨大的价值，需要关注数据的全生命周期。此外，随着企业之间竞争的不断加剧，对数据的产生到数据发挥价值的时间延迟要求越来越短。 +近年来，随着企业数字化转型的不断深入和发展，数据逐渐成为企业最重要的资产。对于每一个企业来说，都需要关注从数据的产生、存储、分析到利用，并发挥其巨大的价值的整个过程。此外，随着企业之间竞争的不断加剧，对数据的产生到发挥其价值的时间延迟要求越来越短。 作为存储和处理数据最重要的基础软件——数据库系统，一般可以按照负载类型分成 OLTP 型数据库和 OLAP 数据库。在一个企业中，这两种类型的数据库通常是并存的，分别支撑这两种负载类型的应用系统。目前，很多企业的这两种类型的系统之间是通过较为复杂的ETL过程“打通的”，数据在时效性上具有比较大的T+N延时。这越来越难以满足企业在数据处理和分析上对时效性的要求。 近几年，HTAP 是比较热的一个概念，它是最有希望解决目前问题的方法。从字面意义上看 HTAP 是混合 OLTP 和 OLAP 业务，能够同时处理这种两种负载的系统。2014年 Garnter 公司给出了严格的定义：混合事务/分析处理( HTAP )是一种新兴的应用体系结构，它打破了事务处理和分析之间的 “墙” 。它支持更多的信息和 “实时业务” 的决策。 + +TiDB 是一个具有优异交易处理能力的分布式 NewSQL 产品，同时也具备了良好的分析能力，又是一款优秀的 HTAP 数据数据库产品。在这部分内容中，首先向大家介绍 TiDB HTAP 的主要特点，然后较为详细的介绍其实现 HTAP 能力的关键技术之一的 TiFlash 列式存储引擎的架构和基本原理，最后向大家介绍 TiFlash 如何使用。 From 10b243946c8ad770d0c7c6d015f578b88befae05 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Thu, 2 Apr 2020 14:52:26 +0800 Subject: [PATCH 22/46] Update tiflash-intro.md --- session1/chapter9/tiflash-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter9/tiflash-intro.md b/session1/chapter9/tiflash-intro.md index 043fcd728c..d9a85b5c8f 100644 --- a/session1/chapter9/tiflash-intro.md +++ b/session1/chapter9/tiflash-intro.md @@ -1,6 +1,6 @@ # 第9章 TiFlash 简介与 HTAP 实战 -近年来，随着企业数字化转型的不断深入和发展，数据逐渐成为企业最重要的资产。对于每一个企业来说，都需要关注从数据的产生、存储、分析到利用，并发挥其巨大的价值的整个过程。此外，随着企业之间竞争的不断加剧，对数据的产生到发挥其价值的时间延迟要求越来越短。 +近年来，随着企业数字化转型的不断深入和发展，数据逐渐成为企业最重要的资产。对于每一个企业来说，都需要关注数据从产生、存储、分析到利用，并发挥其巨大价值的整个过程。此外，随着企业之间竞争的不断加剧，对数据的产生到发挥其价值的时间延迟要求越来越短。 作为存储和处理数据最重要的基础软件——数据库系统，一般可以按照负载类型分成 OLTP 型数据库和 OLAP 数据库。在一个企业中，这两种类型的数据库通常是并存的，分别支撑这两种负载类型的应用系统。目前，很多企业的这两种类型的系统之间是通过较为复杂的ETL过程“打通的”，数据在时效性上具有比较大的T+N延时。这越来越难以满足企业在数据处理和分析上对时效性的要求。 From 32f626e37293ce4cbbb829db000d3aa6a90ed866 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Thu, 2 Apr 2020 14:54:26 +0800 Subject: [PATCH 23/46] Update tiflash-intro.md --- session1/chapter9/tiflash-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter9/tiflash-intro.md b/session1/chapter9/tiflash-intro.md index d9a85b5c8f..ed9de8950c 100644 --- a/session1/chapter9/tiflash-intro.md +++ b/session1/chapter9/tiflash-intro.md @@ -2,7 +2,7 @@ 近年来，随着企业数字化转型的不断深入和发展，数据逐渐成为企业最重要的资产。对于每一个企业来说，都需要关注数据从产生、存储、分析到利用，并发挥其巨大价值的整个过程。此外，随着企业之间竞争的不断加剧，对数据的产生到发挥其价值的时间延迟要求越来越短。 -作为存储和处理数据最重要的基础软件——数据库系统，一般可以按照负载类型分成 OLTP 型数据库和 OLAP 数据库。在一个企业中，这两种类型的数据库通常是并存的，分别支撑这两种负载类型的应用系统。目前，很多企业的这两种类型的系统之间是通过较为复杂的ETL过程“打通的”，数据在时效性上具有比较大的T+N延时。这越来越难以满足企业在数据处理和分析上对时效性的要求。 +作为存储和处理数据最重要的基础软件——数据库系统，一般可以按照负载类型分成 OLTP 型数据库和 OLAP 数据库。在一个企业中，这两种类型的数据库通常是并存的，分别支撑这两种负载类型的应用系统。目前，很多企业的这两种类型的系统之间是通过较为复杂的ETL过程“打通的”，数据在时效性上具有比较大的T+N延时，这越来越难以满足企业在数据处理和分析方面对时效性的要求。 近几年，HTAP 是比较热的一个概念，它是最有希望解决目前问题的方法。从字面意义上看 HTAP 是混合 OLTP 和 OLAP 业务，能够同时处理这种两种负载的系统。2014年 Garnter 公司给出了严格的定义：混合事务/分析处理( HTAP )是一种新兴的应用体系结构，它打破了事务处理和分析之间的 “墙” 。它支持更多的信息和 “实时业务” 的决策。 From e631239565687363a4366a4ebba2c02411faf299 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Thu, 2 Apr 2020 14:56:39 +0800 Subject: [PATCH 24/46] Update tiflash-intro.md --- session1/chapter9/tiflash-intro.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/session1/chapter9/tiflash-intro.md b/session1/chapter9/tiflash-intro.md index ed9de8950c..62375e537f 100644 --- a/session1/chapter9/tiflash-intro.md +++ b/session1/chapter9/tiflash-intro.md @@ -4,6 +4,6 @@ 作为存储和处理数据最重要的基础软件——数据库系统，一般可以按照负载类型分成 OLTP 型数据库和 OLAP 数据库。在一个企业中，这两种类型的数据库通常是并存的，分别支撑这两种负载类型的应用系统。目前，很多企业的这两种类型的系统之间是通过较为复杂的ETL过程“打通的”，数据在时效性上具有比较大的T+N延时，这越来越难以满足企业在数据处理和分析方面对时效性的要求。 -近几年，HTAP 是比较热的一个概念，它是最有希望解决目前问题的方法。从字面意义上看 HTAP 是混合 OLTP 和 OLAP 业务，能够同时处理这种两种负载的系统。2014年 Garnter 公司给出了严格的定义：混合事务/分析处理( HTAP )是一种新兴的应用体系结构，它打破了事务处理和分析之间的 “墙” 。它支持更多的信息和 “实时业务” 的决策。 +近几年，HTAP 是比较热的一个概念，它是最有希望解决目前问题的方法。从字面意义上看， HTAP 是混合 OLTP 和 OLAP 业务，能够同时处理这种两种负载的系统。2014年 Garnter 公司给出了严格的定义：混合事务/分析处理( HTAP )是一种新兴的应用体系结构，它打破了事务处理和分析之间的 “墙” 。它支持更多的信息和 “实时业务” 的决策。 -TiDB 是一个具有优异交易处理能力的分布式 NewSQL 产品，同时也具备了良好的分析能力，又是一款优秀的 HTAP 数据数据库产品。在这部分内容中，首先向大家介绍 TiDB HTAP 的主要特点，然后较为详细的介绍其实现 HTAP 能力的关键技术之一的 TiFlash 列式存储引擎的架构和基本原理，最后向大家介绍 TiFlash 如何使用。 +TiDB 是一个具有优异交易处理能力的分布式 NewSQL 产品，同时也具备了良好的分析能力，又是一款优秀的 HTAP 数据数据库产品。在这部分内容中，首先向大家介绍 TiDB HTAP 的主要特点，然后介绍其实现 HTAP 能力的关键技术之一的 TiFlash 列式存储引擎的架构和基本原理，最后向大家介绍 TiFlash 如何使用。 From 9121bcc265d266d5ec0849d643af1122de81b4ae Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Thu, 2 Apr 2020 15:00:17 +0800 Subject: [PATCH 25/46] Update tiflash-intro.md --- session1/chapter9/tiflash-intro.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/session1/chapter9/tiflash-intro.md b/session1/chapter9/tiflash-intro.md index 62375e537f..5ea5d3400c 100644 --- a/session1/chapter9/tiflash-intro.md +++ b/session1/chapter9/tiflash-intro.md @@ -7,3 +7,11 @@ 近几年，HTAP 是比较热的一个概念，它是最有希望解决目前问题的方法。从字面意义上看， HTAP 是混合 OLTP 和 OLAP 业务，能够同时处理这种两种负载的系统。2014年 Garnter 公司给出了严格的定义：混合事务/分析处理( HTAP )是一种新兴的应用体系结构，它打破了事务处理和分析之间的 “墙” 。它支持更多的信息和 “实时业务” 的决策。 TiDB 是一个具有优异交易处理能力的分布式 NewSQL 产品，同时也具备了良好的分析能力，又是一款优秀的 HTAP 数据数据库产品。在这部分内容中，首先向大家介绍 TiDB HTAP 的主要特点，然后介绍其实现 HTAP 能力的关键技术之一的 TiFlash 列式存储引擎的架构和基本原理，最后向大家介绍 TiFlash 如何使用。 + + +## 目录 + +- [9.1 TiDB HTAP 的特点](tidb-htap.md) +- [9.2 TiFlash 架构与原理](tiflash-architecture.md) +- [9.3 TiFlash 的使用](tiflash-in-action.md) + From 91b034ed5cb95534993bc592244b551affba57eb Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Fri, 3 Apr 2020 08:04:53 +0800 Subject: [PATCH 26/46] Update tispark-intro.md --- session1/chapter11/tispark-intro.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/session1/chapter11/tispark-intro.md b/session1/chapter11/tispark-intro.md index e69de29bb2..ebd7a2f6bf 100644 --- a/session1/chapter11/tispark-intro.md +++ b/session1/chapter11/tispark-intro.md @@ -0,0 +1,11 @@ +## 第11章 TiSpark 简介与实战 + +TiSpark 是 PingCAP 为解决用户复杂 OLAP 需求而推出的产品。它能够让Spark SQL 直接运行在分布式存储引擎 TiKV 上，和 TiDB 一起为用户提供了一站式解决 HTAP (Hybrid Transactional/Analytical Processing) 解决方案。 +在这部分内容中，首先向大家介绍TiSpark的总体架构和基本原理，然后介绍 TiSpark 的部署和使用方法，接下来向大家介绍 TiSpark如何运行在PingCAP为分析型场景而研发的列式存储引擎 TiFlash 的基本知识，最后介绍 TiSpark融合到已有大数据生态体系的方法。 + +## 目录 + +- [11.1 TiSpark 架构与原理](tispark-architecture.md) +- [11.2 TiSpark 的使用](tispark-in-action.md) +- [11.3 TiSpark on TiFlash](tispark-on-tiflash.md) +- [11.4 TiSpark 结合大数据体系](tispark-on-bigdata.md) From 822cf5e05b85a0fffceca55d7b964725c2a154c6 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Fri, 3 Apr 2020 08:05:44 +0800 Subject: [PATCH 27/46] Update tispark-intro.md --- session1/chapter11/tispark-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter11/tispark-intro.md b/session1/chapter11/tispark-intro.md index ebd7a2f6bf..e2154ec800 100644 --- a/session1/chapter11/tispark-intro.md +++ b/session1/chapter11/tispark-intro.md @@ -1,7 +1,7 @@ ## 第11章 TiSpark 简介与实战 TiSpark 是 PingCAP 为解决用户复杂 OLAP 需求而推出的产品。它能够让Spark SQL 直接运行在分布式存储引擎 TiKV 上，和 TiDB 一起为用户提供了一站式解决 HTAP (Hybrid Transactional/Analytical Processing) 解决方案。 -在这部分内容中，首先向大家介绍TiSpark的总体架构和基本原理，然后介绍 TiSpark 的部署和使用方法，接下来向大家介绍 TiSpark如何运行在PingCAP为分析型场景而研发的列式存储引擎 TiFlash 的基本知识，最后介绍 TiSpark融合到已有大数据生态体系的方法。 +在这部分内容中，首先向大家介绍TiSpark的总体架构和基本原理，然后介绍 TiSpark 的部署和使用方法，接下来向大家介绍 TiSpark如何运行在PingCAP为复杂分析型场景而研发的列式存储引擎 TiFlash 的基本知识，最后介绍 TiSpark融合到已有大数据生态体系的方法。 ## 目录 From b832d78c01a8f7365af020dc6232c7144b473cd6 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Sun, 5 Apr 2020 19:26:23 +0800 Subject: [PATCH 28/46] Update scheduling-overview.md --- session1/chapter4/scheduling-overview.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/session1/chapter4/scheduling-overview.md b/session1/chapter4/scheduling-overview.md index 57bf4781bc..53729a71d2 100644 --- a/session1/chapter4/scheduling-overview.md +++ b/session1/chapter4/scheduling-overview.md @@ -2,7 +2,7 @@ 任何一个复杂的系统，用户感知到的都只是冰山一角，数据库也不例外。前两篇文章介绍了 TiKV、TiDB 的基本概念以及一些核心功能的实现原理，这两个组件一个负责 KV 存储，一个负责 SQL 引擎，都是大家看得见的东西。在这两个组件的后面，还有一个叫做 PD（Placement Driver）的组件，虽然不直接和业务接触，但是这个组件是整个集群的核心，负责全局元信息的存储以及 TiKV 集群负载均衡调度。 ## 4.1 调度概述 -本节将介绍一下这个神秘的模块。这部分比较复杂，很多东西大家平时不会想到，也很少在其他文章中见到类似东西的描述。我们还是按照前两节的思路，先讲我们需要什么样的功能，再讲我们如何实现，大家带着需求去看实现，会更容易的理解我们做这些设计时背后的考量。 +本章介绍一下这个神秘的模块。这部分比较复杂，很多东西大家平时不会想到，也很少在其他文章中见到类似东西的描述。我们还是按照前两篇的思路，先讲我们需要什么样的功能，再讲我们如何实现，大家带着需求去看实现，会更容易的理解我们做这些设计时背后的考量。 ### 4.1.1 为什么要进行调度 在前面介绍 TiKV 时提到，TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为单位进行复制和管理，每个 Region 会有多个 Replica（副本），这些 Replica 会分布在不同的 TiKV 节点上，其中 Leader 负责读/写，Follower 负责同步 Leader 发来的 raft log。了解了这些信息后，请思考下面这些问题： @@ -15,7 +15,7 @@ * 并不是所有的 Region 都被频繁的访问，可能访问热点只在少数几个 Region，这个时候我们需要做什么？ * 集群在做负载均衡的时候，往往需要搬迁数据，这种数据的迁移会不会占用大量的网络带宽、磁盘 IO 以及 CPU？进而影响在线服务？ -这些问题单独拿出可能都能找到简单的解决方案，但是混杂在一起，就不太好解决。有的问题貌似只需要考虑单个 Raft Group 内部的情况，比如根据副本数量是否足够多来决定是否需要添加副本。但是实际上这个副本添加在哪里，是需要考虑全局的信息。整个系统也是在动态变化的，Region 分裂、节点加入、节点失效、访问热点变化等情况会不断发生，整个调度系统也需要在动态中不断向最优状态前进。如果没有一个掌握全局信息，可以对全局进行调度，并且可以配置的组件，就很难满足这些需求。因此我们需要一个中心节点，来对系统的整体状况进行把控和调整，所以有了 PD 这个模块。 +这些问题单独拿出可能都能找到简单的解决方案，但是混杂在一起，就不太好解决。有的问题貌似只需要考虑单个 Raft Group 内部的情况，比如根据副本数量是否充足来决定是否需要添加副本，但是实际上这个副本添加在哪里，是需要考虑全局信息的。同时整个系统也是在动态变化，Region 分裂、节点加入、节点失效、访问热点变化等情况会不断发生，整个调度系统也需要在动态中不断向最优状态前进，如果没有一个掌握全局信息，可以对全局进行调度，并且可以配置的组件，就很难满足这些需求。因此我们需要一个中心节点，来对系统的整体状况进行把控和调整，所以有了 PD 这个模块。 ### 4.1.2 调度的需求 上面罗列了一大堆问题，我们先进行分类和整理。总体来看，问题有两大类： @@ -31,9 +31,9 @@ * 维持整个集群的 Leader 分布均匀 * 维持每个节点的存储容量均匀 -* 维持访问热点分布均匀，尽量不要集中在某个或某几个节点上 +* 维持访问热点分布均匀 * 控制 Balance 的速度，避免影响在线服务 -* 管理节点状态，包括手动上线/下线节点，以及自动下线失效节点 +* 管理节点状态，包括手动上线/下线节点 满足第一类需求后，整个系统将具备多副本容错、动态扩容/缩容、容忍节点掉线以及自动错误恢复的功能。满足第二类需求后，可以使得系统整体的负载更加均匀，并且可以方便的管理。 @@ -123,4 +123,4 @@ Raft 协议要求读取和写入都通过 Leader 进行，所以计算的负载 PD 不断的通过 Store 或者 Leader 的心跳包收集信息，获得整个集群的详细数据，并且根据这些信息以及调度策略生成调度操作序列。每次收到 Region Leader 发来的心跳包时，PD 都会检查这个 Region 是否有待进行的操作，然后通过心跳包的回复消息，将需要进行的操作返回给 Region Leader，并在后面的心跳包中监测执行结果。注意这里的操作只是给 Region Leader 的建议，并不保证一定能得到执行，具体是否会执行以及什么时候执行，由 Region Leader 自己根据当前自身状态来定。 ### 4.1.7 总结 -本篇文章讲的东西，大家可能平时很少会在其他文章中看到，每一个设计都有背后的考量，希望大家能了解到一个分布式存储系统在做调度的时候，需要考虑哪些东西，如何将策略、实现进行解耦，更灵活的支持策略的扩展。 \ No newline at end of file +本篇文章讲的东西，大家可能平时很少会在其他文章中看到，每一个设计都有背后的考量，希望大家能了解到一个分布式存储系统在做调度的时候，需要考虑哪些东西，如何将策略、实现进行解耦，更灵活的支持策略的扩展。 From 0d6be980d65a1eb29536a4dc65d00676f1e1bf15 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Sun, 5 Apr 2020 19:36:10 +0800 Subject: [PATCH 29/46] Update scheduling-overview.md --- session1/chapter4/scheduling-overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/session1/chapter4/scheduling-overview.md b/session1/chapter4/scheduling-overview.md index 53729a71d2..35f2cf639f 100644 --- a/session1/chapter4/scheduling-overview.md +++ b/session1/chapter4/scheduling-overview.md @@ -5,7 +5,7 @@ 本章介绍一下这个神秘的模块。这部分比较复杂，很多东西大家平时不会想到，也很少在其他文章中见到类似东西的描述。我们还是按照前两篇的思路，先讲我们需要什么样的功能，再讲我们如何实现，大家带着需求去看实现，会更容易的理解我们做这些设计时背后的考量。 ### 4.1.1 为什么要进行调度 -在前面介绍 TiKV 时提到，TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为单位进行复制和管理，每个 Region 会有多个 Replica（副本），这些 Replica 会分布在不同的 TiKV 节点上，其中 Leader 负责读/写，Follower 负责同步 Leader 发来的 raft log。了解了这些信息后，请思考下面这些问题： +TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为单位进行复制和管理，每个 Region 会有多个 Replica（副本），这些 Replica 会分布在不同的 TiKV 节点上，其中 Leader 负责读/写，Follower 负责同步 Leader 发来的 raft log。了解了这些信息后，请思考下面这些问题： * 如何保证同一个 Region 的多个 Replica 分布在不同的节点上？更进一步，如果在一台机器上启动多个 TiKV 实例，会有什么问题？ * TiKV 集群进行跨机房部署用于容灾的时候，如何保证一个机房掉线，不会丢失 Raft Group 的多个 Replica？ @@ -30,7 +30,7 @@ **作为一个良好的分布式系统，需要优化的地方，包括：** * 维持整个集群的 Leader 分布均匀 -* 维持每个节点的存储容量均匀 +* 维持每个节点的储存容量均匀 * 维持访问热点分布均匀 * 控制 Balance 的速度，避免影响在线服务 * 管理节点状态，包括手动上线/下线节点 From b6bfacde6ddd7bf9a846f4f6bb5aed292d42c5c0 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Sun, 5 Apr 2020 19:39:00 +0800 Subject: [PATCH 30/46] Update scheduling-overview.md --- session1/chapter4/scheduling-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter4/scheduling-overview.md b/session1/chapter4/scheduling-overview.md index 35f2cf639f..c75d1e0cc5 100644 --- a/session1/chapter4/scheduling-overview.md +++ b/session1/chapter4/scheduling-overview.md @@ -32,7 +32,7 @@ TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为 * 维持整个集群的 Leader 分布均匀 * 维持每个节点的储存容量均匀 * 维持访问热点分布均匀 -* 控制 Balance 的速度，避免影响在线服务 +* 控制负载均衡的速度，避免影响在线服务 * 管理节点状态，包括手动上线/下线节点 满足第一类需求后，整个系统将具备多副本容错、动态扩容/缩容、容忍节点掉线以及自动错误恢复的功能。满足第二类需求后，可以使得系统整体的负载更加均匀，并且可以方便的管理。 From 736f8a7e6cdc7b05476830fe101cb3d67398fcf3 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Sun, 5 Apr 2020 22:37:36 +0800 Subject: [PATCH 31/46] Update session1/chapter9/tiflash-intro.md Co-Authored-By: Shirly --- session1/chapter9/tiflash-intro.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/session1/chapter9/tiflash-intro.md b/session1/chapter9/tiflash-intro.md index 5ea5d3400c..6992794c3a 100644 --- a/session1/chapter9/tiflash-intro.md +++ b/session1/chapter9/tiflash-intro.md @@ -4,7 +4,8 @@ 作为存储和处理数据最重要的基础软件——数据库系统，一般可以按照负载类型分成 OLTP 型数据库和 OLAP 数据库。在一个企业中，这两种类型的数据库通常是并存的，分别支撑这两种负载类型的应用系统。目前，很多企业的这两种类型的系统之间是通过较为复杂的ETL过程“打通的”，数据在时效性上具有比较大的T+N延时，这越来越难以满足企业在数据处理和分析方面对时效性的要求。 -近几年，HTAP 是比较热的一个概念，它是最有希望解决目前问题的方法。从字面意义上看， HTAP 是混合 OLTP 和 OLAP 业务，能够同时处理这种两种负载的系统。2014年 Garnter 公司给出了严格的定义：混合事务/分析处理( HTAP )是一种新兴的应用体系结构，它打破了事务处理和分析之间的 “墙” 。它支持更多的信息和 “实时业务” 的决策。 +近几年，HTAP 是比较热的一个概念，它是最有希望解决目前问题的方法。顾名思义， HTAP 是混合 OLTP 和 OLAP 业务，具备同时解决这种两种问题能力的系统。2014 年 Garnter 公司给出了严格的定义：混合事务/分析处理 (HTAP) 是一种新兴的应用体系结构，它打破了事务处理和分析之间的 “墙” 。它支持更多的”信息分析“和 “实时业务” 的决策。 + TiDB 是一个具有优异交易处理能力的分布式 NewSQL 产品，同时也具备了良好的分析能力，又是一款优秀的 HTAP 数据数据库产品。在这部分内容中，首先向大家介绍 TiDB HTAP 的主要特点，然后介绍其实现 HTAP 能力的关键技术之一的 TiFlash 列式存储引擎的架构和基本原理，最后向大家介绍 TiFlash 如何使用。 @@ -14,4 +15,3 @@ TiDB 是一个具有优异交易处理能力的分布式 NewSQL 产品，同时 - [9.1 TiDB HTAP 的特点](tidb-htap.md) - [9.2 TiFlash 架构与原理](tiflash-architecture.md) - [9.3 TiFlash 的使用](tiflash-in-action.md) - From 9f45e42b3c72c7b8570a7eac9c5cd4b77baab67f Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Sun, 5 Apr 2020 22:37:55 +0800 Subject: [PATCH 32/46] Update session1/chapter9/tiflash-intro.md Co-Authored-By: Shirly --- session1/chapter9/tiflash-intro.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/session1/chapter9/tiflash-intro.md b/session1/chapter9/tiflash-intro.md index 6992794c3a..7e028fc956 100644 --- a/session1/chapter9/tiflash-intro.md +++ b/session1/chapter9/tiflash-intro.md @@ -2,7 +2,8 @@ 近年来，随着企业数字化转型的不断深入和发展，数据逐渐成为企业最重要的资产。对于每一个企业来说，都需要关注数据从产生、存储、分析到利用，并发挥其巨大价值的整个过程。此外，随着企业之间竞争的不断加剧，对数据的产生到发挥其价值的时间延迟要求越来越短。 -作为存储和处理数据最重要的基础软件——数据库系统，一般可以按照负载类型分成 OLTP 型数据库和 OLAP 数据库。在一个企业中，这两种类型的数据库通常是并存的，分别支撑这两种负载类型的应用系统。目前，很多企业的这两种类型的系统之间是通过较为复杂的ETL过程“打通的”，数据在时效性上具有比较大的T+N延时，这越来越难以满足企业在数据处理和分析方面对时效性的要求。 +作为存储和处理数据最重要的基础软件——数据库系统，一般可以按照负载类型分成 OLTP 型数据库和 OLAP 数据库。在一个企业中，这两种类型的数据库通常是并存的，分别支撑这两种负载类型的应用系统。目前，很多企业的这两种类型的系统之间是通过较为复杂的 ETL 过程“打通的”，数据在时效性上具有比较大的 T+N 延时，这越来越难以满足企业在数据处理和分析方面对时效性的要求。 + 近几年，HTAP 是比较热的一个概念，它是最有希望解决目前问题的方法。顾名思义， HTAP 是混合 OLTP 和 OLAP 业务，具备同时解决这种两种问题能力的系统。2014 年 Garnter 公司给出了严格的定义：混合事务/分析处理 (HTAP) 是一种新兴的应用体系结构，它打破了事务处理和分析之间的 “墙” 。它支持更多的”信息分析“和 “实时业务” 的决策。 From e729381838bda8f4482ace9c44c28ee4737333a8 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Sun, 5 Apr 2020 22:38:21 +0800 Subject: [PATCH 33/46] Update session1/chapter4/scheduling-overview.md Co-Authored-By: Shirly --- session1/chapter4/scheduling-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter4/scheduling-overview.md b/session1/chapter4/scheduling-overview.md index c75d1e0cc5..1e939e0e94 100644 --- a/session1/chapter4/scheduling-overview.md +++ b/session1/chapter4/scheduling-overview.md @@ -35,7 +35,7 @@ TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为 * 控制负载均衡的速度，避免影响在线服务 * 管理节点状态，包括手动上线/下线节点 -满足第一类需求后，整个系统将具备多副本容错、动态扩容/缩容、容忍节点掉线以及自动错误恢复的功能。满足第二类需求后，可以使得系统整体的负载更加均匀，并且可以方便的管理。 +满足第一类需求后，整个系统将具备强大的容灾功能。满足第二类需求后，可以使得系统整体的负载更加均匀，管理更加容易方便。 为了满足这些需求，首先我们需要收集足够的信息，比如每个节点的状态、每个 Raft Group 的信息、业务访问操作的统计等；其次需要设置一些策略，PD 根据这些信息以及调度的策略，制定出尽量满足前面所述需求的调度计划；最后需要一些基本的操作，来完成调度计划。 From ab6b09e797243843d93579c0c04e7ee3334283c4 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Sun, 5 Apr 2020 22:39:00 +0800 Subject: [PATCH 34/46] Update session1/chapter11/tispark-intro.md Co-Authored-By: Shirly --- session1/chapter11/tispark-intro.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/session1/chapter11/tispark-intro.md b/session1/chapter11/tispark-intro.md index e2154ec800..ed713f0fff 100644 --- a/session1/chapter11/tispark-intro.md +++ b/session1/chapter11/tispark-intro.md @@ -1,7 +1,8 @@ ## 第11章 TiSpark 简介与实战 TiSpark 是 PingCAP 为解决用户复杂 OLAP 需求而推出的产品。它能够让Spark SQL 直接运行在分布式存储引擎 TiKV 上，和 TiDB 一起为用户提供了一站式解决 HTAP (Hybrid Transactional/Analytical Processing) 解决方案。 -在这部分内容中，首先向大家介绍TiSpark的总体架构和基本原理，然后介绍 TiSpark 的部署和使用方法，接下来向大家介绍 TiSpark如何运行在PingCAP为复杂分析型场景而研发的列式存储引擎 TiFlash 的基本知识，最后介绍 TiSpark融合到已有大数据生态体系的方法。 +在这部分内容中，首先向大家介绍 TiSpark 的总体架构和基本原理，然后介绍 TiSpark 的部署和使用方法，接下来向大家介绍 TiSpark 如何运行在 PingCAP 为复杂分析型场景而研发的列式存储引擎 TiFlash 的基本知识，最后介绍 TiSpark 融合到已有大数据生态体系的方法。 + ## 目录 From 14b4146ccfd373ac1f07c1fb906081ee80eaeded Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Sun, 5 Apr 2020 22:39:11 +0800 Subject: [PATCH 35/46] Update session1/chapter11/tispark-intro.md Co-Authored-By: Shirly --- session1/chapter11/tispark-intro.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/session1/chapter11/tispark-intro.md b/session1/chapter11/tispark-intro.md index ed713f0fff..0e5a4ad44e 100644 --- a/session1/chapter11/tispark-intro.md +++ b/session1/chapter11/tispark-intro.md @@ -1,6 +1,7 @@ ## 第11章 TiSpark 简介与实战 -TiSpark 是 PingCAP 为解决用户复杂 OLAP 需求而推出的产品。它能够让Spark SQL 直接运行在分布式存储引擎 TiKV 上，和 TiDB 一起为用户提供了一站式解决 HTAP (Hybrid Transactional/Analytical Processing) 解决方案。 +TiSpark 是 PingCAP 为解决用户复杂 OLAP 需求而推出的产品。它能够让 Spark SQL 直接运行在分布式存储引擎 TiKV 上，和 TiDB 一起为用户提供了一站式解决 HTAP (Hybrid Transactional/Analytical Processing) 解决方案。 + 在这部分内容中，首先向大家介绍 TiSpark 的总体架构和基本原理，然后介绍 TiSpark 的部署和使用方法，接下来向大家介绍 TiSpark 如何运行在 PingCAP 为复杂分析型场景而研发的列式存储引擎 TiFlash 的基本知识，最后介绍 TiSpark 融合到已有大数据生态体系的方法。 From 943dcad8cd35f7bfd59accbdf80562cc99b619d3 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 7 Apr 2020 08:18:33 +0800 Subject: [PATCH 36/46] Update tispark-architecture.md --- session1/chapter11/tispark-architecture.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/session1/chapter11/tispark-architecture.md b/session1/chapter11/tispark-architecture.md index 0d3cabfca4..21d1721f76 100644 --- a/session1/chapter11/tispark-architecture.md +++ b/session1/chapter11/tispark-architecture.md @@ -23,16 +23,16 @@ TiSpark 是将 Spark SQL 直接运行在分布式存储引擎 TiKV 上的 OLAP * 将 TiKV 数据包解码并转化为为 Spark SQL 的行格式 ### 11.1.2 富 TiKV Java Client -如上架构所示 TiSpark 需要从 TiKV 中获取表结构信息和底层 KV Pair 信息，那么 TiSpark 如何与 TiKV 通信获取这些信息呢？ 这里就需要 TiKV Java Client ，通过 gRPC 与 TiKV Server 通信调用 TiKV API 。 +如上架构所示， TiSpark 需要从 TiKV 中获取表结构信息和底层 KV Pair 信息，那么 TiSpark 如何与 TiKV 通信获取这些信息呢？ 这里就需要 TiKV Java Client ，通过 gRPC 与 TiKV Server 通信调用 TiKV API 。 * 解析 TiKV Table Schema 将 TiKV 中的 Schema 信息转化为 Spark SQL 认识的 Schema * 解析 TiKV 的类型系统 - * 从 TiKV 中获取的数据是 KV Pair 需要，编码解码模块负责将 KV Pair 转化为 Spark SQL 可以使用的数据。这里的编解码逻辑和 TiDB 编解码逻辑一致。 - * 协处理器支持，可以谓词，索引，键值域处理计算下推到 TiKV 侧，减少数据传输过程更能利用 TiKV 的分布式计算能力。在调用协处理的时候也依赖上面类型系统和编码系统，用于构造协处理器调用参数。 - * 为了更加精确选择查询计划，提高 SQL 运行效率， TiSpark 中 Java TiKV Client 利用了 TiDB 的统计信息实现了更合理的基于代价的估算 + * 从 TiKV 中获取的数据是 KV Pair ，需要编码和解码模块负责将 KV Pair 转化为 Spark SQL 可以使用的数据。这里的编解码逻辑和 TiDB 编解码逻辑一致。 + * 协处理器支持，可以把谓词，索引，键值域处理计算下推到 TiKV 侧，减少数据传输过程，更能利用 TiKV 的分布式计算能力。在调用协处理的时候也依赖上面类型系统和编码系统，用于构造协处理器调用参数。 + * 为了更加精确选择查询计划，提高 SQL 运行效率， TiSpark 中 Java TiKV Client 利用了 TiDB 的统计信息实现了更合理的基于代价的估算。 ### 11.1.3 打通 TiKV 和 TiSpark -通过富 Java TiKV Client 可以完成 TiSpark 与 TiKV 通信，获取 TiKV 的相关数据，如何将 TiKV 的数据注入到 Spark 中完成 Spark 程序分布式计算呢？ 答案是通过修改 Spark Plan 可以完成。Spark 内置了扩展性接口，通过扩展 SparkSessionExtensions 类 Spark 可以实现用户自定义 SQL Plan，语法支持以及元数据解析等。具体可以参见下图 Spark 官网 API 说明。 +通过富 Java TiKV Client 可以完成 TiSpark 与 TiKV 通信，获取 TiKV 的相关数据，如何将 TiKV 的数据注入到 Spark 中完成 Spark 程序分布式计算呢？ 答案是通过修改 Spark Plan 可以完成。Spark 内置了扩展性接口，通过扩展 SparkSessionExtensions 类， Spark 可以实现用户自定义 SQL Plan 、语法支持以及元数据解析等。具体可以参见下图 Spark 官网 API 说明。 ![图片](/res/session1/chapter11/spark-extension.png) From d83d390e1bd2de1c76e338388346c8dc7ad2987a Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 7 Apr 2020 08:41:17 +0800 Subject: [PATCH 37/46] Update tispark-architecture.md --- session1/chapter11/tispark-architecture.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/session1/chapter11/tispark-architecture.md b/session1/chapter11/tispark-architecture.md index 21d1721f76..e723e54d7f 100644 --- a/session1/chapter11/tispark-architecture.md +++ b/session1/chapter11/tispark-architecture.md @@ -44,14 +44,14 @@ spark.sql.extensions org.apache.spark.sql.TiExtensions ![图片](/res/session1/chapter11/tiextension.png) -原生 Spark SQL 执行计划如下图左边所示，一个 Spark SQL 开始运行，通过 Catalyst 解析器被解析为逻辑执行计划，在优化器中生成物理执行计划，最后通过 DataSource 的 API 获取数据。 TiSpark 修改 Spark Plan 之后 SQL 执行过程如下图右边所示。将 SQL 优化器和物理执行计划改写为与 TiKV 相关的交互，在物理执行计划中从 TiKV 获取表结构、数据和索引等信息。改写之后 Spark 看到的接口不变，但是底层实现变成了从 TiKV 交互，既保证了与原来 Spark 程序的兼容又完成 TiKV 数据注入。 +原生 Spark SQL 执行计划如下图左边所示，一个 Spark SQL 开始运行，通过 Catalyst 解析器被解析为逻辑执行计划，在优化器中生成物理执行计划，最后通过 DataSource 的 API 获取数据。 TiSpark 修改 Spark Plan 之后的 SQL 执行过程如下图右边所示。将 SQL 优化器和物理执行计划改写为与 TiKV 相关的交互，在物理执行计划中从 TiKV 获取表结构、数据和索引等信息。改写之后 Spark 看到的接口不变，但是底层实现变成了与 TiKV 交互，既保证了与原来 Spark 程序的兼容又完成 TiKV 数据注入。 ![图片](/res/session1/chapter11/process.png) ### 11.1.4 聚簇索引 上面 Spark SQL 架构比较抽象，具体来看一个例子： -Spark SQL 运行如下 SQL ，其中 student 表是 TiDB 中的表，在 studentID 列上有聚簇索引， 在 school 列上的非聚簇索引。聚簇索引会将索引和数据放在一起。 +Spark SQL 运行如下 SQL ，其中 student 表是 TiDB 中的表，在 studentID 列上有聚簇索引， 在 school 列上有非聚簇索引。聚簇索引会将索引和数据放在一起。 SELECT class, avg(score) FROM student @@ -61,7 +61,7 @@ GROUP BY class ; ![图片](/res/session1/chapter11/filter.png) -在上图中 studentID 是一个聚簇索引， TiKV Region 中会包含聚簇索引的范围，比如上图中 Region 2 的 studentId 范围是 [5000 - 10000) ， Region 3 的 studentID 范围是 [10000 - 15000) 。在 SQL 运行时聚簇索引会转化为对 TiKV 的范围查询，现在需求查找数据范围在 8000 到 10100 ，TiSpark 会将对于的请求发送到 Region 2 和 Region 3 做范围查找。TiSpark 会在 Spark Executor 端将 TiKV 支持的谓词发送给 TiKV 协处理器计算，并将 TiKV 计算之后的结果进行汇总和再计算。 对于 TiKV 不支持的谓词部分会留在 Spark 中计算得到最终 SQL 运行结果。 +在上图中 studentID 是一个聚簇索引， TiKV Region 中会包含聚簇索引的范围，比如上图中 Region 2 的 studentId 范围是 [5000 - 10000) ， Region 3 的 studentID 范围是 [10000 - 15000) 。在 SQL 运行时聚簇索引会转化为对 TiKV 的范围查询，现在要查找范围在 8000 到 10100 的数据 ，TiSpark 会将对应的请求发送到 Region 2 和 Region 3 做范围查找。TiSpark 会在 Spark Executor 端将 TiKV 支持的谓词发送给 TiKV 协处理器计算，并将 TiKV 计算之后的结果进行汇总和再计算。 对于 TiKV 不支持的谓词部分会留在 Spark 中进行计算，从而得到最终 SQL 运行结果。 ### 11.1.5 非聚簇索引处理 非聚簇索引被编码为键值对，键是按照索引列顺序排序的数据，值是指向表主数据的 Row ID 。 From 62443d395765018f9fad42dfe17523014322d08f Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 7 Apr 2020 08:49:14 +0800 Subject: [PATCH 38/46] Update tispark-architecture.md --- session1/chapter11/tispark-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter11/tispark-architecture.md b/session1/chapter11/tispark-architecture.md index e723e54d7f..751865301f 100644 --- a/session1/chapter11/tispark-architecture.md +++ b/session1/chapter11/tispark-architecture.md @@ -71,7 +71,7 @@ GROUP BY class ; * 首先根据谓词对索引表进行扫表，逻辑类同之前对聚簇索引的读取。 * 根据 Row ID 和所属 Region 分发整理数据 * 在每个 Spark Executor 排序这些 Row ID 并尽可能整合成更大的值域段 -* 针对所查询的表进行编码并并发发送请求 +* 针对所查询的表进行编码，同时并发发送请求 例如下图中扫描 school 的非聚簇索引表数据，得到 1,2,3,4,5,7,8,10,88 的 Row ID ，在 Spark Executor 端对这些 Row ID 排序，再根据 Row ID 对 student 主表进行范围扫描，再将 TiKV 主表返回数据在 Spark 中再计算得到最终结果。 From ed296c00dc19c744bdbe7d4215f2acb438377fb8 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 7 Apr 2020 08:55:51 +0800 Subject: [PATCH 39/46] Update tispark-architecture.md --- session1/chapter11/tispark-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter11/tispark-architecture.md b/session1/chapter11/tispark-architecture.md index 751865301f..06581527d7 100644 --- a/session1/chapter11/tispark-architecture.md +++ b/session1/chapter11/tispark-architecture.md @@ -83,7 +83,7 @@ TiStrategy 负责改写 TiSpark 的物理执行计划，假设 Spark SQL 中包 ![图片](/res/session1/chapter11/agg.png) ### 11.1.7 分布式大数据写入 -最初 TiSpark 只能通过 TiDB JDBC 的方式将数据写入到 TiDB ，这存在可扩展性问题，将 TiSpark 直接写入 TiKV 则可以解决此问题。在 Spark 中数据一般是以 DataFrame 的形式存在， TiSpark 写入过程中可以将 DataFrame 的数据转化为 TiKV 认识的格式，并通过 TiKV Java Client 将数据写入 TiKV。 +最初 TiSpark 只能通过 TiDB JDBC 的方式将数据写入到 TiDB ，这存在可扩展性问题。通过 TiSpark 直接写入 TiKV 则可以解决此问题。在 Spark 中数据一般是以 DataFrame 的形式存在， TiSpark 写入过程中可以将 DataFrame 的数据转化为 TiKV 认识的格式，并通过 TiKV Java Client 将数据写入 TiKV。 * 根据 DataFrame 中数据进行 Region 预切分和分配 * TiKV 数据写入需要支持分布式事务， TiKV 采用 Percolator 协议进行事务操作，操作过程如下： From 902ba90b0a726a7c8c8a4f789e3803bc89bad2ca Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 7 Apr 2020 14:51:18 +0800 Subject: [PATCH 40/46] Update session1/chapter11/tispark-architecture.md Co-Authored-By: Shirly --- session1/chapter11/tispark-architecture.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/session1/chapter11/tispark-architecture.md b/session1/chapter11/tispark-architecture.md index 06581527d7..ebf37a11a7 100644 --- a/session1/chapter11/tispark-architecture.md +++ b/session1/chapter11/tispark-architecture.md @@ -27,7 +27,8 @@ TiSpark 是将 Spark SQL 直接运行在分布式存储引擎 TiKV 上的 OLAP * 解析 TiKV Table Schema 将 TiKV 中的 Schema 信息转化为 Spark SQL 认识的 Schema * 解析 TiKV 的类型系统 - * 从 TiKV 中获取的数据是 KV Pair ，需要编码和解码模块负责将 KV Pair 转化为 Spark SQL 可以使用的数据。这里的编解码逻辑和 TiDB 编解码逻辑一致。 + * 从 TiKV 中获取的数据是 Key-Value Pair ，需要编码和解码模块负责将 Key-Value Pair 转化为 Spark SQL 可以使用的数据。这里的编解码逻辑和 TiDB 编解码逻辑一致。 + * 协处理器支持，可以把谓词，索引，键值域处理计算下推到 TiKV 侧，减少数据传输过程，更能利用 TiKV 的分布式计算能力。在调用协处理的时候也依赖上面类型系统和编码系统，用于构造协处理器调用参数。 * 为了更加精确选择查询计划，提高 SQL 运行效率， TiSpark 中 Java TiKV Client 利用了 TiDB 的统计信息实现了更合理的基于代价的估算。 @@ -96,4 +97,3 @@ TiStrategy 负责改写 TiSpark 的物理执行计划，假设 Spark SQL 中包 TiSpark 实现了富 TiKV Java Client ，并通过 Spark 内置扩展接口改写 Spark Plan ，将 TiKV 的表结构和数据集成到 Spark 中。 非常巧妙的将 TiKV 体系和现有大数据体系融合起来。再通过分析 TiSpark 对聚簇和非聚簇索引的处理，以及协处理器在其中的作用，加深了对 TiSpark 与 TiKV 交互的理解。 最后分析 TiSpark 分布式写入 TiKV ，完成了 TiSpark 对 TiKV 读和写的总体理解。 - From 75293feed336eaaec588eee211c7401c5736321a Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 7 Apr 2020 14:57:10 +0800 Subject: [PATCH 41/46] Update tispark-intro.md --- session1/chapter11/tispark-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter11/tispark-intro.md b/session1/chapter11/tispark-intro.md index 0e5a4ad44e..b9e1e31a66 100644 --- a/session1/chapter11/tispark-intro.md +++ b/session1/chapter11/tispark-intro.md @@ -2,7 +2,7 @@ TiSpark 是 PingCAP 为解决用户复杂 OLAP 需求而推出的产品。它能够让 Spark SQL 直接运行在分布式存储引擎 TiKV 上，和 TiDB 一起为用户提供了一站式解决 HTAP (Hybrid Transactional/Analytical Processing) 解决方案。 -在这部分内容中，首先向大家介绍 TiSpark 的总体架构和基本原理，然后介绍 TiSpark 的部署和使用方法，接下来向大家介绍 TiSpark 如何运行在 PingCAP 为复杂分析型场景而研发的列式存储引擎 TiFlash 的基本知识，最后介绍 TiSpark 融合到已有大数据生态体系的方法。 +在这部分内容中，首先向大家介绍 TiSpark 的总体架构和基本原理，然后介绍 TiSpark 的部署和使用方法，接下来向大家介绍 TiSpark 如何运行在列式存储引擎 TiFlash 的基本知识，最后介绍 TiSpark 融合到已有大数据生态体系的方法。 ## 目录 From 59c5d35e64b3eb35d28143608fe70171bd9ec26e Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 7 Apr 2020 15:03:54 +0800 Subject: [PATCH 42/46] Update tispark-intro.md --- session1/chapter11/tispark-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter11/tispark-intro.md b/session1/chapter11/tispark-intro.md index b9e1e31a66..0e5a4ad44e 100644 --- a/session1/chapter11/tispark-intro.md +++ b/session1/chapter11/tispark-intro.md @@ -2,7 +2,7 @@ TiSpark 是 PingCAP 为解决用户复杂 OLAP 需求而推出的产品。它能够让 Spark SQL 直接运行在分布式存储引擎 TiKV 上，和 TiDB 一起为用户提供了一站式解决 HTAP (Hybrid Transactional/Analytical Processing) 解决方案。 -在这部分内容中，首先向大家介绍 TiSpark 的总体架构和基本原理，然后介绍 TiSpark 的部署和使用方法，接下来向大家介绍 TiSpark 如何运行在列式存储引擎 TiFlash 的基本知识，最后介绍 TiSpark 融合到已有大数据生态体系的方法。 +在这部分内容中，首先向大家介绍 TiSpark 的总体架构和基本原理，然后介绍 TiSpark 的部署和使用方法，接下来向大家介绍 TiSpark 如何运行在 PingCAP 为复杂分析型场景而研发的列式存储引擎 TiFlash 的基本知识，最后介绍 TiSpark 融合到已有大数据生态体系的方法。 ## 目录 From 415330564eed67d5001100ba482a0e9738783cce Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 7 Apr 2020 15:15:50 +0800 Subject: [PATCH 43/46] Update tispark-architecture.md --- session1/chapter11/tispark-architecture.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/session1/chapter11/tispark-architecture.md b/session1/chapter11/tispark-architecture.md index ebf37a11a7..d88f155948 100644 --- a/session1/chapter11/tispark-architecture.md +++ b/session1/chapter11/tispark-architecture.md @@ -8,7 +8,7 @@ TiSpark 是将 Spark SQL 直接运行在分布式存储引擎 TiKV 上的 OLAP ![图片](/res/session1/chapter11/tispark-arch-image.png) -* TiSpark 内置实现 TiKV 和 PD Java Client，让 TiSpark 可以通过 gRPC 与 TiKV 和 PD 通信，从 TiKV / TiFlash 中获取 KV Pair 和表结构用于支持 TiSpark SQL 计算，从 PD 中获取表元数据信息用于支持表结构解析和 TiKV 数据定位。 +* TiSpark 内置实现 TiKV 和 PD Java Client，让 TiSpark 可以通过 gRPC 与 TiKV 和 PD 通信，从 TiKV / TiFlash 中获取 Key-Value Pair 和表结构用于支持 TiSpark SQL 计算，从 PD 中获取表元数据信息用于支持表结构解析和 TiKV 数据定位。 * TiSpark 在分布式写入数据时需要通过 TiDB 来进行锁表和 Region 预切分操作，保证数据写入正确性和高效性 * TiSpark Driver 侧： * 通过 PD CLient 从 PD 中获取 TiDB metadata 信息，并将 TiDB 的 metadata 信息转化 Spark 的支持的 metadata 信息。转化成功之后 TiSpark 可以看到 TiDB的表。 @@ -23,7 +23,7 @@ TiSpark 是将 Spark SQL 直接运行在分布式存储引擎 TiKV 上的 OLAP * 将 TiKV 数据包解码并转化为为 Spark SQL 的行格式 ### 11.1.2 富 TiKV Java Client -如上架构所示， TiSpark 需要从 TiKV 中获取表结构信息和底层 KV Pair 信息，那么 TiSpark 如何与 TiKV 通信获取这些信息呢？ 这里就需要 TiKV Java Client ，通过 gRPC 与 TiKV Server 通信调用 TiKV API 。 +如上架构所示， TiSpark 需要从 TiKV 中获取表结构信息和底层 Key-Value Pair 信息，那么 TiSpark 如何与 TiKV 通信获取这些信息呢？ 这里就需要 TiKV Java Client ，通过 gRPC 与 TiKV Server 通信调用 TiKV API 。 * 解析 TiKV Table Schema 将 TiKV 中的 Schema 信息转化为 Spark SQL 认识的 Schema * 解析 TiKV 的类型系统 @@ -89,7 +89,7 @@ TiStrategy 负责改写 TiSpark 的物理执行计划，假设 Spark SQL 中包 * 根据 DataFrame 中数据进行 Region 预切分和分配 * TiKV 数据写入需要支持分布式事务， TiKV 采用 Percolator 协议进行事务操作，操作过程如下： * 在 Spark Driver 端开始写数据时申请 TiKV 中主数据预写，对此条数据加锁。 - * 在 Spark Executor 端将 DataFrame 转化为 TiKV 的 KV Pair 格式，并调用 gRPC 进行次数据预写，将 DataFrame 数据存入到 TiKV ， 此过程如果存在写入冲突可以选择报错或者覆盖写入。 + * 在 Spark Executor 端将 DataFrame 转化为 TiKV 的 Key-Value Pair 格式，并调用 gRPC 进行次数据预写，将 DataFrame 数据存入到 TiKV ， 此过程如果存在写入冲突可以选择报错或者覆盖写入。 * 在 Spark Driver 端等待 Spark Executor 预写成功，再将主数据提交。 Percolator 提交成功取决于主数据提交状态。 * 在 Spark Excutor 端提交次数据。到此完成了所有两阶段事务提交。 From 9793032659cda6cde10b239dcc43c7bb90c47409 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 7 Apr 2020 15:24:47 +0800 Subject: [PATCH 44/46] Update tispark-architecture.md --- session1/chapter11/tispark-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter11/tispark-architecture.md b/session1/chapter11/tispark-architecture.md index d88f155948..273f501d5b 100644 --- a/session1/chapter11/tispark-architecture.md +++ b/session1/chapter11/tispark-architecture.md @@ -8,7 +8,7 @@ TiSpark 是将 Spark SQL 直接运行在分布式存储引擎 TiKV 上的 OLAP ![图片](/res/session1/chapter11/tispark-arch-image.png) -* TiSpark 内置实现 TiKV 和 PD Java Client，让 TiSpark 可以通过 gRPC 与 TiKV 和 PD 通信，从 TiKV / TiFlash 中获取 Key-Value Pair 和表结构用于支持 TiSpark SQL 计算，从 PD 中获取表元数据信息用于支持表结构解析和 TiKV 数据定位。 +* TiSpark 内置实现 TiKV 和 PD Java Client，让 TiSpark 可以通过 gRPC 与 TiKV 和 PD 通信，从 TiKV / TiFlash 中获取 KV Pair 和表结构用于支持 TiSpark SQL 计算，从 PD 中获取表元数据信息用于支持表结构解析和 TiKV 数据定位。 * TiSpark 在分布式写入数据时需要通过 TiDB 来进行锁表和 Region 预切分操作，保证数据写入正确性和高效性 * TiSpark Driver 侧： * 通过 PD CLient 从 PD 中获取 TiDB metadata 信息，并将 TiDB 的 metadata 信息转化 Spark 的支持的 metadata 信息。转化成功之后 TiSpark 可以看到 TiDB的表。 From c4bcdc576c8fa2029e5fb4642d9f6e1f3ed69ab4 Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 7 Apr 2020 22:29:29 +0800 Subject: [PATCH 45/46] Update tispark-architecture.md --- session1/chapter11/tispark-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter11/tispark-architecture.md b/session1/chapter11/tispark-architecture.md index 273f501d5b..d88f155948 100644 --- a/session1/chapter11/tispark-architecture.md +++ b/session1/chapter11/tispark-architecture.md @@ -8,7 +8,7 @@ TiSpark 是将 Spark SQL 直接运行在分布式存储引擎 TiKV 上的 OLAP ![图片](/res/session1/chapter11/tispark-arch-image.png) -* TiSpark 内置实现 TiKV 和 PD Java Client，让 TiSpark 可以通过 gRPC 与 TiKV 和 PD 通信，从 TiKV / TiFlash 中获取 KV Pair 和表结构用于支持 TiSpark SQL 计算，从 PD 中获取表元数据信息用于支持表结构解析和 TiKV 数据定位。 +* TiSpark 内置实现 TiKV 和 PD Java Client，让 TiSpark 可以通过 gRPC 与 TiKV 和 PD 通信，从 TiKV / TiFlash 中获取 Key-Value Pair 和表结构用于支持 TiSpark SQL 计算，从 PD 中获取表元数据信息用于支持表结构解析和 TiKV 数据定位。 * TiSpark 在分布式写入数据时需要通过 TiDB 来进行锁表和 Region 预切分操作，保证数据写入正确性和高效性 * TiSpark Driver 侧： * 通过 PD CLient 从 PD 中获取 TiDB metadata 信息，并将 TiDB 的 metadata 信息转化 Spark 的支持的 metadata 信息。转化成功之后 TiSpark 可以看到 TiDB的表。 From dc6fbd0d1a9ec6174e01dac5e3a2cd1be318de3c Mon Sep 17 00:00:00 2001 From: tigeriq188 Date: Tue, 7 Apr 2020 22:34:04 +0800 Subject: [PATCH 46/46] Update tispark-architecture.md --- session1/chapter11/tispark-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/session1/chapter11/tispark-architecture.md b/session1/chapter11/tispark-architecture.md index d88f155948..273f501d5b 100644 --- a/session1/chapter11/tispark-architecture.md +++ b/session1/chapter11/tispark-architecture.md @@ -8,7 +8,7 @@ TiSpark 是将 Spark SQL 直接运行在分布式存储引擎 TiKV 上的 OLAP ![图片](/res/session1/chapter11/tispark-arch-image.png) -* TiSpark 内置实现 TiKV 和 PD Java Client，让 TiSpark 可以通过 gRPC 与 TiKV 和 PD 通信，从 TiKV / TiFlash 中获取 Key-Value Pair 和表结构用于支持 TiSpark SQL 计算，从 PD 中获取表元数据信息用于支持表结构解析和 TiKV 数据定位。 +* TiSpark 内置实现 TiKV 和 PD Java Client，让 TiSpark 可以通过 gRPC 与 TiKV 和 PD 通信，从 TiKV / TiFlash 中获取 KV Pair 和表结构用于支持 TiSpark SQL 计算，从 PD 中获取表元数据信息用于支持表结构解析和 TiKV 数据定位。 * TiSpark 在分布式写入数据时需要通过 TiDB 来进行锁表和 Region 预切分操作，保证数据写入正确性和高效性 * TiSpark Driver 侧： * 通过 PD CLient 从 PD 中获取 TiDB metadata 信息，并将 TiDB 的 metadata 信息转化 Spark 的支持的 metadata 信息。转化成功之后 TiSpark 可以看到 TiDB的表。