编者按：
9 月 10 日晚，七牛云主办的「云加数据，智驱未来」数据科学系列论坛如期举行。在直播中，PingCAP 联合创始人兼 CTO 黄东旭为我们带来了主题为《 TiDB 在实时数据分析中的最佳实践》的精彩分享。
MySQL 作为单机数据库，当数据量增加时必然涉及到分库分表等操作去换取水平扩展能力，这时候的复杂度将会呈现几何倍的上升。TiDB 五年前的初心是想设计一个替换 MySQL 分库分表的方案，因此 TiDB 最早的目的是想做一个既能够像单机数据库一样使用，同时又拥有水平扩展能力的 OLTP 分布式数据库。
但是，当用户使用 TiDB 存储数据量越来越多后，有一个新类型的需求冒出来：用户会想我能不能直接在 TiDB 去做一些离线，甚至是准在线的数据分析，而不是把数据转移到 Hadoop 上。我认为有很大一部分比例 OLAP 的需求不用做很重的 ETL，比如电商用户，就想看一下现在卖出去多少东西，或者算一下今天赚了多少钱这种报表。但是过去的 Transaction Database 并不是为了这种比较复杂的分析而设计的。
所以这两年有一个新概念叫 HTAP，尽可能模糊了 OLTP 与 OLAP 的概念。过去因为技术、数据结构、硬件、网络等条件都不成熟，因此这两套设计水火不容，所以在技术上强行划分出了 OLTP 和 OLAP。我认为在未来这些技术细节或者底层差异会越来越模糊，包括 Gartner 在一个报告中也提到，未来只会有一种 Database。所以在 HTAP 的新概念之下会有很多更新的 Workload 诞生出来。
HTAP的技术演进过程
在 HTAP 之前，互联网公司是按照下图所示的一个传统架构去做在线业务和离线业务。
在业务侧，OLTP 的数据可能有很多 MySQL 或者分库分表，这些通过 Binlog 打到 Kafka 作为消息队列，传送到一个近实时的系统。比如用 HBase 去做一些数据的归拢，然后再把这个数据在 Hadoop 上用 hive 或者 Spark 这样的技术去做大数据分析和 ETL，或者再去把 ETL 产生的数据回写到另外的一些 MySQL，或者在另外的一些在线数据库上对外提供服务。这是一个传统的大数据处理架构，但这种架构的一个问题就是：在线和离线的业务是分得很开的，中间都要通过 ETL 的过程和数据的传输层来去串联整个系统。
这就为什么有很多公司只能看到前一天的数据，因为可能要一批一批地去加载。所以我认为 HTAP 这个技术的方向对于用户来说，就像智能手机对于传统手机一样，有了智能手机我就不再需要 GPS、单反相机、移动电话，一个 iPhone 就够了，极大地降低了业务和架构的复杂度。另外，原来可能要维护很多套系统、很多个团队，如果 HTAP 真的存在了，对于绝大多数业务而言只需要维护一套系统。从领导者的角度来说，运维成本和团队人员成本都会降低。
最后一点，我认为对于业务而言意义更大。从前我们很多决策依托的是老数据，但现在可以考虑依托实时数据。比如在一个线下商店，只要用户进入商店，就能通过人脸识别或者会员卡马上知道他接下来会想要去消费什么东西，对什么东西感兴趣，从而快速做出决策。这种情况下，如果系统不是实时的就没有意义，可能用户看一看就流失了。所以在这些基础之上叠加起来，可以对整个业务的迭代和敏捷程度有一个很大的提升。我认为 HTAP 是一种新的数据库物种，它不是传统 OLTP 和 OLAP 的改良。
仍然以电商为例，如上图所示：左边是偏交易的，右边是偏分析的。我们把电商平台内部系统切分成订单管理、账单的历史明细、推荐、联合仓储实时查询库存、实时大屏、促销调价、历史报表。线上最左端是订单管理，包括在线交易的部分，所以从最左端是靠近 OLTP 的，最右端是靠近 OLAP 的。
我们可以发现，像销售历史报表这种是纯离线场景，及时性要求不强的，我可以明天或者下个月看到这个月的报表都不受影响。但是，实时的促销调价、实时大屏、仓储查询都是偏实时的，需要根据线上订单情况、用户访问情况、实时交易情况以及其他渠道的推广情况实时去做计算。这些场景里，过去要实现一个这种系统需要用到 Flink、Spark streaming、Kafka 等技术以及很多实时数据同步工具才能实现。
这是一个很复杂的问题，会面临很多技术挑战：
第一个挑战是 OLTP 数据库的水平扩展性，对于 OLTP 数据库来说，拓展方案上只能用分库分表或者在业务层面做切分。
第二个挑战是 OLTP 系统需要同时兼具 OLAP 的能力，且同时支持行存列存。一般的 OLTP 系统都是用行存去作为底层的存储模型，而 OLAP 是使用列存，在查询的效率大概差了上百倍，业务人员很难放心的在一个 OLTP 系统上去跑复杂查询，背后是有一些风险的。因此不仅需要打消用户的担心，而且还需要在去跑 OLAP 端的时候能跑得快，必须得支持列存。
第三个挑战是需要两者有机统一而仅仅是两套分离的系统。如果分离就会面临互联互通的问题，比如在 OLTP 里边的数据怎么同步到 OLAP 系统里，同步的时延大概是多少，这些都是技术挑战。
TiDB 4.0：一个真正的HTAP系统
TiDB 最新的版本是 4.0。在我心中 TiDB 4.0 之前和 TiDB 4.0之后是两个完全不一样的产品。4.0 之前它是一个交易型数据库，是 MySQL 分库分表的很好替换，能支持海量数据的 MySQL 协议的在线业务，但它并不是一个好的数据仓库，也不是一个好的实时分析的产品，因为它是一个行存的数据库，虽然用起来很方便。
而 TiDB 4.0 可以说是一个真正的 HTAP 系统：
首先 TiDB 4.0 引入了列存的存储引擎，说明在与其它 AP 系统相比时，本质上是没有劣势的。
第二， TiDB 4.0 里，计算引擎是根据列存来做向量化的，相当于利用一些 CPU 批量计算的指令集，去在比较紧凑的数据结构格式上去做很高性能计算的一种技术，这是在 OLAP 数据库里面经常使用的一个技术。
还有一点，在传统的 OLAP 数据库里面几乎没法做的一个事情就是：有一些数据是在行存里是更好的，比如一个随机的带索引的点查，要去大海捞针式的查询，可能是在 OLTP 端是很好的 ，就可以直接找到数据。而列存是比较适合比如说我一张大表全部要扫描一遍，批量的扫描、批量的聚合。在 TiDB 4.0 里面，我们用了一些技术可以把这两种不同的存储领域的优势合并在一起，我们最近有一篇关于 HTAP 的论文入选 VLDB ，大家有兴趣可以仔细看看。
简单来说，整个 TiDB 的存储和计算是完全分开的。如果大家熟悉 HBase 就会知道它里面有 region ，每一块数据是一块小分片，在 TiDB 里每一个 region 其实是一个 Raft 的复制小组。相当于我们对每一小块数据的 Raft 复制小组里面引入了一块列存的副本，由于计算层跟存储层是分开的，所以我们的计算层可以根据 SQL 来确定请求，OLAP 的请求就发到 OLAP 的副本上， OLTP 的请求就发到 OLTP 的副本上。因为底层数据的同步，一直是通过 Raft 化整为零的同步。第二就是说在 workload 上，你的 OLTP 业务永远是在 TiKV 这种节点上去执行，OLAP 业务其实是在 TiFlash 的节点上执行，在原理上它是完全分开的，就硬件软件是分开的，你就不用担心说在这边跑一个复杂查询会不会阻塞这边，而且数据的同步是完全实时的。
所以底层的核心要点在于本身 TiKV 这边提供了一个很好的数据弹性伸缩机制，我们叫 Multi-Raft。实际上把我们所有的 data 拆成了无数个 Raft 的复制小组，我只需要清楚怎么去支撑支持这种异构的数据源，只需要给我的 Raft 的小组里边多一份异构的数据副本，这就很漂亮的嵌入到了原来的 Multi-Raft 的体系里。
而且在这一点上，它与其他的基于 Binlog、Kafka 的数据同步相比，有一个天然的优势，就是不需要其他的 Kafka。想象一下，如果我是两套不同的系统，左边是 MySQL，右边是 Hadoop，中间通过 Kafka 去同步，如果左右两边的数据吞吐量都特别大，Kafka 变成数据同步的过程，就会变成你的瓶颈。
所以在这一点上，TiDB 复制模式的漂亮之处在于它的数据同步的拓展是随着数据本身的拓展是一起的，相当于把整个数据的同步过程化整为零，拆到了每一块数据分片里面。
在前述 HTAP 场景下，简单就是说一句 SQL 开启一个表的列传模式，后 OLTP 业务完全不用做任何修改，但同时又能直接能在数据库上做 OLAP 的分析，这样整体的架构的复杂度，运维的成本，业务的实质性与业务的敏捷性就有很大的提升。所以从传统的交易分析的架构简化成为一个大的中央的 the source of truth 的架构，同时提供 APP 的 server 以及这种事实分析的商业智能的服务。
同时，你也可以去结合现有数仓把 TiDB 作为一个数据的中间层，当然我并不是说他一定会去替换掉原来的这种 Hadoop，或者说这种 database 的这种模型。因为确实有一些非实时的查询，避免不了 ETL，但是可以使用 TiDB 架在 Hadoop 之上提升整个数据扭转的一个实时性。
TiDB 是整体架构中的实时层的很好补充，这就是我今天的一个分享，谢谢大家。
