畅想TiDB应用场景和HTAP演进之路


作者: 康凯森

日期: 2018-04-30

分类: 数据库


前一阵阅读了TiDB官方的文档和使用案例,对TiDB的架构原理,使用场景有了一定了解,本文深度畅想(胡思乱想)下TiDB未来可能的应用场景和HTAP的演进之路。在畅想TiDB的应用场景之前,我们先了解下TiDB诞生的背景和TiDB是什么,要解决什么问题。

1 Why TiDB

db.png-83.1kB

如上图,从1970s年代开始,出现了以Mysql,PostgreSQL为代表的RDBMS, 并在相当长的时间内占据主导地位,但是随着21世纪互联网的快速发展和业务数据的飞速增长,传统数据库缺乏Scalability的缺陷暴露出来,于是出现了以HBase,Redis,MongoDB为代表的NoSQL数据库,NoSQL数据库拥有很好的Scalability和Availability,但是缺乏SQL和ACID Transaction。因此,我们需要一个新一代数据库,能够同时拥有RDBMS和NoSQL数据库的优点。

2 What TiDB

What TiDB

TiDB是一款HTAP数据库(同时支持OLTP和OLAP查询),同时具备了RDBMS和NoSQL数据库的优点,具有以下特点:

  • 优秀的横向扩展能力
  • 高可用
  • 强一致性
  • 支持ACID事务
  • 支持SQL,兼容Mysql协议和绝大多数Mysql语法
  • Cloud-Native
  • 支持多数据中心

TiDB Architecture

TiDB的架构图如上图所示,TiDB的组件共有3个:TiKV Server,TiDB Server,Placement Driver。 每个组件的主要职责如下:

1 TiKV Server

如下图,TiKV Server 负责存储数据,TiKV 是一个支持事务的分布式Key-Value存储引擎,如果不考虑Region复制,一致性,和事务的话,TiKV其实和HBase很像,底层数据结构都是LSM-Tree, Region都是Range分区, Region都是计算和负载均衡的基本单位。

TiKV.png-345.6kB

2 TiDB Server

如下图,TiDB Server 负责接收 SQL 请求,生成SQL的逻辑计划和物理计划,并通过 PD 找到存储计算所需数据的 TiKV 地址,将SQL转换为TiKV的KV操作,与 TiKV 交互获取数据,最终返回结果。

TiDB Server 是无状态的,其本身并不存储数据,只负责计算,可以无限水平扩展。 TiDB Server 类似Kylin中的QueryServer。

TiDB.png-353kB

3 Placement Driver

Placement Driver 主要有以下职责:

  1. 集群的元信息 (某个 Key 存储在哪个 TiKV 节点)
  2. TiKV 集群进行调度和负载均衡
  3. 分配全局唯一且递增的事务 ID

3 TiDB的理论背书

  • Google Spanner: 最主要的特性就是支持跨行事务和在分布式场景上实现 Serializable 的事务隔离级别. TIKV主要参考此篇论文实现。
  • F1: A Distributed SQL Database That Scales: 基于Google Spanner实现的NewSQL数据库, F1论述了Spanner上层的分布式SQL层怎么实现,分布式的Plan怎么生成和优化,TIDB主要参考此篇论文实现。
  • Raft: TiKV 使用 Raft 协议做复制,保持数据的一致性和容灾。
  • Online, Asynchronous Schema Change in F1:TiDB的在线Schema变更主要参考此篇论文实现。
  • Google Percolator: 经过优化的 2PC 实现,依赖一个单点的授时服务 TSO 来实现单调递增的事务编号生成,提供 SI 的隔离级别. TIKV的事务主要参考此篇论文实现。

4 TiDB的应用场景

4.1 Replace Mysql

TiDB replace Mysql

相比Mysql,TiDB 可以做到横向扩展,高可用。 此外,由于TiDB兼容Mysql协议和绝大多数Mysql语法,在大多数情况下,用户无需修改一行代码就可以从Mysql无缝迁移到TiDB。这也是目前TiDB在业界最广泛的应用场景。 下图是几个业界的典型应用:

TiDB replace Mysql

4.2 Replace HBase

TiDB replace HBase

