{
"componentChunkName": "component---src-templates-blog-blog-detail-tsx",
"path": "/blog/tiger-brokers-and-tidb",
"result": {"pageContext":{"blog":{"id":"Blogs_441","title":"案例故事丨老虎国际 x TiDB ，降低架构复杂性，保障全球用户安全可靠投资","tags":["TiDB","技术出海"],"category":{"name":"案例实践"},"summary":"数据安全性、数据可用性和数据架构复杂度成为老虎国际国际化业务的三大挑战。出于对开源技术的信任和认同，老虎国际很早就在数据中台业务中应用了 TiDB 3.0 版本，此后一路升级到 TiDB 5.0，解决了业务挑战与数据安全挑战。","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% 的资源，实现了降本增效**。","date":"2022-12-09","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tiger-brokers-and-tidb","file":null,"relatedBlogs":[{"relatedBlog":{"body":"> **作者介绍** \n**陈培新**，参与国信证券基础平台研发工作（DevOps、微服务治理、Serverless）\n\n\n国信证券是一家全国性大型综合类证券公司，在 118 个城市和地区共设有 57 家分公司、185 家营业部，根据中证协发布的数据，近年来国信证券的总资产、净资产、净资本、营业收入、净利润等核心指标排名行业前列。\n\n国信证券从 2020 年 6 月开始接触 TiDB，从技术预研到第一个业务上线大约花了半年时间。第一个上线的业务是金太阳帐单，后面陆续在数据中台、服务观测等系统中应用。从只在东莞主机房的 TiDB 部署到 2021 年 9 月实现 TiDB 多机房的部署，并启动国产海光 x86 服务器的试点工作，国信证券在开源 NewSQL 数据库的探索和应用层面，积累了丰富的实践经验。目前，**国信证券共有 7 个 TiDB 集群，节点数量 109 个，最大表 100 亿，支撑了托管、经纪和自营等业务**。\n\n## 从 0 到 1，国信金太阳引入 TiDB\n\n身处互联网企业，大家可能跟富途牛牛接触的比较多。国信金太阳跟富途牛牛类似，它提供证券交易、理财和咨询相关的服务。我们使用证券软件最主要的功能就是交易，用户在做交易的时候，关注更多的是收益率以及什么时候去买卖股票，用户可以根据证券软件提供的功能对所有的交易做分析。国信金太阳的用户数大概有一千万左右，国信有一个大数据平台，存储了所有用户历年的交易数据，账单存量数据有一百多亿，清仓股票数据量大概是十亿，整个帐单和清仓股票增量数据大概是二十亿每年。\n\n下图是国信金太阳的数据服务架构。金太阳 App 直接连金太阳后端，后端架构基于国信自研的 gRPC 微服务框架构建。跟大多数券商系统一样，金太阳后端对接柜台系统，里面有交易、帐户、清算等各种后台应用。所有数据最后会推送到数据中心，数据中心每天或每周都会做跑批。跑批完之后，会将相关的数据推送到前端的数据库中，用户通过 App 端的查询服务来直接查询这个数据库，从而获取相关的帐单以及清仓股票的数据。\n\n\n\n图：国信金太阳数据服务架构\n\n整个账单经历了三个版本，账单 1.0 我们可以称它为**刀耕火种**的时代。在 1.0 版本的时候，只支持一年账单的查询，使用的是单库单表 SQL Server。具体是怎么实现的？首先，数据中心每天会将数据同步到一张临时表中，然后进行数据转换的服务，这个临时表的数据会加到正式表里面，正式表里面保存的是一年的数据量。在单库单表的情况下，通过一个中间程序将所有一年的数据都压缩到某一列里面去，里面是一个 JSON 字符串，存的是一年 365 天的数据。那如果新一天有新数据来了怎么办？这边会起一个临时任务，将新的一天推过来的数据压入到这个 JSON 里面去，再倒推 365 天，把以前最早那天的数据清除，最后再写到正式表里面去。可以看到，这其实是一个非常原始的实现。为什么要使用 JSON 这种格式？因为我们的数据用户量大概有一千多万，如果是每天存一行的话，用单库单表肯定是 hold 不住的。所以一开始，我们用了一个非常取巧的方式，将 360 多行给它并了一行，这样的话整个表的数据量将近有一千多万，查询效率还可以。\n\n\n\n图：账单 1.0 单库单表实现方式\n\n这种方式面临的问题是：业务上，用户是希望查询更长时间的数据，比如五年，使用单表的话，这一项其实是难以满足的。技术上，数据查询以及后续的更新压力大，难以扩展，有时候会出现数据更新出错，第二天用户来查询的时候，查到的数据就不准确了。\n\n为了应对这些业务和技术难点，国信在账单 2.0 版本使用 sharding-jdbc 来做分库分表。在引入这个技术的时候，我们也听说了 TiDB，考虑到**证券业务对稳定性要求较高**，当时对 TiDB 稳定性还有一定的担忧，所以选择了 sharding-jdbc。做了分库分表之后，可以支持 5 年帐单的查询，使用了 16 台 MySQL，总共分了 512 张表。数据中心与分库分表是如何进行同步的？数据中心还是和以前每天一样，先把数据写到临时表，转换服务会配置分库分表的规则，从临时表里面取数据，最后写到正式表里面。数据中心有个 ETL 工具，它不支持扩展，所以就没有直接写入到正式表。\n\n\n\n图：账单 2.0 分库分表实现方式\n\n大概跑了两年时间，我们发现了新问题，分库分表虽然可以满足业务需求，但后续在扩展性方面有很大的约束，这些约束包括：第一，字段扩展困难，我们分了 512 张表，如果要有新业务上来，需要新增一个字段，这个时候 DBA 就会很痛苦，需要到每个分表新增字段。第二，扩容极其麻烦，数据一开始预估不准确的话，后面分库分表的规则就一定要变，从一开始 512 张表要变到再乘以 2，变到一千多张表，DBA 迁移的工作非常繁杂，而且很容易出错。第三，同步还需要中间表，所以数据同步的时间也还是一样的慢，并且制约系统上线时间。第四，分表的定时创建跟清理也比较繁琐，每天会将一些日表删掉，比如五年前的表，然后还要去创建第二天的表，在开发的时候，始终是要使用这个定时器来做清理和创建。第五，运维方面，也要运维多个数据库。\n\n到了账单 3.0 的时候，公司的开发和运维方提出了需求，分库分表虽然可以搞定，但是太麻烦了。借这个机会，我们把 TiDB 引入到国信证券里面来，使用 NewSQL 数据库来支持 5 年账单查询。数据中心就直接将数据每天直接推到正式表里面，查询服务方面就是直接去查询 TiDB，在 TiDB 之上加了缓存，**每天同步入库的效率较以前提升了大概 70% 左右**。当前 TiDB 已经在国信三地机房里面做了部署，同时在东莞机房最近也在做国产海光 x86 服务器的试点。\n\n\n\n图：账单 3.0 TiDB 分布式数据库实现方式\n\n接下来谈谈一年多来 TiDB 相关的使用心得。从开发角度来看，首先是大数据量删除，一开始没有经验，还是按照以前老的套路，比如要删除指定某一天的数据，直接就是 DELETE SQL WHERE = “某一天”，当时是周六，运维告警显示 TiDB 有很多台机器逐个地挂掉，后来找排查发现 DELETE SQL 太大了，后续把事务大小调到 10 G，扩展 TiDB 机器内存到 64 G，这部分是满足系统层面的扩展。另外一方面是在应用程序侧做改造，需要去做分批的删除，可考虑使用 Range 分区表，删除数据直接 truncate 或 drop 分区即可。\n\n第二个经验是对新上 TiDB 的业务，尽量要使用 AUTO-RANDOM 作为主键，对那种持续插入、大量插入，很大情况下可以避免插入的热点。对于多机房数据同步，TiDB 是需要主键或者唯一索引，无主键或者唯一索引会造成同步 OOM。在表已有大量数据的时候，如果要加这个主键，整个过程也会比较麻烦。\n\n## 三地高可用容灾架构的实现\n\n一开始只在国信东莞主机房作为试点去做 TiDB 的部署，后续运维要求 TiDB 要做容灾部署相关的工作，应用要实现三地的高可用多活。之前每个机房的应用是访问自己本地的 TiDB ，每个季度会做灾备演练，验证东莞整个主机房故障之后，异地上海与同城福田灾备的可用性。\n\nPingCAP 的老师一开始给了三个方案。第一个方案是最简单直白的，在**三个机房都部署一套单独的 TiDB 集群**。东莞机房做读写，用 TiCDC 或者 binlog 将对应的数据同步到其他两个机房的灾备集群。这个方案的优点是比较简单，做灾备演练的时候，如果东莞主机房挂了，其他两个机房的应用基本上不用做什么操作，还是可以继续使用。这个方案存在问题是副本数比较大，需要有 9 个副本，同步的时延可能也会大一点。\n\n第二个方案是比较经典的**两地三中心**，这个方案对于网络的要求比较高，而且如果东莞机房挂了，福田机房要做一下手动恢复。第三个是**同城双中心**，把东莞跟福田当成一个集群，将数据同步到上海灾备集群，也就是两个集群。但这个方案在做灾备演练的时候做恢复也会比较复杂。\n\n\n\n图：多机房方案对比\n\n经过三个方案的对比，最后国信还是采用了最简单的 binlog 同步方案，每个机房部署一个 TiDB 集群，这也是根据业务特点来实现的。国信的业务基本上使用查询，不会存在多个机房同时写入，所以最后采用了这个最简单的方法。在多机房部署实现的过程中做了一些迁移导入的工作：一开始只有东莞机房，因为对于 TiDB 的使用不熟悉，有一些业务表是没有加主键或者没有唯一索引。福田机房搭建新的 TiDB 集群之后，我们发现在做两地集群同步的时候，同步器就直接 OOM 了，是因为没有加主键或唯一索引导致的。当时有一张最大的表已经到 60 多亿了，如果直接在表上加主键或者唯一索引的话其实是不可能的。\n\n那我们是怎么做到的呢？首先使用 Dumpling 将这个表导出到 CSV 文件，这个 CSV 文件的命名是带有表的名称的，在导出完成之后在原来的数据库上面去创建新表，里面加上主键或者唯一索引，再把导出的这两个 CSV 文件重命名跟新表一样，然后通过 Lightning 把数据导入到这个新的表里面，最后把旧表和新表给重命名，把这张新的表命名为正式表，正式表重命名为备份表，这样做的话可以尽量的减少对业务的影响，在导入导出的过程中，用户基本上是无感的。\n\n\n\n图：无主键表处理\n\n## 服务可观察的探索\n\n最后谈谈在金太阳**服务可观察方面**的探索。应用在使用了微服务架构之后，部署的节点会非常多，而且调用链整个过程也非常复杂，这个时候想定位一个问题就会很复杂，根据业界当前比较流行的 “服务可观察” 概念我们做了一个应用来辅助开发的问题定位。这个 “服务可观察应用” 主要是包含三个部分，一个是日志，第二个是指标，最后一个是跟踪链。我们针对日志部分做了增强，把系统的请求和响应日志通过 ETL 工具转换到 TiDB 里面，然后做了可视化相关的工作。\n\n\n\n图：金太阳服务的可观测性\n\n**可视化**部分是开发一直提的需求，采集了日志一般都是在 ELK 的 Kibana 里面看，都是一些文本，这是非常不直观的。我们做的优化是对于每个微服务的请求跟响应日志我们都导入到 TiDB 里面，用 “服务可观察” 应用去做展示。如果客户有什么问题，输入客户的手机号就可以很直观地看出这个客户在某个时间段做了什么操作，从而可以很快定位问题，同时我们也将内容和响应进行可视化，看起来更加方便。 \n\n当时在做 TiDB 入库也遇到一些问题，因为这个业务特点跟账单不一样，账单基本上都是每天晚上做插入，白天用户做查询操作。并且该业务在开市期间（上午九点到下午三点多）会做持续大量的插入，查询操作会比较小，有问题的时候才上去做查询。这是一个运维相关系统，所以没有用很好的磁盘，系统上线后就发现整个 TiDB 变得非常卡，一开始以为是插入的程序或者查询程序有问题，我们做了很多优化，发现还是不行，最后升级完磁盘之后发现整个性能获得了直接的提升。我们得到的经验就是上 TiDB 的话，一定要选择好的磁盘，这样才能确保处理效率。","author":"陈培新","category":4,"customUrl":"tidb-in-guosen-securities","fillInMethod":"writeDirectly","id":335,"summary":"本文讲述了 TiDB 在国信证券海量数据高并发场景中的实践。国信证券从 2020 年 6 月开始接触 TiDB，从技术预研到第一个业务上线大约花了半年时间。第一个上线的业务是金太阳帐单，后面陆续在数据中台、服务观测等系统中应用。","tags":["用户实践","高并发","服务可观察"],"title":"TiDB 在国信证券海量数据高并发场景中的实践"}},{"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 在多点数字化零售场景下的应用"}},{"relatedBlog":{"body":"> 本文由携程技术团队撰写，介绍了携程自研的国际业务动态实时标签处理平台。其中标签持久化的场景需要解决业务标签的持久化存储、更新、查询服务，TiDB 通过对于不同场景查询特性的支持满足了不同业务场景访问业务特征数据的需要。\n\n**作者介绍**\n\nWeiyi，携程资深数据开发，关注大数据相关技术，对大数据实时计算、流批一体等方面有浓厚兴趣；\n\nHzhou，携程资深数据开发，关注大数据相关技术，对系统架构和实时处理等方面有浓厚兴趣；\n\nRongjun，携程大数据架构开发，专注离线和实时大数据产品和技术。\n\n## 背景\n\n在国际业务上，因为面临的市场多，产品和业务复杂多样，投放渠道多，引流费用高，因此需要对业务和产品做更精细化的管理和优化，满足市场投放和运营的需要，降低成本，提升运营效率，提升转化率。为此我们提出研发携程国际业务动态实时标签处理平台（以下简称CDP），为 Trip 业务增长解决 “Grow Revenue” 和 “Reduce Costs” 的问题，具体如图 1-1。\n\n\n图 1-1 CDP 所需要解决的业务问题\n\n因为 Trip 数据来源比较广泛，既有自身数据也有外部数据；数据形式也非常多样化，既有结构化数据，也有半结构化和非结构化数据；数据加工形式既有离线数据处理，也有在线数据处理；如何通过系统加工这些数据形成业务系统、运营、市场需要并且可以理解的数据和标签，成为了 CDP 平台急需解决的业务和系统问题，简单总结下来系统主要需要解决以下四个方面的问题：\n\n### 数据采集与管理\n\n主要丰富不同的数据来源，包括三个部分。第一方数据，来自自己，UBT 日志，平台数据，客服处理数据，APP 安装数据。第二方数据，来自集团中的其他品牌的数据，如 SC、Travix 等。第三方数据，来自我们合作方的网站，比如 meta 投放平台等。\n\n### ID 匹配\n\n不同的数据源有不同的 ID 标签，比如 APP 端来源的数据会有一个统一的 ClientID 的主键，与之相关联的会有一组标签。来自不同业务系统的数据都会有对应的 ID 以及标签与之对应。这些标签主体的 ID 分别来源于不同的系统和平台。平台之间的 ID 有的相互之间可能没有关联关系，有的有一定的关联关系，但不是一一对应的，但是业务系统使用时往往是需要相互组合使用。因此需要有一个 ID 从数据采集到业务标签创建，到最终使用都能串联的一个唯一 ID。这个是最大的难点。如果没有，那我们需要一个非常完整的 ID Mapping，在不同的 ID 之间可以做转换，这样用户可以串联不同实体之间的标签。\n### 业务标签模型\n\n一些有场景决策使用的标签，比如市场最受欢迎产品，最热门旅游目的地等等。很多公司早期在做标签时什么都想要，铺了上百个统计类标签，然而这些标签并不能直接使用。而且将上百个标签砸向产品或运营人员的时候，因为没有重点，会一下将业务人员“砸晕”。所以能提供真正有效的标签很重要。在这个过程中对业务的理解就变得尤为重要，系统需要根据业务场景建立对应的业务标签模型。\n\n### 标签的使用\n\n和使用标签的系统做对接，比如消息系统，第三方平台，站内平台。让这些业务标签，最大化帮助业务产生业绩。其中的难点是，CDP 怎么和使用它的平台去做对接。\n\n要解决以上问题，系统必须提升数据处理能力，因为处理好的数据是需要立马运用到业务系统、EMD、PUSH 等等使用场景中去，**对数据处理系统的时效性、准确性、稳定性以及灵活性等提出了更高的要求**。\n\n在过去我们现有 CRM 数据是通过数仓 T+1 计算，导入到 ES 集群存储，前端通过传入查询条件，组装 ES 查询条件查询符合条件的数据。目前已经上线的标签有上百个，有查询使用的超过 50%，能满足一部分对数据时效性要求不高的标签数据筛选场景的需要，比如市场活动目标用户的选择。因为是离线计算，所以数据时效性差，依赖底层离线平台的计算，依赖 ES 的索引，查询响应速度比较慢。 \n\n基于以上这些问题，新系统希望在数据处理过程中能提升数据处理的时效性同时满足业务灵活性的要求，对于数据处理逻辑，数据更新逻辑，可以通过系统动态配置规则的方式来消费消息数据（Kafka 或者 QMQ）动态更新标签，业务层只需要关心数据筛选的逻辑，以及条件查询。\n\n## 二、系统设计\n\n基于业务需要，我们将业务数据标签筛选的场景分为两大类：\n\n- 实时触发场景\n\n根据业务需要，配置动态规则，实时订阅业务系统的变更消息，筛选出满足动态规则条件的数据，通过消息的方式推送到下游业务方。\n\n- 标签持久化场景\n\n将业务系统的实时业务变更消息按照业务需要加工成业务相关的特征数据持久化存储到存储引擎，业务根据需要组装查询条件查询引擎数据，主要是 OLAP（分析类）和 OLTP（在线查询）两大类查询。\n\n为了解决以上问题，我们设计开发了一套“实时动态标签处理系统”，业务方只需要按照基本算子规则配置提交任务，系统就会自动解释执行规则，按照配置要求执行数据处理操作，目前支持的基本算子有Stream（流式数据接入目前支持 QMQ 和 Kafka）、Priority（优先级判断）、Join、Filter（过滤）、Sink（数据输出，目前支持 TiDB、Redis、QMQ）等等，这些在整体设计里面会详细介绍，通过规则和动态计算的方式提升数据处理和开发效率，降低开发成本。 \n\n**流式数据采用类 Kappa 架构，标签持久化采用类 Lambda 架构**，系统架构如图 2-1。\n\n\n图 2-1 CDP 系统架构\n\n系统对公司内输出主要是对接站内的自运营渠道，比如消息系统，发送短信，邮箱，广告。站内主流程根据 CDP 的特征组装前端业务流程。\n\n## 三、实时触发\n\n针对动态触发的场景需要解决动态规则配置，规则解析，规则内动态计算节点（算子，之后都简称为算子）的生成，算子的相互依赖关系（DAG），以及数据 join 的处理。 \n\n为了解决实时流式数据处理，我们引入了类似于 Kappa 架构的数据处理方式，做了一些调整，采用主动 Push 方式，因为这个场景的数据主要是应用于 Push/EDM 等主动触达的场景，结果数据不需要落地，我们直接通过 QMQ 消息渠道推送到应用订阅的消息队列。 \n\n\n图3-1 Kappa 数据处理架构\n\n这样解决了消息时效性的问题，同时也解决了规则时效性的问题，修改规则不需要重启任务即可生效。计算结果采用主动推送的方式，省去了数据存储和查询的过程，提升了数据的时效性，节省了存储空间。 \n\n\n图 3-2 CDP 实时触发数据处理架构\n\n规则引擎设计采用Json格式传参，算子设计为两层，上层为固定业务逻辑支持的动态业务算子，主要包含 Stream、Priority、Join、Filter、Sink，下层为固定业务算子使用的一些基础算子，可以自由组合，以满足消息实时处理业务逻辑处理的需要。\n\n关于规则引擎所涉及的一些基本概念描述如下：\n- Stream\n\n消息源接入，主要是 Kafka 和 QMQ，结构化 Json 数据，所有的接入消息源的数据结构、数据类型、来源都需要录入管理，借用公司的 Kafka 和 QMQ 消息注册管理机制，实现全流程打通。\n\n- Priority\n\n优先级判断，比如主流程一般按照搜索页，列表页，填写页，支付页次序排列，因为流量是一层一层减少，所以越到后面流量越重要，在一些业务场景中需要根据这些流量的重要程度排序，优先级判断可以满足这些业务场景的需要。\n\n- Join\n\nJoin 算子，目前只支持使用 Redis 作为 Join 右表，如果 Join 条件不满足右表数据都为 NULL，默认输出左表数据，如果需要右表数据需要指定输出的字段。\n\n- Filter\n\n过滤算子，可以直接过滤上游数据，也可以过滤上游数据与 Redis Join 后的数据。只有通过的数据才会流入后面算子，否则该条数据处理结束。\n\n- Sink\n\n计算结果输出，支持配置化方式，目前支持消息队列模式（QMQ），数据库（TiDB、MySQL 等等）。\n\n- 基础算子\n\n基础的原子算子，不可再拆分，如 +、-、*、/、>、<、=、>=、<= 以及in，not in，like，rlike，IS_NULL，IS_NOT_NULL 等。\n自定义函数\n\n支持计算过程中使用自定义函数，用户可以自定义数据处理函数并注册到生产系统，目前支持的函数如下：\n字符串函数：CONCAT、CONCAT_WS、HASH、IFNULL、IS_NOT_BLANK、IS_NOT_NULL、IS_NULL、LIKE、LOWER、UPPER、REGEXP、REPLACE、SUBSTR、UPPER、URL_EXTRACT_PARAMETER等 \n\n时间函数：CURRENT_TIMESTAMP、FROM_UNIXTIME \n\nJSON 函数：JSON_EXTRACT \n\n- DAG\n\nDAG 是一种“图”，图计算模型的应用由来已久，早在上个世纪就被应用于数据库系统（Graph databases）的实现中。任何一个图都包含两种基本元素：节点（Vertex）和边（Edge），节点通常用于表示实体，而边则代表实体间的关系。 \n\n由于 DAG 计算是一套非常复杂的体系，我们主要借鉴了 Spark 的 DAG 计算思想，简化了 DAG 计算流程从而满足我们实时计算业务场景的需要，**在介绍 DAG 计算方式之前，先介绍一下 Spark 中 DAG 计算的基本思想和概念**。\n\n在 Spark 中 DAG 是分布式计算模型的抽象，专业术语称之为 Lineage —— 血统，RDD 通过 dependencies 和 compute 属性构成首尾相连的计算路径。 \n\nDependencies 分为两大类，Narrow Dependencies 和 Wide Dependencies（如图 3-3）。 \n\nNarrow Dependencies 是指父 RDD 的每一个分区最多被一个子 RDD 的分区所用，表现为一个父 RDD 的分区对应于一个子 RDD 的分区或多个父 RDD 的分区对应于一个子 RDD 的分区，也就是说一个父 RDD 的一个分区不可能对应一个子 RDD 的多个分区。 \n\nWide Dependencies 是指子 RDD 的分区依赖于父 RDD 的多个分区或所有分区，也就是说存在一个父 RDD 的一个分区对应一个子 RDD 的多个分区。在 Spark里面需要shuffle，Spark称之为Shuffle Dependency，做为划分 stage 依据。 \n\n\n\n图 3-3 Narrow Dependencies 与 Wide Dependencies\n\n在 Spark 中 Stage 划分方式是从后往前推算，遇到 ShuffleDependency 就断开，遇到 NarrowDependency 就将其加入该 stage。每个 stage 里面 task 的数目由该 stage 最后一个 RDD 中的 partition 个数决定。如图 3-4。\n\n\n\n图 3-4 Spark Stage 划分方式\n\n**在 Spark 中 RDD 的算子分为两大类**： \n\nTransformations：数据转换，如map、filter、flatMap、join、groupByKey、reduceByKey、sortByKey、repartition等等，该类型算子采用 lazy evaluation（惰性求值），即 Transformation 操作不会开始就真正的计算，只有在执行 Action 操作的时候 Spark 才会真正开始计算。转化操作不会立刻执行，而是在内部记录下所要执行的操作的相关信息，必要时再执行。 \n\nActions：数据物化操作，计算触发，如collect、count、foreach、first、saveAsHadoopFile 等等。 \n\n每个 Stage 内包含一组 TaskSet，Task 之间传递数据是 Pipeline 的方式。\n\n**根据业务标签数据处理需要，借鉴 Spark 的思想，CDP 对 DAG 计算做了一些简化**，具体如下： \n\n在 CDP 的 DAG 中，DAG 的拆分是直接从前往后推算，不需要拆分 Stage，所有的 DAG Task 都在同一个 stage 中（All in one Stage）如图 3-5，并且是并发可扩展，不需要 DAGScheduler。\n\n**在 CDP 中算子分为两大类：**\n\nOperator：数据处理操作算子，如 Stream、Priority、Join、Filter、Sink，是由基础的原子算子配置而来，该类型算子采用 eagerevaluation（及早求值），即 Operator 在数据一旦进入就会触发数据处理操作，这样不需要缓存状态数据，能有效提升数据处理效率。 \n\nEdge：描述 Operator 之间的关系，即拓扑关系。 \n\n\n\n图 3-5 CDP All in one Stage\n\n## 四、标签持久化\n\n标签持久化的场景需要解决业务标签的持久化存储、更新、查询服务，采用分布式高可用关系型数据库（TiDB）存储业务持久化的标签，采用实时触发场景中的动态规则配置的方式消费业务系统数据变更消息，使用本文第三节中提到的实时触发的方式处理后更新持久化标签存储数据，保证业务持久化标签的时效性，**通过 TiDB 对于不同场景查询特性（主要是 OLAP 和 OLTP）的支持来满足不同业务场景访问业务特征数据的需要**。\n\n为了解决标签持久化场景的需求，借鉴 Lambda 数据处理架构的思想，新增数据根据来源不同分别发送到不同的通道中去，历史全量数据通过数据批处理引擎（如 Spark）转换完成以后批量写入到数据持久化存储引擎（TiDB）。增量数据业务应用以消息的形式发送到 Kafka 或者 QMQ 消息队列，通过本文第三节实时触发场景中提到的实时数据处理方法，将数据按照标签持久化的逻辑规则处理完成之后增量写入到持久化存储引擎（TiDB），这样解决数据的时效性问题。 \n\nTiDB 有两大持久化存储方式，一种是 Row 模式的 TiKV，对于实时在线查询场景（OLTP）支持的比较好，一种 Column 模式的 TiFlash，对于分析类查询场景（OLAP）支持的比较好，TiDB 数据存储内部自动解决这两个引擎的数据同步问题，客户端查询根据自身需要选择查询方式。\n\n\n图 4-1 Lambda 架构\n\n\n图 4-2 CDP 持久化流程\n\n持久标签的访问主要场景有两个，一种是跟现有 CRM 系统对接，在线根据业务的特征圈选符合条件的业务数据，这种场景的查询条件不固定，返回结果集因筛选条件而定，对于数据存储引擎的数据计算和处理能力要求比较高，即我们在数据处理领域经常提到的 OLAP 的场景。另一种场景是线上业务根据前端传入的业务标签相关的唯一标识来查询是否满足特定业务要求，或者返回指定特征值，满足业务处理的需要，需要 ms 级响应，对应的是 OLTP 场景。\n\n## 五、业务应用\n\n### 5.1 实时触发场景应用\n\n在 Trip 的很多业务场景中，需要对多条业务输入数据做清洗、整合、计算加工处理之后再反馈应用到业务场景中去，促进业务增长。比如 Trip 一些产品线的促回访、促首单、促复购、优惠券过期、APP 新用户触达等 App Push 和 Email 邮件营销和消息等场景，提升 Trip 产品曝光和转化效率。 \n\n以 Trip 某产品促回访 APP Push 推送消息为例，从页面的浏览行为到触发发送的流程可以分为几个部分： \n\n1）发生浏览行为；\n\n2）CDP 实时获取和处理目标行为日志数据，发送给发送通道； \n\n3）发送通道完成消息发送前处理； \n\n4）根据针对该产品的不同浏览行为发送不同内容的消息。 \n\n根据该产品实时促回访场景业务需要，以及 CDP 实时触发场景支持的算子，配置过滤任务从而动态过滤出该产品促回访场景需要的数据，根据不同的浏览深度打上不同的标签，推送通道根据深度标签给不同的客户端推送不同的内容，具体的 CDP 配置算子业务逻辑如图 5-1。\n\n\n图 5-1 CDP 某 Trip 产品促回访触发逻辑示意图\n\n通过 CDP 实时触发场景配置，系统可以根据配置动态生成任务，不需要额外的代码开发，并且配置可以动态修改，动态生效，不需要编译、重启任务。目前这种方式从运行效果来看时效性更高，更灵活，更稳定，开发测试成本更低，不需要走代码开发、编译、测试、发布的流程。 \n\n### 5.2 标签持久化\n\n在第一节中我们提到来自不同业务系统的数据都会有对应的 ID 及标签与之对应，我们在持久化这些标签的同时根据业务需要建立这些 ID 之间的 Mapping 关系，如果是一一映射我们会直接存储 Mapping 关系，如果是多对多的关系我们会根据业务需要，按照首次、最近、全部映射关系等等方式落地 ID Mapping 关系，方便用户筛选时串联不同 ID 的特征。 \n\n目前 CDP 已经上线跟携程国际业务相关的业务系统经过实时清洗、转换和整合处理后落地的业务特征标签库，系统通过 API 的方式对外提供相关数据查询和计算服务。目前 CDP 在跟 Trip 各个业务系统深度整合打通，为国际业务增长提供业务特征标签库的数据和服务支持。","author":"携程技术","category":4,"customUrl":"dynamic-real-time-label-processing-platform-in-ctrip","fillInMethod":"writeDirectly","id":326,"summary":"本文由携程技术团队撰写，介绍了携程自研的国际业务动态实时标签处理平台。其中标签持久化的场景需要解决业务标签的持久化存储、更新、查询服务，TiDB 通过对于不同场景查询特性的支持满足了不同业务场景访问业务特征数据的需要。","tags":["TiDB"],"title":"携程国际业务动态实时标签处理平台实践"}}]}}},
"staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}