七牛云数据科学系列论坛嘉宾黄东旭：TiDB 在实时数据分析中的最佳实践

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 ,大家有兴趣可以仔细看看。

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!