update scheduling-overview.md , tiflash-intro.md and tispark-int… (#804)

session1/chapter11/tispark-intro.md

@@ -0,0 +1,13 @@
+## 第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)

session1/chapter4/scheduling-overview.md

@@ -10,7 +10,7 @@ TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为
 * 如何保证同一个 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，进而影响在线服务？
@@ -35,7 +35,7 @@ TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为
 * 控制负载均衡的速度，避免影响在线服务
 * 管理节点状态，包括手动上线/下线节点
 
-满足第一类需求后，整个系统将具备多副本容错、动态扩容/缩容、容忍节点掉线以及自动错误恢复的功能。满足第二类需求后，可以使得整体系统的负载更加均匀、且可以方便的管理。
+满足第一类需求后，整个系统将具备强大的容灾功能。满足第二类需求后，可以使得系统整体的负载更加均匀，管理更加容易方便。
 
 为了满足这些需求，首先我们需要收集足够的信息，比如每个节点的状态、每个 Raft Group 的信息、业务访问操作的统计等；其次需要设置一些策略，PD 根据这些信息以及调度的策略，制定出尽量满足前面所述需求的调度计划；最后需要一些基本的操作，来完成调度计划。
 

session1/chapter9/tiflash-intro.md

@@ -0,0 +1,18 @@
+# 第9章 TiFlash 简介与 HTAP 实战
+
+近年来，随着企业数字化转型的不断深入和发展，数据逐渐成为企业最重要的资产。对于每一个企业来说，都需要关注数据从产生、存储、分析到利用，并发挥其巨大价值的整个过程。此外，随着企业之间竞争的不断加剧，对数据的产生到发挥其价值的时间延迟要求越来越短。
+
+作为存储和处理数据最重要的基础软件——数据库系统，一般可以按照负载类型分成 OLTP 型数据库和 OLAP 数据库。在一个企业中，这两种类型的数据库通常是并存的，分别支撑这两种负载类型的应用系统。目前，很多企业的这两种类型的系统之间是通过较为复杂的 ETL 过程“打通的”，数据在时效性上具有比较大的 T+N 延时，这越来越难以满足企业在数据处理和分析方面对时效性的要求。
+
+
+近几年，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)