相比HBase, TiDB 可以很好地支持SQL, 支持事务,支持二级索引,没有Java GC的痛点(TiKV是由Rust开发,Rust可以完全手动控制内存,无GC)。所以我认为TiDB可以代替掉HBase。 下图是几个业界的典型应用:

TiDB replace HBase

4.3 TiDB for OLAP

TiDB的设计目标是同时很好的支持OLTP和OLAP,但是从公开的测试结果来看,TiDB的OLAP性能一般,不如现在专门的OLAP系统(Kylin, Druid,Palo,ClickHouse等),在业界实践中,大多数公司都会引入TiSpark来解决OLAP问题。

从OLAP视角来看,TiDB的优点如下:

  • 兼容Mysql协议和语法
  • 实时和离线数据导入
  • 支持聚合,明细,点更新
  • 在线Schema变更
  • 易运维
  • Both OLAP And OLTP

从OLAP视角来看,TiDB的缺点如下:

  • 无列式存储
  • 无预计算手段
  • 无向量化执行

4.4 TiDB for 实时数仓

TiDB realtime data warehouse

上图是易果集团实时数仓的架构图,上游OLTP的数据和其他的实时数据可以实时写入TiDB,下游OLAP的业务可以通过 TiDB或者TiSpark实时进行分析, 并且可以通过TiSpark将实时和离线整合起来。

4.5 Data Ecosystem Based On TiDB (In the future)

以下的畅想(胡思乱想) 需要TiDB未来能做到以下两点:

  1. 高效的OLAP查询
  2. 高效的批量写入

Data Ecosystem Based On TiDB

上图的含义如下:

  1. 最上游让Mysql和TiDB支撑在线OLTP和部分在线OLAP业务。
  2. 通过实时的Binlog同步将数据同步到下游,下游可以是基于TiDB的数仓,也可以是Kafka,还可以是其他系统,比如数据实时同步到ES做全文检索。
  3. Kafka的数据可以被任意下游消费,一种数据流是经过Flink等实时计算引擎进行ETL处理后,导入TiDB进行OLAP查询。
  4. 基于TiDB的数仓可以提供历史数据的Ad-hoc查询,也可以通过Spark进行ETL,ML,Ad-hoc查询。
  5. 所有结构化数据的查询都可以交给TiDB,非结构化数据的处理和查询交给Spark。

上图基于TiDB的Data Ecosystem相比于现在基于Hadoop的Data Ecosystem具有以下优点:

  1. 减少数据冗余,节省存储成本:现在有些数据可能在Mysql, Hive, OLAP系统中都有1份,其原因就是Mysql和Hive的查询效率低下,而在TiDB中,我们有可能只需要一份数据,如果TiDB能同时很好的支持OLTP和OLAP。
  2. 更精简的ETL流程:由于TiDB拥有OLTP和OLAP能力,现在许多以聚合,过滤为主的ETL就不需要做了。
  3. 更少的系统维护,更低的运维成本:如果我们基于TiDB构建数据仓库且TiDB能同时很好的支持OLTP和OLAP,那么Mysql,Hive,HBase,Presto,Kylin,Druid等系统理论上都可以被TiDB替换掉,并且可以实现结构化数据查询的接口大一统。
  4. 更高的开发效率:如果TiDB能同时很好的支持OLTP和OLAP,那么实现OALP需求,用户的开发成本就会低很多,甚至无需开发。
  5. 更低的学习成本:TiDB只要用户懂SQL就可以轻松的用起来,但是目前的Hadoop生态系统繁杂,概念众多,用户的学习成本和上手成本都较高。

5 TiDB HTAP 演进之路

那么我们可以通过哪些方法来加强TiDB的OLAP能力,使其成为一个真正的HTAP数据库呢?在介绍HTAP的演进之路前,我们先简介下行存和列存的优缺点和适用场景。

5.1 行存的优缺点和适用场景

行存的优缺点和适用场景

上图是个行存的示意图,就是数据按行组织,查询时按行读取。行存在学术论文中一般简称为NSM(N-ary Storage Mode)。

行存的优点如下:

  • 适合快速的点插入,点更新和点删除
  • 对于需要访问全部列的查询十分友好

