{
"componentChunkName": "component---src-templates-blog-blog-detail-tsx",
"path": "/blog/tidb-in-social-application",
"result": {"pageContext":{"blog":{"id":"Blogs_485","title":"方案精讲丨TiDB 在社交场景的解决方案实践","tags":["技术出海"],"category":{"name":"产品技术解读"},"summary":"本文介绍了 TiDB 数据库在社交应用出海中的应用。文章通过几个社交应用企业的实践案例，具体说明了 TiDB 的优势和应用场景。","body":"## 导读\n\n社交出海已经逐渐成为国内科技企业技术出海的主战地，本文介绍了 TiDB 数据库在社交应用出海中的应用。TiDB 可以解决大规模数据处理、横向扩展、多数据中心部署、强一致性和 SQL 兼容性等技术挑战，帮助社交应用实现稳定高效的全球化发展。文章通过几个社交应用企业的实践案例，具体说明了 TiDB 的优势和应用场景。 \n\n在中国互联网高速增长的十几年间，出海应用主要以工具产品为主，随着市场不断拓宽，社交娱乐等也成为互联网公司出海热衷的领域。同时，过去中国出海应用只在边缘市场做探索，而现在则是面向海外主流市场全面探索，从定位于市场的补充产品蜕变为海外应用市场的主流产品。\n\n最新的 data.ai 研究显示，移动生活方式在印尼和新加坡占据主导地位，用户每天使用应用的时间达到了 5.7 小时，有 13 个地区的用户每天使用应用的时间超过了 4 小时。此外，2022 年新加坡和澳大利亚的增长时长比 2020 年增长了 40%，说明社交应用市场正在不断发展。\n\n根据 data.ai 在 2021 年对移动应用使用时长的统计，用户有 70% 的时间花在了社交与照片和视频应用上。这相当于用户在使用移动应用时每 10 分钟中就有 7 分钟花在社交和照片视频上。另外根据 2022 年第二季度的下载量、用户支出和月活跃用户数（MAU）的排名显示，社交媒体和在线视频的应用为主导。从上面几组数据可以看出，社交出海可以为出海企业带来了无限的未来和想象空间，社交出海开始成为出海的主旋律。\n\n## 社交出海面临的数据库技术挑战\n\n作为出海业务，基于社交产生了很多新业务模式，比如社交+直播、社交+游戏、社交+电商，这些都是以社交作为出海业务的基石，那么在社交场景中会面临怎样的挑战呢？在过去，会面临比较多的困难，这里主要讲以下三个挑战：\n\n第一是扩展性挑战。社交应用在海外市场面对的用户量和数据量都会大幅增加，快速扩容升级成为了关键，如果采用传统的对数据库进行分库分表是很难满足业务要求的。因为分库分表也会带来新的问题：第一是业务的改造成本高，业务需要进行额外的开发来适配分库分表的路由规则；第二是多维查询会变得困难，因为分库分表是基于某个维度或者字段进行拆分的，比如一个电商平台，如果按照用户 ID 进行拆分，那么商家维度的查询就会困难；第三是对分布式事务的支持有限；第四是由于业务的发展，数据量在不断的增加，当达到一定容量时就得进行二次拆分，也给运维带来了一个很大的成本开销。\n\n第二个时效性的挑战。在社交场景中，如用户画像、风控、广告投放等业务对于时效性的要求比较高，如果单单采用以前的 kafka+Flink 或者是 Storm 这些流式计算引擎，往往不能很好的满足实时查询分析的要求。比如业务需要对用户画像进行精准的广告投放。业务出海在不同的国家和地区也要符合当地的法律法规的，比如：文化宗教信仰、区域政治动荡，这些都需要依靠于实时的风控来进行保障的。\n\n第三个是成本挑战。海外社交产品从 0 到 1 的冷启动是需要对产品、用户、运营三个基本要素进行快速试错，并验证项目可行性的过程，以低成本不断迭代更新。其中成本可以分为两块：一个是资源成本一个是人力成本。如何在业务规模的不同阶段来控制资源的成本呢？如何让开发人员在更短的时间内迭代新功能并快速上线呢？TiDB 就能很好的帮助企业解决这些问题，比如针对资源成本的考虑，TiDB Cloud 支持集群的 Scale Up 和 Scale Out，Serverless。\n\n## TiDB 在社交的应用场景\n\n在社交场景中，按照业务模块可以划分为通讯信息层、支付交易层、平台运营管理层。其中通讯信息是基础，包含了社交中的好友关系、通讯数据、包括聊天记录文章、帖子等，这部分数据的特点是数据量大，在对实时性有要求的同时还对大数据的分析查询也有一定的要求。支付交易层是社交软件的变现方式，包括了交易记录、用户钱包、账单管理等核心功能，这部分数据的特点是对数据的高可用要求很高。平台运营管理层更多的是以辅助形式出现，对于数据有比较强的分析和管理要求。对于以上三个模块，TiDB 有哪些功能是可以满足这些要求的呢？\n\n### TiDB 支撑社交通讯信息场景\n\n\n\n在通讯信息层的账号中心功能上，对于面向出海的应用来说，用户的分布往往是在不同国家和地区，对此， TiDB 可以支持本地读的跨 Region Global Database，用户可以在本地完成数据身份的验证；对大数据量的通讯来说，TiDB 也提供了弹性的扩容能力，用户不需要分库分表来打散数据，可以针对不同的 TiDB 组件进行扩容，比如在计算能力不足时可以扩容 TiDB Server，存储能力不足时可以扩容 TiKV 节点，AP 能力不足时可以扩容 TiFlash 节点，是非常灵活的。在一些对于消息有时效性要求的场景中，TiDB 也提供了基于 TTL 的行功能，方便对于数据的清理。另外，针对该行业的初创企业，TiDB 提供的 Serverless 可以帮助用户最大化节省成本。\n\n### TiDB 支撑社交支付交易场景\n\n\n\n在支付交易场景中，用户钱包和交易流水等关系到公司营收的核心功能，重中之重是如何保证高可用的可靠性。这方面 TiDB Cloud 集群本身就是多副本，每个副本分布在不同的 AZ，这已经是具备了比较高的可用性。此外， TiDB Cloud 还支持跨 region 的多数据中心复制，甚至还可以跨云进行复制，云中立也是 TiDB Cloud 的一个优势。\n\n另外对于数据的恢复能力，TiDB Cloud 提供了 PITR 和 Flashback 两个功能，如果是在 GC 范围内的数据恢复可以基于表、Database、集群这三个维度来进行快速的 Flashback，就再也不用担心数据的误操作。对于超过了 GC 外的恢复，可以通过 PITR 实现任意时间点的恢复。因此，这些功能对高可靠性要求能很好的满足。\n\n### TiDB 支撑社交平台运营管理场景\n\n\n\n在平台运营管理层面，用户画像和实时风控是两个重要组成部分。用户画像可以用于基于内容的推送和广告的精准投放以及对人群的划分。在出海场景中，数据合规是一个绕不开的话题，比如文化宗教信仰、区域的政治动荡等，这些都需要依靠实时风控。用户画像和实时风控这两个业务的特点是数据量大的同时对实时性分析有比较高的要求，TiDB HTAP 的特性就能很好的解决这个问题。对于类似广告投放优化的功能，有一个特点就是具有周期性的负载场景，TiDB Cloud Serveless 就非常适合这种场景，可以在高峰时进行弹性扩容，同时也支持 Flink、Spark 接口，可以以大数据技术栈进行很好的集成。\n\n## TiDB 在社交应用场景的实践\n\n### TiDB 助力 LiveMe 简化架构新体验\n\nLiveMe 是一个全球直播和社交平台，于 2016 年 4 月推出。LiveMe 的产品功能包括 H2H、多人聊天、虚拟形象直播、蹦迪房等，它使用户能够随时随地直播、并观看其他精彩的直播以及与世界各地的朋友进行视频聊天。目前 LiveMe 已在全球积累了超过 1 亿用户和超过 300 万的主播。它已成为美国最受欢迎的社交应用程序之一，并已在 200 多个国家和地区推出。\n\n与其他行业出海一样，直播产品的出海也面临着许多全球化挑战。如各地的合规监管、本地化运营、持续创新、政治文化差异等，都为直播产品出海带来巨大挑战。而在出海的过程中，底层的技术能力帮助 LiveMe 在成本节约、用户增长、金融风控、提升研发效率等方面不断实现精细化运营与业务创新。\n\n经过了多年的沉淀，LiveMe 在业务上已经形成了线上微服务主导，线下计算中心主导的技术架构。线上业务是通过 Go 语言开发的一套微服务架构，每个服务根据不同业务特性具有自己独立的存储。线下业务是由数据研发团队来维护，通过 sqoop 和 MySQL Binlog 同步等方式从数据库层面抓取数据到数据仓库，完成一系列业务相关的支持。\n\n这套业务架构中线上业务主要面临着以下痛点：\n\n第一，虽然完成了微服务分库的设计，每个服务都有自己独立的数据库，但是每个业务中又存在很多业务上的大表，都存在 MySQL 分表的现象。在典型的分表场景中，数据库表会按照用户的 UID 尾号经过 MD5 后分到 256 张表，但是日积月累后又需要再根据时间日期做一个垂直的分表，导致数据库表无法完成聚合查询，再加上跨时间段的分表需求，很多场景无法满足线上需求。\n\n第二，对于分析型业务数据而言，需要保证数据的实时性，并保留数据细节。实时的数据分析，可以在业务上更快做出决策，例如在一些活动运营场景中，业务团队需要快速从各个数据维度来分组统计观察活动效果；在金融相关风控业务中，需要根据各个维度快速聚合来判断各项数据是否达到风控模型的阈值。如果使用离线计算的方式，数据的实时性根本无法得到保证；此外，经过离线计算或者实时计算过的数据，如果用户反馈数据有问题，需要查看数据的细节也很难实现。\n\n第三，各种精细化运营需求，例如推荐、个性化运营等场景不断增加，对于数据的实时要求越来越高。因此，LiveMe 急需一种更简单，同时让线上线下业务做好平衡的方案。\n\n基于以上业务挑战，LiveMe 经过一系列技术选型后最终选择了 TiDB 数据库。TiDB 的以下特性可以帮助 LiveMe 很好的应对挑战：\n\n- TiDB 的性能大于等于 MySQL ；\n- TiDB 的 HTAP 特性能够解决线上大表的问题，在后台或者一些实时分析场景中，其 OLAP 分析能力能够保证实时数据报表；\n- TiDB 引入的 MPP 架构分析能力，使得 OLAP 查询速度非常快，这也是 OLAP 数据库架构上的技术方向；\n- TiDB 团队有着完善和专业的技术支持，在过程中可以帮助 LiveMe 解决很多问题，在线上大规模使用后也没有后顾之忧。\n\n### TiDB 在某知名直播互动应用的实践\n\n某知名直播互动应用是一款倡导健康生活的直播互动应用和健康教育平台，可以发现身边的好友，查看他们的可公开资料、相册和动态，根据自己的兴趣爱好进行多维度匹配。截至 2020 年 3 月, 在全球有超过 4900 万的注册用户，用户已遍布全球超过 210 多个国家和地区，中国大陆以外的国家和地区月活用户数，占全球月活跃总用户数的 49%以上。\n\n在使用 TiDB 之前，该应用的用户关系遇到了如下挑战：随着 业务发展，MySQL 性能容量出现了瓶颈，无法满足日益增长的性能和容量要求，如果把用户关系进行分库分表，业务需要做很大的改动；用户关系本来就是一个读多写少的场景，所以为了扩容补容量，增加只读节点，会存在主从复制的延迟的问题；同时一些分析类 SQL 的执行比较差，无法及时返回，所以业务会把一些数据缓存在 Redis 当中，这就导致了 Redis 的资源成本随之增加。\n\n经过一些调研，用户最终选择了 TiDB，使用 TiDB 后收益也很明显，TiDB 可以针对业务发展的不同阶段进行快速的扩缩容，而且对业务是无感知的，业务不需要做改动，无需担心分库分表。针对读多写少的场景可以直接增加 TiDB Server 节点进行扩容，轻松解决了用户的问题。同时，TiDB 还提供了 HTAP 的混合查询能力，用户也把很多之前存储在 Redis 的查询转移到了 TiDB 集群，从而节省出了 Redis 缓存资源的开销，节约了成本。\n\n## 总结\n\n除了上述两家企业，还有不少将 TiDB 作为解决方案的社交出海企业，TiDB 在社交应用出海中能够解决大规模数据处理、横向扩展、多数据中心部署、强一致性和 SQL 兼容性等技术挑战，帮助社交应用实现稳定高效的全球化发展。","date":"2023-04-13","author":"陈畅亮","fillInMethod":"writeDirectly","customUrl":"tidb-in-social-application","file":null,"relatedBlogs":[{"relatedBlog":{"body":"近些年，由于互联网的快速发展以及线上需求的爆发，**直播在国内已经成为一个非常成熟的商业模式**。在娱乐、教育、办公等场景中涌现出许多优秀的视频直播产品。随着国内市场竞争日益白热化，加之企业出海渐成趋势，越来越多的直播公司选择走出去，寻找新的海外直播市场，借鉴国内成熟的产品、运营以及商业模式，让全球的用户都用上中国人创造的产品，LiveMe 便是成功的出海直播产品之一。\n\nLiveMe 是一个全球直播和社交平台，于 2016 年 4 月推出。LiveMe 的产品功能包括 H2H、多人聊天、虚拟形象直播、蹦迪房等，它使用户能够随时随地直播、并观看其他精彩的直播以及与世界各地的朋友进行视频聊天。**目前 LiveMe 已在全球积累了超过 1 亿用户和超过 300 万的主播。它已成为美国最受欢迎的社交应用程序之一，并已在 200 多个国家和地区推出。**\n\n## 业务痛点\n\n与其他行业出海一样，直播产品的出海也面临着许多全球化挑战。如各地的合规监管、本地化运营、持续创新、政治文化差异等，都为直播产品出海带来巨大挑战。**而在出海的过程中，底层的技术能力帮助 LiveMe 在成本节约、用户增长、金融风控、提升研发效率等方面不断实现精细化运营与业务创新。**\n\n经过了多年的沉淀，LiveMe 在业务上已经形成了线上微服务主导，线下计算中心主导的技术架构。线上业务是通过 Go 语言开发的一套微服务架构，每个服务根据不同业务特性具有自己独立的存储。线下业务是由数据研发团队来维护，通过 sqoop 和 MySQL Binlog 同步等方式从数据库层面抓取数据到数据仓库，完成一系列业务相关的支持。\n\n这套业务架构中线上业务主要面临着以下痛点：\n\n第一，虽然完成了微服务分库的设计，每个服务都有自己独立的数据库，**但是每个业务中又存在很多业务上的大表**，都存在 MySQL 分表的现象。在典型的分表场景中，数据库表会按照用户的 UID 尾号经过 MD5 后分到 256 张表，但是日积月累后又需要再根据时间日期做一个垂直的分表，导致数据库表无法完成聚合查询，再加上跨时间段的分表需求，很多场景无法满足线上需求。\n\n第二，**对于分析型业务数据而言，需要保证数据的实时性，并保留数据细节**。实时的数据分析，可以在业务上更快做出决策，例如在一些活动运营场景中，业务团队需要快速从各个数据维度来分组统计观察活动效果；在金融相关风控业务中，需要根据各个维度快速聚合来判断各项数据是否达到风控模型的阈值。如果使用离线计算的方式，数据的实时性根本无法得到保证；此外，经过离线计算或者实时计算过的数据，如果用户反馈数据有问题，需要查看数据的细节也很难实现。\n\n第三，各种精细化运营需求，例如推荐、个性化运营等场景不断增加，**对于数据的实时要求越来越高**。因此，LiveMe 急需一种更简单，同时让线上线下业务做好平衡的方案。\n\n此时，如果 LiveMe 继续选择大数据技术栈解决痛点就会面临以下挑战：1）大数据技术栈的架构非常复杂，中间件过多；2）需要额外的技术栈学习成本，比如如果使用数据同步，就需要 sqoop、scala、kafka 等中间件，会大幅增加整个业务的复杂性；3）希望线上业务以及架构非常简单，能够简化到普通开发人员只要能够 CRUD（增加(Create)、读取(Read)、更新(Update)和删除(Delete)） 数据库就可以上手开发。\n\n## 为什么选择 TiDB ？\n\n基于以上业务挑战，**LiveMe 经过一系列技术选型后最终选择了 TiDB 数据库**。TiDB 的以下特性可以帮助 LiveMe 很好的应对挑战：\n\n1. TiDB 的性能大于等于 MySQL ；\n\n2. TiDB 的 HTAP 特性能够解决线上大表的问题，在后台或者一些实时分析场景中，其 OLAP 分析能力能够保证实时数据报表；\n\n3. TiDB 引入的 MPP 架构分析能力，使得 OLAP 查询速度非常快，这也是 OLAP 数据库架构上的技术方向；\n\n4. TiDB 团队有着完善和专业的技术支持，在过程中可以帮助 LiveMe 解决很多问题，在线上大规模使用后也没有后顾之忧。\n\n## 如何利用 TiDB 实现实时聚合查询\n\n鉴于 LiveMe 的微服务架构，如果将数据源全部替换，工程量大且不能一蹴而就，因此就需要一种兼容性的方案，在保证线上业务不受影响的同时也能使用 TiDB 的特性来解决 LiveMe 的业务痛点。因此，对于需要聚合查询的业务， LiveMe 通过消息队列广播的方式，在业务层订阅相关事件再补充业务侧需要的宽表信息写入 TiDB，基于 TiFlash 就可以做到实时的运营报表。业务开发人员只需要编写对应的 SQL 查询，就可以轻松完成需求。**没有了复杂的 ETL 过程，大大简化了开发流程。**\n\n**对于业务数据， LiveMe 使用 AWS SQS 消息队列**，相比 Kafka 的优势在于每条数据都是原子性的，每条数据都可以用来做幂等重试，来保证数据的最终一致性。目前，这套技术方案已经支撑了 LiveMe 的活动运营和金融风控等多个业务场景，满足了 LiveMe 对于线上大量数据实时聚合查询的要求。\n\n\n\n## 如何使用 TiDB 简化技术架构\n\nLiveMe 有一个类似朋友圈功能的场景，这个业务中存在两个技术难点：**第一是对于数据的无限量增长存储如何实现扩容；第二是数据的冷热分离，这又涉及到数据成本的问题。**\n\n以用户发 Twitter 的场景举例：如果用户发了一条 Twitter，它会写入到自己所有的关注列表，比如有 100 个粉丝，就写入 100 条，如果有 10 万粉丝就需要写入 10 万条数据，这是一个典型的写扩散场景。这个场景带来的效果是数据爆炸半径非常大，如果某流量网红发一条 Twitter ，数据写入量会非常大，因此需要一个能够接近于无限扩容的存储机制才可以实现这个场景。\n\n\n\nTwitter 的技术实现\n\nTwitter 是通过维护一个 redis-cluster 来解决 feed 分发的存储。LiveMe 的技术团队也想到使用这种技术架构，技术团队经过选型考虑使用 codis 集群来做存储，但通过对成本的考量，认为这个方案是不可行的，大量的 feed 冷数据存储在 codis 这样的内存密集型数据库中，成本非常高。因此，技术团队面临的挑战是如何用低成本的方式去实现一个写扩散的场景。\n\n\n\nTwitter 的解决方案\n\n基于 TiDB 解决方案，LiveMe 技术团队在上述写扩散场景中，把扩散写入的部分替换成了 TiDB，使用一张数据库表来存储所有 feed 的写入关系，比如用户有 100 万粉丝，就在数据库里插入 100 万条数据。**基于 TiDB 的分布式数据库特性，帮助 LiveMe 简单高效地解决了数据增长扩容问题。**\n\n基于此技术架构，技术团队简化了一个典型的 redis 缓存设计问题，热数据放在 redis 中，用 mget 来获取。冷数据放在 TiDB 中，用 select in 查询，这样做数据冷热区分就非常容易，甚至可以实现一个简单的布隆过滤器来了解哪些数据在热数据，哪些数据在冷数据里。以此减少无效数据的回源，更高效获取数据。\n\nLiveMe 的朋友圈功能基于 TiDB 的分布式存储特性进行技术改造后，**feed 表从 2021 年中旬上线至今已经达到数十亿数据写入**，现在的数据量单表 39 亿条。因为这些数据是永久保留不会删除的，所以该数据也会一直增长。\n\n## 未来规划\n\n未来， LiveMe 将会继续尝试 TiDB 在更多业务中，一方面会做数据库管理开发；另一方面将对于强事务依赖交易型的业务尝试使用 TiDB，为直播电商场景做技术储备。","author":"张龙","category":4,"customUrl":"tidb-in-liveme","fillInMethod":"writeDirectly","id":449,"summary":"LiveMe 是一个全球直播和社交平台，目前已在全球积累了超过 1 亿用户和超过 300 万的主播，面临新的业务挑战，LiveMe 经过一系列技术选型后最终选择了 TiDB 数据库。","tags":["TiDB","技术出海"],"title":"LiveMe x TiDB丨单表数据量 39 亿条，简化架构新体验"}},{"relatedBlog":{"body":"本文讨论了金融科技（Fintech）行业在数据基础设施建设上所面临的挑战，以及 TiDB 数据库在解决这些挑战方面的天然优势。TiDB 的 HTAP 架构和强大的水平扩展能力，为 Fintech 甚至是 Web3 的企业提供了重要的业务价值。本文将探讨 TiDB 如何应对 Fintech 行业的痛点，以及它为这些企业带来的实际价值。\n\n## 背景\n\nFintech 是金融（Finance）和技术（Technology）两个词的结合，主要指能够撕裂传统金融服务方式的高新技术。Fintech 涵盖了大量的细分行业，除了日常生活中经常接触到的移动支付和互联网银行，还包括像区块链、Web3 和 NFT 等新兴细分行业。\n\n\n\nFintech 行业的快速发展提出了一些业务需求。首先，Fintech 是全球经济中规模最大、增长最快的业务之一。其次，新冠疫情加速了整个金融科技的发展趋势，例如非接触支付、在线支付、保险和数字金融等服务的需求急剧增加。此外，由于其行业特性，Fintech 对数据的一致性和服务的可靠性、数据的安全合规以及监管等都有严格要求。因此，在选择相关解决方案时，通常会保持非常谨慎的态度。\n\n除此之外，Fintech 以客户为中心，需要对客户行为进行实时数据洞察，以更好地了解客户行为，量身定制转型、实现个性化营销和为用户提供增值服务。\n\n最后，在 Fintech 这样高度创新的技术背景下，通常在策略调整和产品方向选择上非常灵活、快速。因此，相较于传统金融企业，Fintech 更加敏捷，相关产品推向市场的时间更短。\n\n## Fintech 行业面临的技术挑战\n\n随着金融科技行业持续发展，对技术领域也提出了更多挑战，落在数据库方面，当相关数据量或整个业务请求量达到单机限制时，整个数据基础设施建设就会变得非常复杂。基础设施复杂化会带来以下问题：\n\n- 首先，很难在关键核心 OLTP 联机交易场景下，同时保证数据一致性及可靠性；\n- 数据架构复杂化会导致数据处理链路和时效性出现相对较差的情况，从而使大规模实时洞察变得非常困难；\n- 再者，为了适应基础设施的复杂性，前端业务开发需要不断使用更多的技术栈，并让应用程序依托于多种技术栈来支撑业务访问，这会拉长业务开发时间并使应用程序开发更为复杂，从而导致上市时间变慢；\n- 最后，为管理财务数据，还需要满足严格的监管和合规要求。\n\nTiDB 作为企业级分布式数据库，其拥有的天然优势，可以很好地解决 Fintech 行业所面临的痛点。它的 HTAP 架构设计和出色的水平扩展能力，对于 Fintech 甚至是 Web3 的企业来说，都具有非常重要的业务价值。\n\nTiDB 的架构设计非常简洁，在一套架构中同时提供了行存和列存两种存储引擎，并统一了 SQL 入口，简化了整个数据处理链路。这种设计进一步提高了 Fintech 业务的开发敏捷性，无需了解底层数据分布或数据管理这样复杂的工作，只需要通过标准的 SQL 完成业务代码的开发，加速了整个产品的持续迭代能力和速度。\n\n此外，面对越来越大的数据量，TiDB 拥有良好的水平扩展能力，可以自动实现各个集群节点之间的均衡，针对 Fintech 行业的数据业务增量提供了很好的支持，可以促进整个 Fintech 行业的业务发展。同时，它核心的事务特性、高可用性和可靠性也为 Fintech 业务的发展提供了很好的保障。除此之外，TiFlash 这种列存、MPP 并行处理加速的框架设计，也能够帮助 Fintech 相关场景基于实时数据为其用户提供及时的业务决策或增值服务。\n\n## TiDB 在 Fintech 行业的应用和实践\n\n\n\nTiDB 作为一款高效稳定的开源数据库，在国内外的银行、证券、保险，以及在线支付、金融科技等行业中都得到了非常普遍的应用。它的应用场景非常丰富，包括核心的交易支付、交易支付相关的查询、在线数据服务，以及实时风控、反洗钱、反欺诈、财务对账、清结算等。下面通过四个典型场景案例，来进一步介绍 TiDB 对 Fintech 场景提供的业务价值。\n\n### 在线数据服务\n\n在线数据服务是 Web3 行业中的典型业务场景。以 Web3 在线数据服务为例，相关业务发展带来了对应的业务挑战。首先是这个行业存在大量的数据倾斜，这与其本身的数据特征相关，这使得水平和垂直分片变得非常困难。此外，像 NFT 这样的在线数据服务场景下，需要高实时、高并发和高吞吐的业务请求响应。同时，它对延时的敏感性也很高，且非常注重用户体验。\n\n以以太坊为例，其数据量已经超过 10TB，每天还以 100 万笔交易的速度在不断增加。因此，对整个 Scale 的要求也非常高。在整个查询行为上，查询类型非常多样且复杂，包括简单的数据过滤、索引查询，以及聚合类查询和多表场景。同时，因为是一个在线的数据服务，其对实时数据分析也有一定的需求，要求系统提供 7×24 小时在线服务。\n\n针对在线数据服务的业务需求，需要数据库具备实时获取数据的能力，满足低延时的诉求，同时要求数据库具有高可用性。在传统解决方案中，数据处理的链路非常长，数据需要经过前端业务存储到关系型数据库，再进行 ETL 存储，最终放到数据服务层，向业务方提供查询。这种传统解决方案架构非常复杂，损失了数据时效性，并且在高并发访问、表关联等方面也存在缺陷。\n\nTiDB 的特性可以很好地解决在线数据服务所面临的这些挑战。一方面，TiDB 的扩展能力非常强大，计算节点和存储节点都可以进行动态扩缩容，能够应对高吞吐、高并发场景。另一方面，TiDB 高可用的架构设计能够最大程度保证前端业务访问的连续性。此外，HTAP 的能力可以在简化技术栈的同时保证数据的新鲜度，使得前端业务在使用 TiDB 时，整个业务数据的新鲜度非常高。\n\n\n\nNFTScan 是一家多链 NFT 数据基础设施服务商，为 Web3 用户提供高效简洁的 NFT 资产搜索查询服务，为 Web3 开发者和新一代金融科技公司提供专业的 NFT API 数据服务。NFTScan 使用了全托管 TiDB Cloud ，满足其 Web3 行业的场景需求。在使用 TiDB Cloud 前，NFTScan 的 NFT 数据链路是从链上获取数据，然后对数据进行过滤，并将 NFT 相关的数据分别存储到 RDS 和 ES 中。这两种数据存储产品分别用于提供 C 端、B 端以及内部运营分析等三类业务查询。使用 TiDB Cloud 后，在数据存储这一侧只存储了一份数据，即全部数据都存储在 TiDB 集群中。这意味着，NFTScan 通过 TiDB Cloud 简化了整个技术栈。在进行业务开发迭代时，不需要同时适配 RDS 和 ES，也不需要了解这两种数据存储产品。相应的业务开发只需要通过一种标准的 SQL 语句就可以完成业务迭代。因此，用户在业务的敏捷性和迭代速度上得到了进一步提高。\n\n另外， TiDB Cloud 在高可用方面，天然支持跨 AZ 部署，能够提供跨 AZ 高可用的能力。在云上的场景下，计算和存储节点可以按需扩容，这能够进一步支持客户的业务增长。目前，NFTScan 使用 TiDB 存储了大约 6TB 的业务数据，QPS 达到 5000，平均查询时长 40ms，各种应用在 TiDB 上运行稳定。\n\n### 多源汇聚+实时对账\n\n目前整个金融科技行业正在向单元化和服务化方向发展。因此，业务数据会根据不同的业务属性进行拆分，这意味着数据是分散且成熟的。为了实时查询和分析这些数据，可以使用 TiDB 作为多源汇聚层，支持对账、收益分配、损益展示等业务。\n\n\n\nTiDB 高度兼容 MySQL 生态，官方提供了数据库管理工具 DM，用户可以使用它完成整个上游到下游 TiDB 数据的实时同步。除此之外，TiDB 也提供了多种数据接入方式，可以将上游业务数据（如客户中心、产品中心等）以统一全局维度 1：1 进行入库。同时，如果上游已进行分库分表，TiDB 也可以使用 DM 完成合库合表的操作，将分散的数据在 TiDB 汇聚成一个全局的汇聚库。\n\n在多源汇聚的场景中，TiDB 对汇聚查询也有着天然的优势，用户不需要接入新的技术栈，只需要保持 SQL 技术栈就可以完成复杂的任意维度的分析查询 。这意味着 TiDB 可以在汇聚库上完成跨服务单元的后台数据批量操作，包括复杂的查询和报表类查询。同时，在整个业务中，原来共享的库仍然是以逻辑单独库的形式存在于 TiDB 的大集群中，提供服务。由于存储规模天花板相对较高，TiDB 的存储和计算能够通过不断加入节点进行横向扩容。\n\n在实时数据汇聚场景下，TiDB 有一个 Web3 用户案例。该用户在使用 TiDB 前，由于其业务特性要求，数据分散存储在 RDS 上。随着需求增长，用户需要提供 toC 类的损益分析、查询和内部运营分析。因此，客户使用 TiDB 的 DM 产品通过解析 Binlog，实时将上游业务库的数据汇聚到一套 TiDB 集群中。随着业务规模的不断增长，该集群最终规划的集群大小达 100TB。此外，TiDB 还能够同时支持 C 端和运营分析类查询，保证了数据服务的全面性。整个数据的时效性和新鲜度也非常高，无论是 C 端用户还是内部运营分析人员，看到的数据都是实时展示的。\n\n### 核心支付\n\n在第三个场景中，TiDB 主要涉及支付领域，例如商业银行的联机交易和第三方支付公司的移动支付等核心业务系统。通过使用 TiDB，可以为用户提供大规模吞吐量、高并发联机交易、多中心、多数据容灾以及弹性扩展机制。此场景的特点在于对安全性、稳定性和可靠性的高要求，需要提供分布式计算、分布式数据库管理和在线扩展的能力，并具备高并发、低延迟和大吞吐量的数据处理能力。由于它是一种类似于联机交易的支付场景，因此对整个事务的要求和数据一致性要求也非常高。\n\n传统方案中，为了解决业务需求，通常会采用分库分表架构。然而，传统 MySQL 分库分表架构也存在一些问题。分布式中间件对应用程序的侵入度较高，这意味着整个应用需要进行较大的改造和调整，相对来说比较复杂。一旦采用分库分表架构，应用模型和数据模型都会变得相对固定，从而牺牲了灵活性。由于支付场景对事务的要求很高，而引入分片这样的中间件解决方案在分布式事务方面的能力相对较低，需要在应用开发方面进行调整和适配。此外，采用分库分表后系统的弹性扩展和在线扩展能力也必然会受到限制，主从模式的高可用架构存在风险。在业务高峰期，无法完全避免主从之间数据同步的延迟。一旦数据库出现延迟，整个高可用架构和容灾能力都会下降。\n\n\n\n面对这些问题，通过 HTAP 数据库 TiDB 可以迎刃而解：\n\n首先，TiDB 的使用方式近似于传统单机数据库的访问方式，对整个应用的访问是透明的，无论是应用模型、数据模型还是整个事务的交易模型，无需人为切割。在整个核心交易支付场景中，也无需指定 Sharding key，不会限制后续数据查询的灵活度。\n\n同时，TiDB 的多中心多活容灾机制能简化整个部署的复杂性，无需管理十几套甚至数十套主从模式的集群。它完整地支持了整个分布式联机交易的事务，无需应用提前规避和处理。\n\n此外，TiDB 还提供了一个动态调度机制，使在线扩容节点时完全不会影响业务，后台会自动进行数据均衡。\n\n在该场景中，有一个日本顶尖的支付应用公司将 TiDB 应用在核心支付场景的案例。该客户在 2019 年 10 月上线了第一个 TiDB 集群。截至目前，客户的 TiDB 集群主要应用于支付和钱包等核心业务，涵盖支付查询、支付流水管理、钱包余额和钱包返现等功能。\n\n在使用 TiDB 之前，该用户的架构基本上是使用主从模式的 RDS。这使得其无法随着业务增长在容量和吞吐量方面得到很好的支持。此外，该移动支付客户还需要应对一些大促销带来的动态扩展需求。在这样的核心场景下，不希望出现主从同步延迟和高可用性降级问题。为解决这些问题，客户考虑到 TiDB 首先是兼容 MySQL 的，因此相对于业务改造和迁移，工作量较低。此外，随着数据量的大幅增长，不需要采用分库分表方案，应用逻辑相对简单，且读写均能水平扩展。\n\n在同类业务场景中，TiDB 有许多成功案例。考虑到这一点，该用户决定将支付核心业务迁移到 TiDB 集群。结果显示，在迁移后，整个系统的吞吐量提升了三倍。\n\n### 实时风控\n\n最后一个场景是实时风控，它在金融科技行业中扮演着重要的角色。实时风控需要整合各种业务提供的能力，包括征信、额度和反欺诈等，以提供企业级的统一风控入口。随着业务的发展，实时风控的要求也不断提高。例如，针对关键应用数据，需要同时具备实时数据分析的能力，以对交易流水、反欺诈和决策分析等实时数据进行批量处理。\n\n在过去，实时风控在数据链路处理这一侧的链路相对较长，涉及到的数据库品类也非常多，限制了其扩展能力。此外，无论是在数据链路还是数据服务这一侧，都存在限制。在数据链路这一侧，由于链路较长，数据处理变得复杂。在数据服务这一侧，数据被存放在多个地方，因此在灵活性和扩展性方面做出了一定的牺牲。在实时风控的场景下，通过将 TiDB 与传统的大数据生态技术栈（如 Flink 和 Kafka）结合使用，可以显著提高数据价值获取的能力，不管是作为单独的实时数据分析处理引擎，还是传统的大数据技术栈，这也意味着整个数据链路处理侧相对简单。通过流式的方式实时接入客户行为和反欺诈等数据，然后利用 TiDB 的 HTAP 能力进行实时的数据分析聚合。最终提供统一的 API 支持高并发查询的能力。\n\n\n\n在这个场景中，典型的客户案例是互联网银行。在使用 TiDB 之前，互联网银行客户面临了许多问题。他们的数据分散在不同的数据库中。为了处理风控指标，需要查询不同的数据源，然后进行汇总处理。但随着业务增长和需求变化，原先的技术栈 MySQL 出现了性能瓶颈。此外，MySQL 在实时分析场景的性能相对较差。基于这些考虑，客户在在线风控场景下使用 TiDB 替换原有技术栈。使用 TiDB 后，整个技术架构发生了变化。业务前端的数据，包括交易、用户行为、征信和身份认证等数据，通过 CDC 实时同步到 TiDB 集群中，大数据相关的风控指标则通过 ETL 进行抽取。最终，通过实时获取和分析，使用统一的 TiDB 数据库完成了在线风控和反欺诈业务流程。\n\n## 总结\n\n本文主要介绍了 TiDB 在在线事务处理（OLTP）场景、实时数据聚合和分析场景下的解决方案。除了在 Fintech 行业得到广泛应用外，TiDB 所具备的能力和价值也在许多互联网客户中也得到了应用。目前，全球已经有近 3000 家企业客户使用 TiDB，覆盖了电商、智能制造、物流和游戏等领域。\n\n\n\n\n","author":"高振娇","category":1,"customUrl":"building-a-new-generation-data-service-platform-for-fintech","fillInMethod":"writeDirectly","id":474,"summary":"本文讨论了金融科技（Fintech）行业在数据基础设施建设上所面临的挑战，以及 TiDB 数据库在解决这些挑战方面的天然优势。","tags":["TiDB","Fintech"],"title":"方案精讲丨TiDB 助力 Fintech 构建新一代数据服务平台"}},{"relatedBlog":{"body":"## 导读\n\n跨境电商进入多模式并行阶段，海量数据增长下，数据技术栈面临重重考验，实时、全量兼得至关重要。\n\n在跨境电商领域中，TiDB 得到了广泛的应用。本文作者李坤，PingCAP 中国出海事业部技术总监，分析了电商出海的现状与挑战，同时介绍了 TiDB 的产品能力，并结合实际案例介绍了对应的解决方案。\n\n## 背景\n\n近年来，随着国内电商行业发展见顶和国家政策的支持，出海电商成为一个快速发展的行业，2021 年虽然跨境电商经历了各类风险考验，但是在这些重重考验下我国跨境电商出口额达 1.44 万亿元，同比增长 24.5%，仍处于高速发展区间，显示出了我国出海电商发展的韧性和强大的动能。\n\n在独立站、直播短视频、社交媒体的带动下，跨境电商 DTC 模式出现爆发式增长，为出海企业创造了全新链路，跨境电商进入多模式并行阶段，同时形成全新的跨境电商产业生态。\n\n## 现状与挑战 \n\n跨境电商企业在业务扩张时通常会遇到海量数据增长的数据存储问题，技术栈也随之越来越复杂，包含数据库、ETL、分析引擎等；同时，出海业务通常分布在多个地区或国家，因此普遍比较青睐公有云、多云部署，以及全球部署；相较国内，由于能提供更高的效率，出海企业对 SaaS 服务的接受度也比较高。\n\n在出海过程中，每个企业都会有对自身业务增长的预期，通常会从两方面考虑：第一，随着业务的增长，希望可以实现数据平滑扩展。数据库都是以单节点的（DBMS）为主要基础，常见的限制是当数据量增长达到容量瓶颈时，性能便会出现急剧下降；第二，随着业务的增长，希望可以持续进行数据分析。尤其是在电商行业，数据分析作用非常突出。虽然以数据湖和数仓为代表的技术栈可以承担更大数据量，但处理数据的延迟将其功能限制在离线分析，而无法用于实时分析场景。\n\nTiDB 的定位恰好可以帮助企业跨越上述数据鸿沟。TiDB 是一个高度兼容 MySQL 的分布式数据库产品。在架构上，TiDB 采用了计算存储分离的典型架构，它为 TiDB 的长期演进带来了很多好处，如 serverless 架构演进，更好的资源管控等等。在计算部分，TiDB 提供了一个 SQL 的统一入口，它是无状态的服务，可以随时在线扩展；存储部分通过 Raft 使用通用型硬件实现多台节点横向部署，可以跨多节点实现高可用。当数据规模增长时，可以通过增加节点来扩展性能。用户不需要对表提前进行分区设计的划分，一切由 TiDB 内部独立完成。\n\nTiDB 存储部分包含 TiKV 和 TiFlash 两个存储引擎，这也是 TiDB HTAP 主要能力所在。TiKV 是行存引擎，可以承担在线交易型业务，同时把数据实时同步给列存 TiFlash。列存由于能够拿到实时数据，可以进行高速分析，例如重型查询、大表之间的 join 等操作。TiKV 与 TiFlash 之间实现了物理隔离，不会互相干扰。\n\n过去，当电商平台业务快速发展时，为了解决海量数据增长，通常需要分库分表，但这样会使业务逻辑变得更加复杂。为了提升读取性能，用户可能会选择增加只读节点，但写入能力仍然是单点。这时为了扩展性，有些业务就会选择 NoSQL，但这也意味着不得不放弃 SQL 和事务性。这些问题都可以使用新一代 HTAP 数据库 TiDB 来解决。 \n\n作为一款企业级数据库产品，TiDB 提供了多种部署形态。在云上提供了托管服务 TiDB Cloud ，用户可以从 Web 控制台一键部署，自助完成所有运维操作。同时，TiDB Cloud 还入驻了 AWS 和 GCP 的 marketplace；用户也可以私有部署，通过 TiDB Operaor 部署在 K8s 中。去年年底，PingCAP 发布了第一款 Serverless 架构的 HTAP 数据库 TiDB Cloud Serverless Tier 测试版，这是一个划时代的产品，它可以为所有开发者秒级提供一套 HTAP 数据库，根据真实的 workload 负载实现弹性扩缩容，帮助客户节省部署成本和服务成本。\n\n## 电商行业解决方案\n\nTiDB 可以结合标准的 SQL 入口以及弹性扩展能力、HTAP 一体化能力，向电商提供敏捷开发、持续交付的能力。下面通过面向商家、最终用户和运营分析几个维度介绍 TiDB 在电商业务中的主要应用场景：\n\n### 商品中心\n\n\n\n商品中心是电商平台提供服务的具体内容，大量商品和内容信息会在平台进行曝光展示，用户看到商品信息后产生消费意愿，最终完成下单。商品内容在电商整个业务链条中会被多次依赖，在特定的时间或者特定的活动下（如购物节），会产生爆发式的流量增长。此时，商品内容模块的流量可能达到平时数倍以上。所以，在面向 C 端平台的这些核心模块必须保证数据服务的可靠性及稳定性，通常对 SLA 的要求是非常高的，数据量也非常大。\n\nTiDB 基于原生的分布式架构，可以根据业务的实际情况灵活扩展计算及存储节点。同时，TiDB 也具有数据强一致性能力，可以做到故障自动恢复，为商品中心提供可靠的数据存储，应对大促带来的流量高峰。\n\n### 订单中心\n\n\n\n订单中心在电商交易的链路中扮演着一个非常重要的角色。它向上对接用户信息，将用户订单信息转化为订单数据，并且管理并追踪整个订单过程，是整个公司在线交易中不可或缺的一个环节。同时，订单中心还承接了其他系统的功能，如促销、仓储、会员和支付等，扮演着关键的承上启下的作用。\n\n订单中心对 SLA 有很高的要求，同时订单的数据规模非常大，订单状态还要保持持续跟踪，这就造成订单中心的吞吐量也相当大。\n\n与传统解决方案和基于 MySQL 的分布式解决方案相比，TiDB 在吞吐量、数据处理和查询能力、可扩展性等方面具有显著优势。过去，为了解决查询问题，传统解决方案必须扩展大量的读写节点，导致系统数据冗余，同时又只能扩展读能力，写能力无法得到扩展。而 TiDB 提供了一种高效的解决方案，可以同时扩展读写能力，是管理大量订单的最佳选择。\n\n### IM 场景\n\n\n\nIM 类型的场景在电商中也非常典型。其中一个显著的特点是数据量大，但往往 SQL 模型比较简单。过去有很多产品承载着 IM 这种系统，例如 HBase、Redis、MySQL 和 TiDB。HBase 存储成本很低，但作为一种老牌存储，其运维较为复杂且不太稳定。Redis 运维简单、灵活性好、性能非常好，但是对于一些消息来说，它无法持久化，存在丢失消息的风险。MySQL 使用 SQL 的成本较低，但由于其单机数据库的设计，其容量限制和吞吐能力受限，这导致业务在数据量变大时无法再扩展。\n\nTiDB 可以很好地解决这些问题。当然，这里也有一个缺点，即初期成本相比 Redis 和 MySQL 略高。除此之外，TiDB 也即将支持 TTL。老的 IM 数据可能会被归档，从而避免了归档后需要运维或业务手动删除的任务，节省了工作量。\n\n### 促销中心\n\n很多电商服务都是 SaaS 类的服务，第三方公司很难提前预见未来的促销活动何时发生。促销活动可能会导致整体负载的大幅变化。过去，TiDB 尽管已经具备弹性水平扩展的能力，但有时候还是会显得有些来不及。当 TiDB Cloud 提供了 Serverless 能力后发生了变化，电商企业可以根据实际负载情况，无需人为干预就能完成在线弹性扩缩容。这大大降低了用户的 TCO 和运维成本，使得 TiDB 在这个场景下具有非常优越的竞争力。 \n\n### 实时风控\n\n风控系统的职责之一是防止营销活动中的作弊行为，例如羊毛党、虚拟用户裂变、刷榜单等，甚至还包括一些内容违规情况。因此，过去的风控系统通常关注哪些用户在何时对什么商品或事情进行了什么操作。一般的实现方式是对业务订单、支付订单、抽奖活动、秒杀活动等系统的记录或日志进行收集、分析和处理。由于这些数据记录和数据源非常多，因此风控系统的数据量通常很大。在关键的操作前，业务会调用风控服务接口进行分析。数据的实时性越高，就越能及时感知到风险并处理掉风险问题或访问。因此，实时性对于风控系统非常重要。 \n\n\n\n借助 TiFlash 一体化的 HTAP 能力，TiDB 可以很好地处理需要实时性非常高的风控业务。与此同时，风控业务中也有一类负载比较重的 SQL 查询，但执行时间很难预测，这些查询可能是突发性流量或有周期性的，而不是持续存在的。如果计算资源始终按照最高需求或峰值提供，将会造成极大的浪费。因此，TiFlash 的 Serverless 可以很好地为这类负载降低总体拥有成本（TCO）。\n\n## 跨境电商行业解决方案\n\n除了传统经典的亚马逊、eBay 等老牌第三方电商平台，近年来，独立站逐渐在跨境电商中流行起来。其趋势正不断增长，其中包括 DTC 自建、SaaS 建站和开源建站等多种方式。\n\n提到独立站，就不得不提 SaaS 平台。SaaS 平台中有大量租户数据需要管理，这些数据要怎样才能更好地进行管理呢？通常这些数据需要满足以下需求：如隔离性，即多个租户之间的隔离；敏捷性，即数据需要能够快速创建；可扩展性，面对未来的业务增长需求，数据可以快速扩缩；性能方面希望每个租户都能够拥有比较隔离的资源，以避免邻居争用，也就是所谓的“吵闹的邻居”，这可能会导致性能争用等问题。另外，希望 SaaS 用户的数据能够合法合规，并且存储在他们所要求的地区内。\n\n\n\n过去常见的部署方式可能有以下几种：一、每个租户都有独立的数据库实例部署；二、将所有租户共享在一张表中。但这些方式有各自的优点和问题。例如，共享方式的隔离性较低，但独立实例的成本又相对较高。\n\n\n\n\n\nTiDB 可以通过一套集群解决以上问题：首先，TiDB 提供了 PlacementRule 特性，可以在不同的维度上为各个租户设置数据分布策略，以保证数据合规要求；第二，TiDB 提供并行 DDL，由于租户的数据可能经常调整，并行 DDL 可以直接从 TiDB 的小表缓存中查询，效率更高；第三，由于 TiDB 本身具有弹性扩展能力，无需为大型租户进行特别改造，保证小租户和大租户在整个业务逻辑上保持统一；第四，在 SaaS 的电商系统中，一定会有一些租户需要的资源相对较高，TiDB 可以自动将数据打散分布在所有的计算、存储节点上。\n\n## 应用案例\n\n### Shopee\n\nShopee 是东南亚领先的电商平台之一。目前在订单等核心子系统上都采用了 TiDB。在 2018 年引入 TiDB 之前，Shopee 面临着以下两个挑战：首先，自建的 MySQL 已成为严重的瓶颈；其次，虽然考虑过 MySQL 分库分表方案，但发现挑战非常大。基于上述问题，Shopee 团队开始寻找适合的技术方案。经过充分的技术调研和测试，TiDB 最终在 Shopee 内部被广泛使用。下面是两个典型场景： \n\n第一个场景是 Shopee 的 Chat 系统。2019 年，客户尝试将 Chat 从 MySQL 迁移到 TiDB，成功支撑了平台的大促。Chat 是聊天服务，如买家和卖家之间的问询等，该系统分为两个部分：MySQL 存放消息元数据，消息的内容存储在消息服务中，这部分使用了自研的文件系统。在迁移前，MySQL 的稳定性和运维性都面临挑战。\n\n消息服务是单点服务，其数据冗余和机制不健全，导致可能会丢失最近的聊天记录。Shopee 也考虑过持续使用 Redis，但其成本过高，也有丢失数据的风险。为满足业务要求，最终选择了 TiKV 集群，它可以保证业务在容量上在线扩展，从而保证高可用性。\n\n另外一个系统是 Shopee 的风控系统，最初他们将风控系统也放在 MySQL 上，并且按照 user ID 将数据分成上百张表。随着用户量的增长，在 2018 年的一次促销活动中订单量达到了前一年的 4.5 倍，所以数据体积开始疯狂增长，急需解决数据存储容量的问题，从长期考虑，Shopee 没考虑使用分库分表，切换到 TiDB 业务已经平稳运行了四年时间，在上线的早期阶段 6 个月内数据增长了 8 倍。\n\n### 小红书 \n\n小红书在业务快速发展的过程中，也同样希望保持数据的多样性、实时性与更强的扩展性。使用 TiDB 之前，他们在如实时数据视图、反欺诈分析和实时报表等业务中主要采用了 MySQL、Hadoop 和 Hive 的架构，并且使用了 MySQL 的分库分表。该架构的实时性比较差，很多数据要等到 T+1 才能获取，而且数据源也很多，这三个业务要分别访问不同的数据源，因此业务复杂度比较高。采用 TiDB 后，小红书将 T+1 的提交方式改为实时写入 TiDB 数据库，查询更加方便。此外，TiDB 作为数据服务层，通过 Flink 将其中聚合的结果再次返回 TiDB，最终结果可供业务直接在这一套系统上使用。这三个业务的数据源得以统一，业务的实时性从过去的 T+1 变成了实时，同时还简化了运维的复杂度和架构。\n\n### 转转\n\n转转是一家电商公司，在很多业务中也广泛使用 TiDB 系统，例如 IM 交易、用户和商品等。转转是一个重度使用 TiDB 的客户，可以从世界杯促销等方面看到他们对于数据容量的增长有着良好的承担能力。当然，在许多泛电商领域中，TiDB 也得到了广泛的应用。\n\n## 总结\n\n外贸数字化所导致的全球贸易新格局正在形成。在浪潮之下，已经有相当多的企业正在尝试拥抱于 此。跨境电商成为一个高速发展的行业，但快速增长的用户量与流量也对电商平台的技术架构带来 冲击，TiDB 新一代分布式数据库的水平扩展架构可轻松应对节日大促与秒杀带来的数据量激增问题。同时，作为一个开源数据库，TiDB 的系统和生态非常开放。它可以连接到各种应用程序和大数据生态系统，同时还可以与私有云、公有云集成。其 HTAP 一栈式实时数据分析能力，也让数据实时分析成为可能，帮助企业提升运营效率，赢得市场先机。","author":"李坤","category":1,"customUrl":"how-to-achieve-real-time-and-full-data-under-the-growth-of-mass-data","fillInMethod":"writeDirectly","id":477,"summary":"在跨境电商领域中，TiDB 得到了广泛的应用。本文分析了电商出海的现状与挑战，同时介绍了 TiDB 的产品能力，并结合实际案例介绍了对应的解决方案。","tags":["TiDB","技术出海"],"title":"方案精讲丨电商数据技术栈，在海量数据增长下如何实现实时与全量兼得？"}}]}}},
"staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}