在解释将HTAP导入Xiaohongshu之前，让我们简要介绍Xiaohongshu。
xiaohongshu被称为中文版本的Instagram，但是除了通常的社交功能（例如视频和图像共享）外，它还还包括一个电子商务平台。根据Xiaohongshu的官方网站，截至2019年，活跃用户已超过1亿。
这既是社交媒体又是电子商务网站，每天生成的数据量在数十亿美元。为了支持数据驱动的决策，这些大量数据必须经过多层清洁，转换和聚合，更重要的是，决策的实时性质也需要解决。
此外，Xiaohongshu的应用程序方案和用户数量继续增长，因此整个数据基础架构的可扩展性也是一个主要的挑战。
最终，Xiaohongshu采用TIDB作为实时流式存储。
Why Xiaohongshu chose TiDB?
实际上，小舒（Xiaohongshu）在2017年已经针对某些项目采用了TIDB，但直到2018年才被广泛使用。
三个主要原因如下。
- 由于数据驱动的决策，临时查询将有各种OLAP需求，因此传统的OLTP数据库无法支持使用。
- 许多OLAP数据库可以有效地处理查询，但是写入性能不佳，而TIDB写入也具有出色的性能。
- 在数据簇的水平缩放方案中，必须尽可能快地提供新实例。 TIDB通过筏多数机制使所有实例中的数据集保持一致。
现在，tidb已被广泛用于小舒的各个领域，包括
- 数据仓库应用程序
- 报告分析
- 促销销售的实时仪表板
- 反欺诈检测
- 等。
过去的疼痛点
通常，整个数据体系结构如下。
在这种性能差的建筑中，有三个典型用例。
首先，在生产环境数据库上执行临时查询。为避免增加生产数据库的开销，必须制作生产数据库的完整副本，并且所有临时查询均在副本上运行。
但是，用于生产的MySQL使用碎片，这在操作中产生了很高的复杂性。除了操作难度之外，在碎片的中间软件上的集合的实施（例如group by，join等）也导致了实施的复杂性，另一方面，MySQL上的交易也是一个大挑战。
其次，为了更有效地查询报告，报告分析是通过预处理生成的，并存储在独立的MySQL中，以避免Hadoop直接查询的延迟。但是，由于它是预处理的，因此无法有效地响应要求更改。此外，由于缺乏碎片，独立的MySQL具有较小的可扩展性。
最后，要在各种应用程序场景中执行反欺诈检测，它必须依靠存储在数据湖中的数据，这不是实时的，而是T + 1 Ingesion。这使得反欺诈不可能在时间内工作，即使检测到欺诈，也已经造成了损害。
解决方案
这三种情况的答案是tidb。
在临时查询的用例中，必须处理两个疼痛点，一个是操作的困难，另一个是实施的复杂性。然后，只需将所有数据放入TIDB并维护一个TIDB即可。因为TIDB完全支持MySQL 5.7，因此可以通过MySQL Binlog同步。
当然，它并不那么简单。要将碎片数据库放入TIDB中，它需要正确处理数据，即将它们合并到一个大宽表中。因此，我们需要处理流媒体中合并和自动提出主要密钥的问题。但是最终，所有生产数据库都将与TIDB同步，即使对于Xiaohongshu的数据量，同步延迟都在1秒内。
然后，可以将相同的做法应用于报告分析和反欺诈。
由于实时流媒体流，反欺诈不再需要T + 1时间来响应，并且可以直接通过Flink SQL来处理实时流媒体。另一方面，报告分析更容易，因为所有数据都可用，并且可以在单个数据库上操作。
发生了新问题
首次引入tidb时，xiaohongshu中使用的tidb版本为3.x。
tidb 3.x仍然是基于行的存储引擎，尽管它可以在OLAP中实现良好的性能，但对于大型数据量来说，它仍然不够好。此外，所有场景都使用无法隔离临时查询和生产应用的相同TIDB群集。
，但是这些问题在升级到tidb 4.x版本后得到了解决。
原因是tidb 4.x引入了HTAP体系结构，该体系结构可以使行存储引擎和列存储引擎的共存。称为Tiflash的新列存储引擎独立于原始行存储引擎TIKV，不会互相干扰。
当应用程序将数据写入tikv时，数据将迅速同步到tiflash通过筏学习者机制，以使行存储和列存储保持一致。
此外，TIDB使用内部CBO来知道查询是否应立即使用行或列引擎并自动路由查询，从而大大降低了应用程序的复杂性。
tidb 4.x还具有一种新的机制，有助于提高整个数据体系结构的性能：悲观的锁定。在tidb 3.x中，只有乐观的锁定，这使得在巨大的连续写入数据量下进行交易之间的冲突很容易。
一旦发生交易冲突，它只能在客户端进行重试，从而大大提高了应用程序开发的复杂性。但是悲观的锁定可以有效地解决此问题，并且应用程序的错误处理变得更加简单。
结论
实际上，Xiaohongshu在进行技术选择时也提到了Clickhouse，并且Clickhouse的性能比TIDB更好。但是，Clickhouse相对难以操作和维护。
此外，Clickhouse是列存储引擎，在数据更新方案性能不好。如果重写“更新”以“附加”，则需要一方面的修改成本，另一方面需要额外的删除逻辑。
因此，tidb是最终选择。
从我的角度来看，HTAP是未来，可以通过合并行存储引擎和列存储引擎来涵盖各种用例。仅使用一个数据库来处理大数据的各种需求是成本效益的。
过去，为了支持各种数据产品，我们必须在许多数据库中不断进行技术选择，并仔细考虑各种用例，但是使用HTAP，这些复杂性不再存在。
就个人而言，我期待看到数据工程的逐步简化。