行存的缺点如下:

  • 对需要读取大量数据并访问部分列的场景不友好

所以行存适用于OLTP场景。

5.2 列存的优缺点和适用场景

列存的优缺点和适用场景

上图是个列存的示意图,就是数据按列组织,每列的数据连续存放在一起,查询时按列读取。 列存在学术论文中一般简称为DSM(Decomposition Storage Model)。

列存的优点如下:

  • 只读取部分列时,可以减少IO
  • 更好的编码和压缩(由于每列的数据类型相同)
  • 更易于实现向量化执行

列存的缺点如下:

  • 不适合随机的插入,删除,更新。(多列之间存在拆分和合并的开销)

所以列存适用于OLAP场景。

5.3 TiDB HTAP 演进之路——行列转换

现在我们已经知道了OLTP需要行存,OLAP需要列存,OLTP一般是查询较新的数据,OLAP一般是分析历史数据,所以要想同时很好地支持OLTP和OLAP,我们一个很自然的思路就是进行 行列转换,对于较新的数据使用行存,对于历史数据使用列存。 如下图所示:

屏幕快照 2018-04-30 下午4.44.02.png-171.5kB

这种实现的难点就是如何确定一份数据什么时候由行存转为列存,此外,由于要支持点的更新和删除,必然要支持Compaction。Kudu, Druid采用了类型的思路。

5.4 TiDB HTAP 演进之路——行列混存 Spanner

上面的行列转换,是要维护两套独立的存储格式,有没有可能只用一种存储格式呢? 答案是可能的,就是行列混存。

行列混存 Spanner

上图是Spanner采用的行列混存方案,具体来说,就是将一个Page拆成多个Mini Page, 一列对应一个Mini Page,第一列放在第一个Mini Page,第二列放在第二个Mini Page,以此类推。在每个Page 的开头,会存放每个Mini Page的Offset。 好处是:当要依据某一列进行 Scan的时候,我们可以方便的在Mini Page里面顺序扫描,充分利用 Cache;而对于需要访问多列得到最终tuple的场景,我们也仅仅需要在同一个Page里面的Mini page之间读取相关的数据。

更多信息可以参考 PAX:一个 Cache 友好高效的行列混存方案

5.5 TiDB HTAP 演进之路——行列混存 Peloton

CMU的开源数据库Peloton中采用了另一种行列混存思路,如下图所示:

行列混存 Peloton

Peloton项目基于Tile来实现行列混存, Tile之间是列存,Tile内部是行存。一个Table有多个Tile Group组成, 一个Tile Group可以包含多个Tile。热数据可以存放到OLTP友好的Tile Group中,也就是一个Tile Group里面只有一个Tile,当数据变冷之后,可以将Tile Group 转成对OLAP友好的布局,也就是Tile Grou里面可能有几个Tile了。当Tile Group里面每个Tile都只有一个Column的时候,就变成完全的列存了。 有没有感到Tile的概念和HBase的Column Family很像。

更多信息可以参考 基于 Tile 连接 Row-Store 和 Column-Store

5.6 TiDB HTAP 演进之路——TiDB On ClickHouse

我们知道TiDB在OLAP场景下缺乏一个列式存储,而ClikcHouse是目前已知的单机性能最强大的开源OLAP数据库,但是其在分布式化上做的很差。So,Maybe 我们可以整合TiDB和ClickHouse,用ClickHouse填补TiDB在OLAP场景下的短板,用TiDB填补ClickHouse在分布式,运维性,易用性上的短板。

TiDB On ClickHouse

简单调研TiDB和ClickHouse的接口后,我们会发现,理想是美好的,现实是残酷的,真要做TiDB On ClickHouse的话,TiDB和ClickHouse两边都需要做大量的改动。

6 总结

本文简介了Why TiDB的What TiDB,没有讲How TiDB(对于实现细节感兴趣,可以阅读TiDB官方文档,论文和源码), 主要畅想(胡思乱想)了下TiDB的应用场景和HTAP演进之路。 个人比较看好TiDB的未来,TiDB能否拥有更广阔前景的关键就是OLAP能力的强弱

7 参考资料

1 TiDB官方文档和博客

2 CMU-15415-ColumnStore

3 TiDB用户案例


评论