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

简单来说,整个 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 是整体架构中的实时层的很好补充,这就是我今天的一个分享,谢谢大家。

数据科学系列论坛第二期预告

10月20日,七牛云主办的「云加数据,智驱未来」数据科学系列论坛第二期将邀请七牛云数据科学家周暐、支流科技 CEO温铭、eBay Spark committer王玉明等业界专家围绕大数据及数据分析进行专业分享及深度探讨,敬请关注!

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

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