{
"componentChunkName": "component---src-templates-blog-blog-detail-tsx",
"path": "/blog/tidb-in-liveme",
"result": {"pageContext":{"blog":{"id":"Blogs_449","title":"LiveMe x TiDB丨单表数据量 39 亿条，简化架构新体验","tags":["TiDB","技术出海"],"category":{"name":"案例实践"},"summary":"LiveMe 是一个全球直播和社交平台，目前已在全球积累了超过 1 亿用户和超过 300 万的主播，面临新的业务挑战，LiveMe 经过一系列技术选型后最终选择了 TiDB 数据库。","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，为直播电商场景做技术储备。","date":"2022-12-27","author":"张龙","fillInMethod":"writeDirectly","customUrl":"tidb-in-liveme","file":null,"relatedBlogs":[{"relatedBlog":{"body":"券商是一个古老的行业，发展至今已经历了三个时代：第一代券商为传统券商，在线下交易大厅进行买卖；第二代券商开始了电子化进程，从线下到线上进行了浅层服务的转移，改善了用户体验，提高了金融服务的效率；**第三代券商更多强调“科技赋能”，在功能业务上更创新、更多样，且存在完整的互联网基因，业务依靠线上平台，拥有底层自研能力，如交易、风控等系统。**\n\n老虎国际作为第三代券商的代表，是一家全球知名的国际化券商，在新加坡、美国、中国香港、澳大利亚等地持有 59 张牌照或资质，在全球多地开展业务。投资者在老虎国际可通过一个账户交易美股、港股、A 股（沪港通/深港通）、星股（新加坡股）、澳股（澳大利亚股）、期货、基金等全球主要市场的金融产品，享受一流的投资体验。\n\n老虎国际自主研发的交易平台 TigerTrade，累计交易规模在三年内突破 10000 亿人民币，创下互联网券商冲击万亿交易规模最短用时。2019 年 3 月，老虎国际在美国纳斯达克挂牌上市，目前拥有全球近 900 万用户，年交易规模超 2000 亿美元。\n\n## 业务挑战\n\n作为一家全球化的券商，每个国家证券行业发展情况不同，数据合规要求也存在差异，比如新加坡有 PDPA，欧盟有 GDPR，美国有 CCPA 等，甚至不同国家业务特点也大为迥异。**在每个国家/地区都本地部署业务系统显然并不现实，老虎国际采用跨地区的混合云架构为全球用户提供支撑，解决在数据架构、数据安全、数据合规等方面所面临的的全球挑战。**\n\n同时，老虎国际的数据架构复杂度非常高，底层系统包含 Java、Python、Go 等不同的语言，**中间件、数据库、大数据等都是异构场景，导致维护成本和研发效能都大打折扣。**\n\n此外，在老虎国际证券业务发展过程中，**业务波动性是常态**，这也使得其核心业务--后台账本系统，经常面临数据库的性能挑战。后台账本是用户在老虎国际参与证券交易时，如产品购买、出入金、IPO 打新、公司行动、被收费等各个业务版块，针对用户行为明细数据记录的系统。账本每天需要记录大量的用户流水，并根据用户行为生成用户每日账单。如果账本出现问题，直接关系到用户体验和投资收入。\n\n2020 年 3 月，美股遭遇了前所未有的震荡，开盘即暴跌，触发一级熔断机制，暂停交易 15 分钟。老虎国际的数据库也经历了前所未有的数据查询量，查询数量曲线呈指数级增长，原有的 MySQL 遇到了极大瓶颈。证券交易还要求数据库具有金融级数据强一致性，并具备灾备能力，一旦某个机房宕机，另一个机房可以立刻启用。\n\n**数据安全性、数据可用性和数据架构复杂度成为老虎国际国际化业务的三大挑战**。出于对开源技术的信任和认同，老虎国际很早就在数据中台业务中应用了 TiDB 3.0 版本，此后一路升级到 TiDB 5.0，解决了业务挑战与数据安全挑战。\n\n## 后台账本数据库迁移\n\n老虎国际的后台账本底层数据架构由多套集群组成，单集群数据量接近 2TB，MySQL 数据库虽然具有较好的稳定性和负载能力，但为了应对不断增长的数据量只能采取分库分表方案，难以保证跨分片的事务一致性，跨库的 Join 关联查询性能较差，数据库多次扩展难度和维护量极大。2021 年，老虎国际的运维与研发团队对主流的冷热数据分离、分库分表、分布式数据库等方案进行选型与性能压测。**在压测中，TiDB 在 P95 延迟、TPS 事务指标、QPS 等方面整体性能都强于 MySQL，并且 TiDB 的性能可以随着节点水平扩展线性提升，解决性能和单机资源瓶颈问题**。压测增强了老虎国际技术团队的信心，最终决定将后台账本的 MySQL 集群也迁移到分布式数据库 TiDB 上。\n\n\n\n\n\n**由于 TiDB 拥有非常丰富的生态组件，整个迁移过程十分顺利**。为了保障业务稳定，老虎国际采用了新旧数据库同时写入的方式，通过 DM 将 MySQL 数据同步至 TiDB 集群，逐渐切换一部分读流量到 TiDB，整个迁移历经近 3 个月，最终全部切换到 TiDB。同时，老虎国际也制定了“逃生方案”，通过 TiCDC 将数据同步到下游的一个 MySQL 集群，一旦发现 TiDB 有问题可以随时切换。在经过半年多业务的考验后，最终技术团队将该 MySQL 集群关闭。\n\n\n\n不同国家对于监管、数据可用性，以及 SLA（服务级别协议）要求非常高。**在同城，老虎国际还利用 TiDB 的灾备架构，通过 TiCDC 在灾备机房部署了一个 TiDB 集群作为灾备方案**，当主机房发生故障时，服务器负载均衡自动切换到备用机房，保证数据服务高可用，整体延迟达到分钟级甚至更低。\n\n## 为什么选择 TiDB？\n\n**对于券商而言，数据处理速度与成本是紧密相关的**。MySQL 的分库分表维护成本较高，对业务的限制也比较多。而 TiDB 的分布式架构无需分库分表，大大简化技术栈，降低了运维难度，通过在线水平扩展有效解决底层数据存储扩容难题；TiDB 的金融级高可用特性，可靠的灾备、数据恢复方案保障了老虎国际证券业务稳定运行；TiDB 高度兼容 MySQL，有着成熟的 MySQL 迁移方案，研发侧大部分代码无需改动，即可顺利完成整个迁移工作，大大降低迁移成本。\n\n## 业务收益\n\n现在，老虎国际的数据架构整体可以分为三部分：**第一，将分布在各业务系统甚至 APP 内的数据进行收集；第二，进行数据处理；第三，将数据持久化存储**。非敏感数据通过 DM 和 CDC 快速同步到 TiDB，敏感数据通过 Flink 进行脱敏后输入 TiDB，利用 TiDB HTAP 的能力构建数据中台和实时数仓，既保证 OLTP 查询时系统的稳定性，又保证 OLAP 的快速分析，两者同时存在又保证隔离，兼顾安全和稳定。最后，老虎国际还将 TiDB 作为类似数据湖的概念提供数据源给下游的 HDFS 使用，对外提供更多数据服务。\n\n\n\n过去，老虎国际的数仓只能满足 T+1 的数据分析，**通过 TiDB ，老虎国际实现了实时同步、实时分析**，将延迟降低到了 5 秒钟；同时，**TiDB 的性能实现了比较快的数据接入**，之前 Hbase 中只有 4,000+ 表，TiDB 目前已经达到 80,000+ 表；此外，使用 TiDB 后，老虎国际将数据的全量同步变成增量同步，**极大减少了网络带宽压力。TiDB 统一了两个大数据分析场景，提升了易用性，并节省了 40% 的资源，实现了降本增效**。","author":"PingCAP","category":4,"customUrl":"tiger-brokers-and-tidb","fillInMethod":"writeDirectly","id":441,"summary":"数据安全性、数据可用性和数据架构复杂度成为老虎国际国际化业务的三大挑战。出于对开源技术的信任和认同，老虎国际很早就在数据中台业务中应用了 TiDB 3.0 版本，此后一路升级到 TiDB 5.0，解决了业务挑战与数据安全挑战。","tags":["TiDB","技术出海"],"title":"案例故事丨老虎国际 x TiDB ，降低架构复杂性，保障全球用户安全可靠投资"}},{"relatedBlog":{"body":"制造业是一个古老而悠久的行业，它的起源最早可追溯到石器时代。从新石器时代简单的工具，到今天复杂的智能工厂，制造业历经千年发展，蜕变成了由技术驱动的创新行业，充满各种自动化流程、始终互连的设备和数据丰富的流程。\n\n本文将以数益工联数字化工厂为例，介绍“离散型”制造业面临的数据挑战，以及分布式 HTAP 数据库 TiDB 如何助力工业数据价值的挖掘。\n\n## “离散型”制造业面临数据挑战\n\n在制造业中，通常有着“流程型”和“离散型”两种区分。“流程型”是指被加工对象不间断地通过生产设备，通过一系列的加工装置使原材料进行化学或物理变化，最终得到产品。典型的流程生产制造业有医药、化工、石油化工、电力、钢铁制造、能源、水泥等领域。“离散型”制造，则是指材料的生产过程通常被分解为多项加工任务。典型的离散制造行业主要包括机械制造、电子电器、航空制造、汽车制造等行业。\n\n在整个离散制造业的现场有着太多的生产、物料、工艺以及人员数据。以前，离散制造业往往只能通过人工上报，手动填单等方式来进行数据收集。对于管理层而言，这些数据往往是不透明的、不准确的，或是滞后延迟的。**离散制造企业本身从业务到管理，都亟需通过数字化进行优化和提升。**\n\n## 如何解决“离散型”制造业的数据挑战？\n\n工业数字化软件供应商数益工联，致力于打造基于“数据流 + 价值流”的离散制造业数字化软件。数益工联团队以 IE+IT 为核心能力，实现产品和技术的双轮驱动，已在十多个行业落成全球领先的数字标杆工厂公司。公司至今已获得华创资本、高瓴创投、元生资本等知名机构的风险投资，累计融资额数亿元，在上海、苏州、广州三地设有子公司，打造跨区域全国服务平台。\n\n**数益工联数字工厂系统（DFS，Digital Factory System）应用新一代的物联网技术与丰富的现场交互手段，获取工厂现场最实时、最真实、最有效的数据**，不仅包含设备状态、设备异常数据、设备生产数据等设备 IOT 数据，还包含人员的交互使用数据，如计划报工、工艺、仓储物流、质检等核心生产管理业务的数据等。**对管理层而言，通过数益工联数字工厂系统，可以直观看到清晰、直接的报表，从中发现数据的价值，继而深入分析并采取行动，优化制造现场。**\n\n## 数益工联数字化工厂架构面临的挑战\n\n\n\n数益工联数字化工厂架构图\n \n从架构上看，数益工联数字化工厂主要分为四层：\n\n**第一层为物联层**，包括硬件和软件两部分。硬件主要为数益工联自研的智能终端，软件包括边缘应用和物联平台。其中应用主要具备设备参数的采集、人脸识别等功能，以上应用均运行于智能终端。物联平台则主要承担设备管理、配置和升级的相关工作。\n\n**第二层为应用层**，包括 IOT 数据服务、核心服务、低代码平台。IOT 数据服务是接受物联上报数据，计算设备开机率，异常等设备相关的服务，同时也是其他业务的数据源头；核心服务包括了计划报工、质量等数字化工厂服务；低代码平台主要包括了报表的可视化平台、流程编排等功能。\n\n**第三层为大数据层**，分成了大数据和算法两个部分。大数据应用包括了成本控制、APS、工艺大数据；算法包括了人脸识别、时序分析等算法。\n\n**第四层为基础架构层**，作为基础设施提供其他业务使用。主要包括了存储、数据库、中间件和云原生等部分。\n\n\n\n数字工厂的数据源头主要包括两部分：\n\n第一部分是 IOT 事件，包括了设备的开关机、物联采集、异常等数据，这部分数据通过 mqtt 上传到 IOT 服务进行处理，同时会推送到队列中，方便后续的计算和存储；\n\n另一部分是业务产生的数据，包括了计划报工、上下班等产生业务数据，主要通过 http 进行上传和展示。业务数据会直接存放到数据库中，同时将数据推送到队列中。\n\n数据存储主要采用了 TiDB 和 Starrocks 两个数据库，除了时序相关的数据，业务数据都存放在了 TiDB 中。\n\n**随着数益工联业务规模的不断增长，数据量变得愈发庞大，对于数据库的稳定性也提出了更高的要求**：\n\n1. 多数业务数据需要支持秒级延时，因此需要数据库具有很高的并发能力；随着业务的增长，数据量也会越来越大，需要数据库具有良好的拓展性；\n2. 随着数据量的增大，报表制作成本和难度变大，无法保证实时性。\n\n为解决业务系统的性能瓶颈，提高数据库的性能问题，数益工联选择了 TiDB 这一新型分布式数据库实现重构。\n\n\n\n数益工联研发团队在实践过程发现，TiDB 许多优势正好可以满足数益工联的需求：\n\n- **TiDB 兼容性强**，在实践的过程中几乎没有遇到过不兼容的问题，除了少数默认编码的问题。\n- **支持云原生部署**，可以通过 Kubernetes Operator 来快速部署 TiDB 集群，具有完善的配套监控功能。\n- **能够实现自动化水平扩容，支持高可用**，运维无需手动接入，极大地降低了运维成本。\n- **支持 OLAP**，TiDB 支持 TiFlash，降低部署复杂度，TiFlash 在亿级别数据的查询中，通常能达到 5 倍的加速。\n\n## TiDB 如何助力数益工联挖掘价值数据？\n\n那么，数益研发团队是如何使用 TiDB 实现对于工业数据的价值挖掘的？以工厂运转效率的重要指标设备开机率为例，对于工厂而言，设备的开机率与生产效率息息相关，能否实时获取开机率，机器是否实现了高效且合理的运转非常重要。数益工联团队通过 TiDB 实现了以下功能：\n\n\n\n- **开关机记录**：一条开机记录表示记录单个设备的一次开机时间和关机时间。这种记录表，由于数据量过大，现在主要放在 ES 中。\n- **开机率**：表示在一段时间内的开机时间的占比，延时需要精确到秒级，这种数据现在转换成时序的数据存放在 Starrocks，同时创建物化视图，加速时间跨度大的查询。\n\n但随着时间增长，团队也遇到了以下问题：一是开机记录和开机率数据不同源，导致数据容易不一致；二是 Starrocks 存储量大，占用了大量的计算和存储资源。\n\n因此，数益工联数据团队对于开机率进行了第三次改造：Starrocks 不再保存开机率的时序数据。时序数据量比较大，容易出现异常，导致数据不一致。**数益工联一方面将开机记录存放在 TiDB 中；另一方面通过开机记录来计算出开机率。**\n\n原先 ES 同步写入容易引发业务写入超时的问题，这次改造解决了 ES 数据写入延时的问题，同时，也减少了 Starrocks 的存储资源的占用。**这次改造使得在 100 台设备的应用场景中，一年能减少百 GB 级别的 Starrocks 存储；充分利用了 TiDB 的 HTAP 能力，通过 TiDB 的 HTAP 直接对开机记录进行聚合查询，降低了业务复杂度，给业务开发提供了很大的便利性**。目前，TiDB 在线上运行表现十分稳定。\n\n## 改造 TiFlash，实现 TiDB 物化功能\n\n与此同时，数益工联研发团队也在进行一些定制化的改造。由于业务需要支持任意时间段查询开机率的能力，因此需要按天对数据进行预聚合，但 TiDB 不支持物化能力，需要借助业务逻辑来实现，加大了业务实现复杂度。随**着业务预聚合的需求越来越多，数益工联研发团队决定对 TiFlash 进行改造，实现 TiDB 物化功能：**\n\n1. 根据物化语句生成物化表。\n2. 分区为粒度进行聚合，当数据到达一定时间的策略的时候，会把整个分区进行聚合，放到物化表分区中。\n3. 擎自动判断是否使用基表分区还是物化分区。\n4. iflash团队的交流中发现，需要解决重复计算的问题，因此数据需要多副本去重计算。\n\n\n\n目前，在数益初步的单副本测试中，虽然还存在一些问题需要修复，但能看到 TiFlash 的物化功能展现了很大的潜力，相信将在未来多业务场景下发挥重要作用。\n\n数据库在制造业中扮演着至关重要的角色，它们为工厂提供了强大的信息管理能力，帮助工厂更好地挖掘数据的价值。TiDB 可以帮助制造业处理海量数据，提供高效的查询性能，我们也期待帮助更多制造业用户完成数字化转型，从而提升企业的竞争力与效率。","author":"PingCAP","category":4,"customUrl":"how-to-use-htap-to-mine-industrial-data-value","fillInMethod":"writeDirectly","id":447,"summary":"本文将以数益工联数字化工厂为例，介绍“离散型”制造业面临的数据挑战，以及分布式 HTAP 数据库 TiDB 如何助力工业数据价值的挖掘。","tags":["HTAP","TiDB"],"title":"数益工联 x TiDB丨如何运用 HTAP 挖掘工业数据价值？"}},{"relatedBlog":{"body":"> 本文根据多点 Dmall 数据库团队负责人冯光普在 TUG 企业行成都站的分享整理而成，介绍了在数字化零售场景下，TiDB 在多点的使用情况、核心业务场景支撑、价值分析、及经验总结。\n\n## 一、Dmall OS 数字化零售方案\n\nDmall OS 是多点全渠道数字化零售方案，通过对零售场景中人、货、场全方位数字化解构+重构，赋能零售商和品牌商，帮助客户实现会员数字化、搭建线上线下一体化营销体系、实现门店作业在线化协同、以及智能供应链，助力商家降本、增效、提升客户体验。\n\n\n\n\n截止到 2021 年 6 月，Dmall OS 已助力物美，麦德龙，711，新百，中百，重百，锅圈食汇，DairyFarm，万宁等 120+ 国内外零售商，覆盖连锁商超、便利店、专营零售等业态；并基于全渠道零售数据为国内外知名品牌实现高速增长。\n\n\n\n\n## 二、TiDB 整体使用情况\n\n多点自 2019 年接触 TiDB，目前有超过 30 个 TiDB 集群，服务器节点超过 300 个，总数据量 320TB 以上，其中，最大的 TiDB 集群有 40 台服务器规模，数据量级 60TB，集群 QPS 峰值达到了 100K。\n\n- 2020 年开始调研并在非关键业务中试用，当时版本是 v3.1；\n\n- 2021 年正式跑通上线，在业财融合场景中落地，版本 v4.0.9，除 TiCDC 偶尔出问题，整体比较稳定；\n\n- 2022 年整体升级到 v5.1.4 后，TiCDC 稳定性问题也得到彻底解决，研发和 DBA 睡觉非常踏实；\n\nTiDB 大版本升级，使用 TiUP 仅一条命令即可完成，滚动的方式，过程中业务也很平滑，深得 DBA 喜爱\n\n\n\n\n\n当前各行业数字化转型，将领域对象、流程、场景数字化，实现实时在线、高效协同、智能决策，垂直领域的 SaaS 解决方案不断涌现，它们在助力企业降本增效的同时，在数据方面也面临以下技术挑战：\n\n1. **数据持续快速增长**，对于 MySQL 等开源单机数据库，达到容量上限需引入分库分表方案，比如 Sharding-JDBC，这类方案虽然逻辑上透明，但使用后 SQL 能力受限，实际很难执行跨节点 SQL；\n\n1. **实时商业洞察**，数据规模大且产生速度快，对 AP 也提出了挑战，T+1 的方式已经难以满足商业洞察和决策的需求了，比如：商家营销活动的执行效果分析，如果依赖 ETL 抽数+离线计算的技术方案，就无法在活动进行中及时优化营销策略，提升有限资源的回报率；\n\n1. **更低的成本**，不仅是资源层面的存储成本，计算成本，也包括架构及维护成本，弹性可扩展的云原生架构是未来的发展趋势；\n\n\n\n\n## 三、核心业务场景支撑\n\nTiDB 在多点 Dmall 的典型应用场景，简单归纳，主要有以下三类：\n\n1.**海量流水类存储**，使用 TiDB 直接替换了 MySQL，多并发批量写的方式，充分发挥 TiDB 高吞吐的优势，典型场景：App 推送记录，短信发送记录，单次营销活动产生的记录可达千万规模，从 MySQL 切换到 TiDB 后，DBA 就告别了容量焦虑，不用频繁归档历史数据，且 RocksDB 引擎相对 InnoDB 引擎有 3~10 的压缩优势，成本比使用 MySQL 更低；\n\n\n\n\n2.**冷热分离全量存储**，对于响应时间敏感，同时数据持续快速增长的在线业务，采用读写分离架构，将近期热数据存储在 MySQL，提供高并发低延迟的在线读写，同时实时同步到 TiDB，保存全量数据，提供历史快照查询及统计分析，支持业务数据变更溯源。典型场景：商品调价、库存变更，数据量超过了单机 MySQL 容量，且持续增长，基于自研的 DRC-TiDB 组件（它可过滤源端 MySQL 归档 DELETE 事件，同步 MySQL 数据到 TiDB），避免了数据增长超过 MySQL 单机容量后水平拆分的技术复杂度；\n\n\n\n\n3.**多源聚合存储及分析**，中台思想及微服务技术架构，实现了在业务域清晰划分下的技术能力复用，及研发高效分工协同，但也导致了数据散落到各个业务子系统中，全链路的业务聚合分析变得困难，在数据规模超过单机存储容量，且要求准实时性分析时，问题更甚。TiDB 透明的水平扩展能力，及 TiFlash 引擎 AP 能力，为这类场景提供了可行方案，典型场景：营销活动分析，聚合同步了多个在线 MySQL 业务库及 MQ 的数据，在 TiDB 中实时计算活动效果，助力运营评估和优化营销策略。\n\n\n\n\n## 四、TiDB 价值分析\n\n站在研发的视角，使用 TiDB 的好处：\n\n1. **更简单的架构**，TP 分库分表 + ETL 同步聚合 + AP 分析引擎，这种技术架构，除了技术复杂度、资源成本高、运维困难外，结构/数据一致性难以保证，ETL 同步延迟也是常态。TiDB 提供了另外一种可能：基于内建的 Raft learner 数据复制技术简化了架构，实现 TP 业务和 AP 业务基于同一份数据，避免了一致性和延迟问题。\n\n1. **实时数据分析能力**，基于 TiFlash 列存引擎，及 MPP 计算架构，实时业务数据集上的直接分析得以实现，得益于 TiKV 的水平扩展能力，上游数据的流入和存储几乎无限制，更多的数据，可放大实时数据分析的价值。\n\n1. **专注业务创新**，在充满不确定性的商业竞争中，为快速验证 MVP，业务早期存储选型采用简单易用的 MySQL，但在数据规模达到单机容量上限引入分库分表等技术后，业务研发就需要关注底层存储架构的约束和限制，开发效率降低；甚至权衡性能、稳定性、或成本被迫放弃部分需求特性，业务创新也受到影响，丢失早期竞争优势。TiDB 提供了另外一种可能：在业务进入快速增长阶段，底层存储的扩展对上层业务真正透明，让研发可以专注于业务创新和快速迭代。\n\n\n\n\n站在运维 DBA 视角，使用 TiDB 的好处：\n\n1. **云原生红利**，TiDB 符合云原生架构理念，不论计算层，还是存储层，加机器即扩容，可按需、弹性、近乎无限扩展，相较于 MySQL 分库分表方案的技术复杂、实施门槛高、SQL 能力受限，大规模快速增长数据场景下，运维 TiDB 幸福指数高于运维 MySQL；\n\n1. **MySQL生态友好**，TiDB 兼容 MySQL 协议，已建成的平台工具，可直接复用，比如：查询工具，慢 SQL 分析，监控指令等，DBA 可快速上手为研发提供数据库接入服务；\n\n1. **数据可靠性高**，MySQL 需要依赖外部 HA 组件实现故障切换，除部署配置复杂外，还难以彻底避免脑裂问题，TiDB 内部实现了基于 Raft 的数据同步和故障切换，failover 高效可靠，数据强一致保证，DBA 几乎没有心智负担；\n\n\n\n\n在成本方面，TiDB 一直有很多争议：1）组件多，有 PD、TiKV、TiDB 等；2）多副本+高可用，集群部署起步成本较高，会劝退很多用户。根据我们实际使用经验，成本方面的真实情况是：\n\n- 在数据规模较小，如在单机 MySQL 容量以内，主从两节点 MySQL 集群，成本是远低于 TiDB 集群的；\n\n- 当数据规模超过单机 MySQL 容量，需要引入 sharding 方案后，情况会发生变化，使用 TiDB 可能比使用 MySQL 更便宜，主要因为：\n\n- TiKV 的 RocksDB 引擎相对 InnoDB 引擎，有 3~10 倍压缩优势，存储相同规模数据，TiDB 的存储节点数远远低于 MySQL 集群；\n\n- 随着数据规模增长，只有 TiKV 节点数是随之增长，PD 节点的成本基本不增长，而 TiDB 节点数是与 QPS 相关；\n\n- 还需考虑引入 sharding 方案后，技术复杂度提升，SQL 能力受限，会带来运维成本的升高，以及开发效率的降低；\n\n\n\n\n## 五、实践经验及场景对比\n\n从使用 MySQL 切换到使用 TiDB，需要重点关注和理解分布式架构的优缺点，尤其是算存分离以及分布式事务带来的网络开销，局域网的网络交互延迟，与读写 SSD 的 IO 延迟在一个级别，它远远高于单机数据库进程内的数据交互，简单总结一下，结论：\n\n- TiDB 相比 MySQL 响应更慢；\n\n- TiDB 相比 MySQL 可输出吞吐更高；\n\n因此，建议采用多并发、批量读写的方式，以发挥 TiDB 的优势。\n\n\n\n\n下图是 MySQL 与 TiDB 的详细优劣势对比和选型参考，在数据规模小，要求低延迟的 TP 业务场景中，MySQL 更加合适，而在数据规模远超单机容量、持续快速增长、对响应延迟不那么敏感的 HTAP 业务场景中，使用 TiDB 更加合适。\n\n\n\n\n## 六、总结\n\n- TiDB 基于云原生理念，采用算存分离架构，可以按需、弹性、近乎无限的水平扩展；\n\n- 基于 TiDB 的 HTAP 能力，可实现同时支撑 TP 业务和 AP 业务的一体化架构，综合成本低；\n\n- TiDB 与 MySQL 相辅相成，生态友好，是优秀的面向数据快速增长的理想选择。\n\n> 延展阅读： \n[“新经济 DTC 转型背后的数据库”专题 ](https://pingcap.com/zh/events/database-behind-new-economy-digital-transformation) \n点击查看更多[新经济 DTC 转型案例实践](https://pingcap.com/zh/blog?tag=%E6%96%B0%E7%BB%8F%E6%B5%8E%20DTC%20%E8%BD%AC%E5%9E%8B)","author":"冯光普","category":4,"customUrl":"tidb-in-digital-retail-in-dmall","fillInMethod":"writeDirectly","id":403,"summary":"本文根据多点 Dmall 数据库团队负责人冯光普在 TUG 企业行成都站的分享整理而成，介绍了在数字化零售场景下，TiDB 在多点的使用情况、核心业务场景支撑、价值分析、及经验总结。","tags":["TiDB","新经济 DTC 转型"],"title":"TiDB 在多点数字化零售场景下的应用"}}]}}},
"staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}