共计 4071 个字符，预计需要花费 11 分钟才能阅读完成。
作者介绍：张亿皓，小红书根底技术部资深开发工程师，负责数据库相干的研发和落地工作。
TiDB 在小红书业务场景的利用简介
2017 年，小红书曾经开始在生产业务中应用 TiDB，真正成体系的去做 TiDB 的落地是在 2018 年，为什么要抉择应用 TiDB？
当今很多公司的业务都是数据驱动，面对小红书 APP 每天数以亿计的数据，咱们心愿有一个数据库可能提供以下个性：
第一，数据应用的多样性 ，有时候须要在数据库做一个 TP 的短查问，做一些很高的写入，有时候又心愿做一些聚合剖析，可能展示汇总统计的后果，TiDB 的 HTAP 架构正好满足了多样性的需要。
第二，更高的时效性 ，咱们晓得有很多数据分析的引擎尽管计算很快，然而对于实时剖析的反对能力比拟弱，TiDB 能够提供更高的时效性。
第三，TiDB 基于 Raft 的扩展性 ，小红书 APP 每天的数据都是上亿级别，单点的集群总有一天会被打满，会被打爆，咱们就冀望能有一个扩展性极佳且扩容不便的数据库，TiDB 十分符合，所以咱们抉择了 TiDB。
TiDB 目前在小红书的利用涵盖报表剖析、大促实时大屏、物流仓储、数仓利用、电商数据中台、内容平安审核等多个业务场景。6 月 6 日是小红书的周年庆大促，须要展示一些实时的销量、店家成交总额排名、总销量等信息，这个实时大屏的利用前面连贯的就是 TiDB。
TiDB 在这些业务当中给咱们解决了哪些问题？我从这些业务中筛选了三个十分典型的利用场景来跟大家分享。
- 数据报表：数据报表其实很好了解，分析师常常须要看一些数据，比方这周的走势，看一些销量状况，看一些用户增长状况，看同比与环比数据。
- 线上业务库的实时查问：比方 300 亿行的一个表，MySQL 必定存不下，须要走分库分表的逻辑，而且心愿在做查问或者剖析的时候不能对在线业务产生影响，解决线上分库分表 MySQL 的查问问题。
- 反欺诈数据分析：所谓反欺诈举个例子像黄牛薅羊毛，小红书的电商平台定期会发一些优惠券，黄牛就最喜爱薅这些优惠券，咱们是否在短时间内抓到这些黑产行为，将他们捕获下来进行剖析和拦截。
传统 MySQL 与数仓计划的局限
在没有 TiDB 的时候，咱们怎么做？如上图所示，从业务逻辑上来划分，从上到下是业务在线层、数仓离线层和数据服务层。
首先在数据报表场景，采纳 Hadoop 数仓对数据做一些预聚合，而后把这些高维度的数据简略聚合一下放到 MySQL 外面再做查问。对于数据报表，会把 Hadoop 外面的数据通过 Hive 以 T+1 的模式每天做一些预聚合放到 MySQL 外面，再搭建一些 BI 零碎进行图形展现化的报表查问，分析师就能够看到他们定制化的一些报表。然而随着业务的快速增长，报表的模式变得更加多种多样，MySQL 的扩展性也是一个比拟头疼的问题，如果单纯地减少一些 MySQL 的节点，到最初就会变成咱们如何治理那么多 MySQL 节点的问题，搞过运维的同学都晓得，这是一件比拟繁缛的事件。
再来看在线的 MySQL 分库分表场景，咱们要在下面做数据查问，又不能影响线上库，所以只能去查从库，这个从库当然也是一个分库分表的场景。这里产生了一系列问题：首先还是运维的问题，分库分表 MySQL 那么多节点怎么管？怎么扩容？分片是不是要从新去做 Sharding？如何保障一致性？缩容怎么缩？元信息怎么治理？这是运维下面的复杂度。除此之外，我感觉有必要提的一点，比如说线上的一个分库分表 MySQL，我在下面想做一个事务，分库分表的中间件不便做吗？如果我还想做一个 JOIN，甚至我还想做一个 Group by 聚合查问，分库分表中间件不便做吗？可能能够做，但都不会很简略，所以咱们须要有一个可能不便地做比较复杂分布式查问的计划。
第三在反欺诈数据分析场景，咱们比拟关注时效性。在 TiDB 之前对于后端的一些打点数据，咱们这些数据写到数仓外面，等到 T+1 第二天的时候，业务刚才能查到下面的数据，这样 T+1 的时效性就比拟差了。黄牛薅羊毛是一个很快的事件，到第二天可能间接薅完了你也没方法，所以十分心愿最好能在半分钟、十秒钟，甚至秒级别，就能看到收回优惠券的具体应用状况。
引入 TiDB HTAP 计划，晋升全场景数据服务能力
基于以上场景的种种挑战，咱们引入了 TiDB 3.0 HTAP 计划，来看看新的业务架构，如下图，咱们看到数据服务层采纳 TiDB 就能够提供业务所需的全副数据服务。
咱们从新梳理一下引入 TiDB 之后的三个业务场景。
在数据报表场景，间接用 TiDB 间接替换 MySQL，解决了随着业务增长 MySQL 扩容简单的问题。我感觉能实现无缝切换最重要的起因是 TiDB 一开始就反对 MySQL 协定，这是我感觉 TiDB 设计上十分牛的一点，很聪慧的一点。前端的 BI 工具不必再开发一个所谓的 TiDB 驱动，间接用 MySQL 驱动就能够。在扩容层面，这是 TiDB 最善于的事件，能够间接加个节点，数据主动做好从新平衡，十分不便。
在分库分表的 MySQL 场景，分库分表怎么做查问？咱们造了一条实时流，把 MySQL 的数据通过 Binlog 实时写到 TiDB 外面，同步的提早在一秒钟以内。实时流不仅仅是一个简略的数据同步，还做了一个事件就是合库，什么叫合库？原来线上分了一万个表，分表是因为 MySQL 存不下，当初一个 TiDB 集群是可能存下的，就没有必要分表了。实时流写到 TiDB 外面的同时，还把这一万张分表合成了一张大表，合的过程中可能还要解决一些非凡问题，比如说原来的自增主键怎么搞？自增主键合起来的时候是不是有问题？可能要做一些数据转换，有一些数据要做格局或者映射之类的数据处理，总之在实时流外面都把这些事件解决好，最初咱们看到一张大表，就没有分库分表这件事件。在 TiDB 下面再做一些查问，不影响主库，TiDB 实际上作为一个 MySQL 的大从库，如果想做一个事务，也没问题，TiDB 反对事务，想做一个 JOIN，想做一个聚合，TiDB 都可能反对这类操作，最初就是一张大表出现在 TiDB 外面。
最初看看反欺诈数据分析场景，利用了 TiDB 之后咱们把 T+1 的提交改成了由 Flink 的 SQL 实时来写入，打点数据产生的速率很高，峰值的 QPS 大略能达到三四万，单表一天大略写入 5 亿左右的数据，如果咱们保留 10 天的数据大略会达到 50 亿单表的量级。写进来之后，怎么做查问呢？次要是一些 Ad – Hoc 查问，如果分析师想看这次优惠券发下去的应用状况是怎么样的，散发状况是怎么样的，心愿能在分钟级别就可能看到，每次 SQL 都可能有变动，咱们间接绕过 Hadoop 数仓，通过 TiDB 来提供更加实时的查问。
TiDB 4.0 HTAP 计划的利用成果
通过引入 TiDB，咱们在以上三个典型业务场景上解决了遇到的各种问题。这个计划有没有有余？其实也是有的，如果 3.0 没有有余的话，可能就不会诞生明天的 4.0。咱们应用下来的感触次要是 TiDB 3.0 在 OLAP 剖析这一块能力稍有些有余，TiKV 是一个基于行存的数据库，去跟一些专门做剖析的列存引擎去比拟，其实是没有可比性的。TiDB 如何解决这个问题？是不是 TiDB 引入一个列存引擎就能够？到了 4.0 的时候，TiDB 带着 TiFlash 这么一个列存引擎来到了咱们背后。
TiFlash 的设计有几点我感觉十分棒：首先，作为一个列存引擎 TiFlash 可能与 TiKV 共存，不是说只能选列存，只能选行存，两个能够同时存在，既然能同时存在，两头这个行存到列存数据的复制和转换怎么做？是不是须要再搭一条复制流去做？不必，TiDB 都帮咱们做好了，通过 Raft Learner 复制机制间接采纳一个较低提早的形式把数据全副同步到 TiFlash 外面。从查问端来看，是否须要做一些非凡的解决让 TiFlash 走列存引擎呢？答案是都不须要，TiDB 有一个 CBO 执行打算的主动路由，能够晓得这条 SQL 是 TiFlash 扫全表比拟好还是走 TiKV 的索引查问比拟快，能够帮我布局好。引入 TiFlash 的运维老本是非常低的，我要做的事件就是申请机器把 TiFlash 部署下来，而后就完结了，数据主动同步过来，查问主动路由过来，什么事件都不必管。
咱们也对 TiFlash 做了测试，拿物流场景作为例子，咱们对其中的 393 条生产查问进行评估，上图的纵轴是 TiFlash 的性能晋升， 从聚合查问来看，相似于 Group by、SUM 这些聚合查问，大略有三到十倍的性能晋升，均匀工夫缩小 68% 左右。如果是非聚合查问，均匀工夫缩小 4% 左右，非聚合查问基本上都命中了 TiKV 的索引，没有走 TiFlash 的列存。
TiDB 4.0 还给咱们带来乐观锁，在物流场景很多表须要 JOIN，JOIN 其实是代价比拟高的一件事件。为了防止 JOIN，咱们会把这些要 JOIN 的表提前给拼成一张大宽表。举个例子，我把三张表拼成一张大宽表，那就有三个流就会同时更新大宽表，更新同一行，原来的 TiDB 3.0 是乐观锁的机制，就会产生事务抵触，对于客户端的重试来说是不太敌对。TiDB 4.0 有了乐观锁，很好地解决了这个问题。
咱们平时和 PingCAP 的 TiFlash 团队也有比拟多的交换，咱们也会常常提出一些新的需要，例如最早的时候，TiFlash 是不反对 ditinct count 这一类场景的，效率很低，开发团队在理解咱们的需要后很快做出了优化，反对了 ditinct count 场景。
TiFlash 与 ClickHouse 怎么选？
最初说一下 TiFlash 跟其余计划的比照，拿大家比拟相熟的 ClickHouse 列存引擎做个比拟，ClickHouse 其实单从计算性能来说，的确是比 TiFlash 要快一点。为什么某一些场景咱们还是抉择 TiFlash 呢？因为 ClickHouse 有一些问题，比如说 ClickHouse 的集群模式运维起来比较复杂，对数据更新的反对也比拟弱，因为很多业务是事务型的，有很多更新需要，而 ClickHouse 更新的性能比拟差，如果要改成 Append、Insert 这个逻辑，业务侧就要做大量的改变，例如数据要做去重之类的事件，很多场景下为了反对高频率的更新咱们就抉择了 TiFlash。
本文整顿自张亿皓在 TiDB DevCon 2020 上的演讲。
