{
"componentChunkName": "component---src-templates-blog-blog-detail-tsx",
"path": "/blog/the-trend-and-technology-choice-of-digital-native-enterprise",
"result": {"pageContext":{"blog":{"id":"Blogs_463","title":"技术出海丨数字原生企业的出海趋势和技术选择","tags":["TiDB","DNB","技术出海"],"category":{"name":"观点洞察"},"summary":"本文将以全球化的视野观察中国数字原生企业出海的新趋势，包括 DNB（ 数字原生企业）主要行业的发展特点，目前发展阶段的热点和未来转向，再从这些行业趋势来看中国出海企业面临的技术挑战。","body":"最近一年，中国企业出海成为热门话题，特别是数字原生企业的出海。许多文章和报告分析了中国数字原生企业在全球（东南亚、南美洲、欧洲、美国等）的发展趋势，以及一些成熟的数字原生企业在电商、游戏、社交、新一代数字媒体方面的成功经验。作为新一代分布式数据库的 TiDB，其主要服务对象也是全世界的数字原生企业。\n\n本文将以全球化的视野观察中国数字原生企业出海的新趋势，包括 DNB（ 数字原生企业）主要行业的发展特点，目前发展阶段的热点和未来转向，再从这些行业趋势来看中国出海企业面临的技术挑战，PingCAP 作为一家全球化数据企业在全球的布局和如何帮助出海企业获得增长。\n\n## 中国数字原生企业的当前优势\n\n过去两年，中国出海企业布局发生了重大变化。全球化已经成为长期生存战略，特别是在数字原生企业中，出海成为企业能够穿越周期并且持续生长的关键可能性。中国数字原生企业的人才优势逐渐体现，中国在整个移动互联网和数字平台时代所积累的人才优势是中国企业全球化的基础。未来十年，中国数字原生企业的出海和全球化将是值得关注的话题。\n\n中国在跨境电商、游戏、数字媒体、社交等领域，在各种共享经济应用方面，在东南亚和欧洲均显示出了巨大的优势。在过去十年的 Web2.0 移动互联网时代中，中国的模式创新和人才积累的优势，特别是在电商和社交媒体领域，已经成为全球企业争相仿效的最佳实践。而在新一代的 web3 和 NFT 技术平台中，也有大量的中国工程师和商业人员的存在。\n\n简单来说，中国数字原生企业具有独特的优势，这来自中国移动互联网发展的人口红利、工程师红利、web2.0 的经验积累、全球化的市场营销模式。中国工程师具有强大的技术能力，并不断溢出优秀的人才，这带来了巨大的效率优势。\n\n中国数字原生企业未来十年的全球化成功，最重要的因素是人才基础。人才分布决定了数字版图，现在全球各国开源人才分布的会变成未来五到十年数字经济的人才底座。从这个角度能看出：未来亚裔工程师和技术人才可能成为全球数字经济的最重要的建构师，其中中国人和印度人占有很大比例。亚洲的数字化以及全球的数字化可以得到亚裔工程师的支持，中国的数字原生企业可以依赖这种人才分布，并一开始就定位全球市场，现在开展全球化的出海企业在人才方面具有不同以往的信心。\n\n## 中国数字原生企业的成长挑战\n\n出海有机遇当然也有挑战。中国数字原生企业有人才优势和有 web2.0 积累的商业模式构建的能力，但仍缺乏三方面的能力：第一是全球化业务拓展中的跨文化组织和协同，如何使用本地化方法构建全球化组织。第二是运营风险与合规，各国都有自己独特的合规法案和内控法案，以及数据安全规定。这使得数字原生企业在全球拓展时会面临许多运营风险，特别是在数据安全和个人隐私方面。第三是技术人才和全球化基础设施问题，如何形成全球化的技术组织和标准，因为全球化时面临的技术人才是更难获得的。\n\n\n\n技术角度再延伸看，数字原生企业全球化面临的主要技术挑战包括：\n\n1. 全球部署：在多云环境下，如何管理自身的基础设施并处理数据合规的挑战。\n2. 高可用与安全：保护个人和企业数据的安全，解决高可用、高一致性和低延迟等生产数据要求，这些都是全场景业务的技术挑战。\n3. 技术架构的复杂：在全球获得高质量的技术团队是一项挑战，而全球的技术部署不能太复杂，否则将无法在当地解决计算引擎、数据库、中间件等各种架构的挑战。\n\n## PingCAP 全球化的探索和实践\n\nPingCAP 的全球化同样和中国数字原生企业一样，兼具机遇和挑战。为了提高自身的全球化能力，PingCAP 要不断努力，这是随着服务全球化的企业一起成长的。下面以 PingCAP 全球化为例的阐述是作为一个现实例子带来中国技术企业全球化的思考，也会给中国数字原生企业出海带来一些启发。\n\n首先，PingCAP 在全球布局时首先进入美国和日本市场。这两个市场通常被认为是中国企业海外扩展最困难和最具挑战性的市场。事实上，PingCAP 最初全球化的目的是为了制造最好的世界级产品和聚合全球化人才，但后来却意外发现，这两个国家的客户要求特别高，并面临一些挑战。但事实证明，最初走的这条自主开源的道路建立了信任，加上经过世界级场景打磨的产品，使得 TiDB 在这两个成熟市场得到认可。\n\n通过持续性服务这些成熟市场的头部用户，PingCAP 不仅得到了商业回报，还得到了真正的 “Lighthouse” 成功案例，这具有很强的说服力。今天，PingCAP 在美国的成功案例对欧洲、日本、新加坡、印度等的客户都有巨大的影响力。\n\nPingCAP 在日本的第一个客户是当地排名第一的一家移动支付公司。从 2018 年开始，日本用户开始从使用传统的 Oracle 数据库转向使用云数据库，并逐渐开始关注 NewSQL。NewSQL 在日本是一个新的热门词汇，TiDB 在没有大量员工的情况下，通过线下的客户拜访和分享活动等形成了良好的口碑。经过多年的发展，TiDB 已经在日本成为了用户最关注的新一代数据库，在 2022 年的 DBtech Showcase 大会上获得了排名第一的关注度。\n\n在硅谷，PingCAP 于 2022 年 11 月 1 日，成功举办了首届 HTAP Summit ，作为一家中国的创业公司，在硅谷这样的地方举办一场超过 200 人参加的线下大会是非常困难的，特别是对于那些在硅谷不够知名的中国技术公司来说。中国创业公司在做数字原生企业海外扩张时都会面临着人少、事多、挑战大、知名度不够等种种困难情况。\n\n在新加坡的亚太区，Web3 是当前热门话题。在不到一年的时间里，PingCAP 已经在新加坡获得了多个 Web3 的客户的认可。通过组织和参加活动，PingCAP 获得了当地技术公司的高度认可和关注，这也是 PingCAP 在新加坡和整个东南亚地区的特点。\n\n在印度，TiDB 成功支撑了印度最大的电商和物流公司在印度 \"双十一\" 这一天的高峰期。印度是一个开发者极其活跃的国家，在开源贡献者方面仅次于硅谷。在印度的 \"双十一\" 期间，通过使用 TiDB，他们实现了技术架构的变革，应对了全印度的 \"双十一\" 购物狂潮。\n\nPingCAP 是中国技术企业走向全球化的一员，任何数字原生企业都可能需要经历类似 PingCAP 的全球化拓展过程，这过程中可能会遇到各种各样的困难和挑战。每一次的进步都需要团队间的信任，包括与开发者建立联系、通过云技术提供服务，以及不懈的探索和努力。\n\n## 中国数字原生企业如何选择全球化的合作伙伴\n\n在选择全球化的技术合作伙伴时，中国的全球化数字原生企业应该考虑如下必选项和优选项，这是由 PingCAP 和全球用户以及中国数字原生企业在过去几年中的经验得出的。这里着重强调了对于一个有全球化抱负的中国数字原生企业如何选择合适的技术合作伙伴。\n\n\n\n在选择全球化技术合作伙伴方面，有以下几个必选项：\n\n1. 选择技术领先的企业，因为技术领先直接影响到业务的竞争力。\n2. 中国企业出海必然面临多云的选择，因此必须选择一个云中立的厂商，以保证一次应用适配，同时还能节省成本。\n3. 合作伙伴必须具备全球化的合规经验，全球化的支持能力，包括用户服务支持当地的需求。\n4. 全球范围内均有技术团队，既需要当地的人员，也要有核心技术团队在中国，这对于中国数字原生企业来说是非常重要的。\n\nTiDB 在日本、印度等困难的地方仍能获得用户信任的原因在于自主开源的模式，这让用户相信其领先的技术，并且无风险。全球大型客户的部署案例和多云部署经验对于中国企业的出海也是重要的参考。同时，多云部署模式的出现，如将 OLTP 放在 A 云，OLAP 分析放在 B 云，以及全球化的社区支持，都是全球化带来的价值。\n\n最后也是最重要的一个方向是友好的上下游技术生态。基于开源的多云技术生态，很容易与数据湖、大数据技术栈以及应用开发技术栈、低代码人工智能技术栈形成良好的融合。现在数字技术中最重要的云原生、数据技术、人工智能技术、低代码技术，以及新一代的 SaaS 都是开源的，TiDB 在北美、印度等地也与多家技术厂商形成多元化的技术合作关系，包括云厂商 AWS、Google、阿里云等。这些合作经验使得作为一家数字原生企业不必担心未来集成的成本，因为都已在技术厂商内部进行了预集成和消化。\n\n**只有真正全球化的公司才能服务全球化客户**\n\n\n\nPingCAP 相信，只有全球化的公司才能服务好全球化的客户，中国的企业海外扩张仅仅是第一步，最终的目标是成为一家全球化的公司。以 TiDB 为例，它已经拥有超过 3000 家全球用户，其中大多数是数字原生企业，涵盖了金融、互联网、物流、游戏、智能制造等领域，这些全球化用户的部署经验可以成为中国企业海外扩张的重要参考和支持。此外，PingCAP 自身的全球化也处于中国技术公司中较为领先的水平，从早期的全球化开源到现在的多云架构，再到与云厂商的合作，它所积累的全球化经验可以与中国企业共享。\n\n团结协作，共同走向一个数字原生企业全球化的目标，虽然前路艰难，但 PingCAP 希望与中国出海企业长期保持一起共创共赢的关系，通过共同努力，赢得全球化用户的尊重，为全球化用户企业带来更多价值。\n\n","date":"2023-02-21","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"the-trend-and-technology-choice-of-digital-native-enterprise","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":"近些年，由于互联网的快速发展以及线上需求的爆发，**直播在国内已经成为一个非常成熟的商业模式**。在娱乐、教育、办公等场景中涌现出许多优秀的视频直播产品。随着国内市场竞争日益白热化，加之企业出海渐成趋势，越来越多的直播公司选择走出去，寻找新的海外直播市场，借鉴国内成熟的产品、运营以及商业模式，让全球的用户都用上中国人创造的产品，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":"同盾科技是中国领先的人工智能科技企业。为了确保服务的低延迟和高可用性，同盾的技术团队不断寻找最佳的技术架构。经过长时间调研，他们最终选择了新一代分布式数据库 TiDB 作为离线层的核心数据库，**基于 TiDB 打造的实时数据架构为风控智能决策保驾护航**。\n\n同盾科技是中国领先的人工智能科技企业，专注决策智能领域，致力于帮助政企客户防范风险、提升决策效率。同盾科技坚持自主科技创新，多项算法和软件系统已达全球领先水平，并形成了“基于隐私计算的共享智能平台-智邦”和“基于人工智能的决策智能平台-智策”两大平台，聚焦于金融风险、安全风险、政府治理风险三大场景，业务覆盖全球数十个国家，为 22 大行业、118 个细分场景的上万家客户提供了领先且独具特色的决策智能解决方案。\n\n## 风控业务场景对数据库的需求与挑战\n\n作为一家第三方风控公司，客户经常需要调用同盾的智能决策服务去做业务决策，如电商大促期间防范黑产薅羊毛，个人信贷杜绝多头借贷老赖行为等。因此，**同盾服务调用常常呈现出非常大的 TPS 请求**。同时，为了不影响客户调用服务的质量与体验，**同盾对低延迟和高可用有着硬性要求**。\n\n基于这样的特征，同盾日均过亿的决策服务调用，会产生包括非结构化/结构化多种数据结构类型在内的海量数据入库。丰富的数据类型与多样的细分场景，使得同盾科技必须使用多种数据库去满足不同的业务场景需求，在同盾的数据架构中包含了 Cassandra、MySQL、HBase、Redis、Mongo 等数据库。\n\n在同盾的数据架构中，大多数初始落库的数据还比较原始，为了提供优质的数据服务用于智能决策，**技术团队构建了成熟的大数据平台**，用 T+1 离线数据分析的方式去进行日常的离线数据分析作业，利用数据二次加工赋能上层的风控智能决策。\n\n但面对复杂的数据基础架构，同盾在业务增长中也遭遇了如下挑战：\n\n- 同盾拥有在线数千个大大小小的 MySQL 工作实例，**数据十分分散**，有一些是核心的风控业务系统数据，有一些是后台基础架构平台的数据，还有一些是集团 IT 系统数据，同盾希望通过集中化的方式对这些数据进行分析管理；\n- 最开始同盾将上游 MySQL 数据同步到下游进行分析，但整个过程中**数据交换工作效率非常低**，整体作业分析的 SLA 无法得到保证；\n- 由于上下游数据同步的阻塞问题，导致了离线数据同步实时性很差，**上下游数据经常出现数据不一致的情况**，非常影响提供给作业的数据质量。\n\n其实同盾科技的业务场景并不复杂，只需要同步生产环境中数千个 MySQL 实例至下游的离线系统，提供给作业开发人员通过大数据平台进行离线分析加工。**项目的核心目标是在海量数据落库下，保障在线到离线数据的数据库的准实时性和一致性，并提供优质的数据服务给内部的风控系统开发人员、算法模型工程师和运营人员加工数据。**\n\n## 为什么选择 TiDB？\n\n经过长时间调研，同盾科技的技术团队最后选择了新一代分布式数据库 TiDB 作为离线层的核心数据库。同盾科技数据库运维梁高升表示，主要有以下几点原因最终促成同盾选择 TiDB ：\n\n首先，**TiDB 高度兼容 MySQL 协议**，在 TiDB 的使用和运维过程中大大减轻了运维和开发人员的使用成本；\n\n第二，TiDB 作为**分布式数据库**，同盾可以把它看成一个大的数据库实例，可以汇聚上游所有的MySQL实例数据；\n\n第三，TiDB 具备**存算分离**的架构，可以让同盾非常灵活地控制硬件成本，而不用一味堆砌服务器；\n\n最后，TiDB 拥有**非常活跃的社区**。即使在使用 TiDB 的过程中遇到一些问题也马上能在社区得到解决。\n\n## 解决方案\n\n\n\n最终，同盾科技数据库团队构建了一整套基于 TiDB 的数据流转架构，该架构共分为三层：\n\n### 实时数据层\n\n同盾内部有 3000+ MySQL 实例，在实时数据库层通过 MySQL Cloud 管控上游数千个 MySQL。\n\n### 传输层\n\n在传输层，从 MySQL Cloud 对接实时数据同步任务到内部 Otter，Otter 可以实现准实时同步 MySQL 数据，然后再由 Otter 实时同步数据到 TiDB。\n\n上下游同步组件决定了数据在下游离线场景的整体数据质量，同盾对数千个 MySQL 实例同步数据的同时，需要保证其稳定性、低延迟及整体可控的管理成本。虽然 PingCAP 数据迁移工具 DM 支持全量/增量灵活的数据导入场景，并具有较快的导入速率，但目前单个 DM worker 只支持绑定一个数据源，这限制了管理大量 MySQL 同步任务的需求。同盾最后选择使用 Otter 作为常态化的数据增量同步平台，但 Otter 只支持增量数据同步，且单任务吞吐有上限，同盾通过使用其支持 spark streaming 来进一步保障同步的吞吐和准实时性。未来在 TiDB 推出一个 DM worker 支持多个数据源的特性后，同盾会再考虑进行替换。\n\n### 离线数据层\n\n离线数据层中的大数据平台主要管控 TiDB 的元数据和实际到下游的同步情况。在 Spark 运行作业的过程中通过 TiSpark 去访问 TiDB，最后接入 Hadoop 进行分析作业。\n\n## 业务收益\n\n通过打造 TiDB 数据产品链，同盾科技实现了数千个 MySQL 数据的离线汇聚管理。TiDB 有着便捷易操作的 Dashboard 管理界面，运维无心智负担，大大提升了数据库运维团队的管理运维和使用数据的便捷性与效率。同时，TiDB 的高性能保障提供高质量的数据服务，实现了准实时同步数据。\n\n同盾科技数据库运维梁高升介绍，同盾刚开始上线的是 TiDB 2.0 早期版本，在上下游数据同步过程中遇到了一些 TiDB 和 MySQL 不那么兼容的情况，如果在上游有大量数据更新的情况下，会出现同步阻塞的情况，导致同步的实时性、一致性出现问题。但 TiDB 版本迭代速度非常快，每个版本都会对性能及稳定性做出大量改进和优化，**在升级到 5.4 版本后，同盾就已经解决了大部分的兼容问题**。而且在基准测试中，TiDB 的性能也得到了质的飞跃。\n\n## 未来规划\n\n同盾科技是 TiDB 非常早期的用户，多年的使用让同盾确信 TiDB 是一款非常好的产品，**未来也会继续致力于在更多的场景依靠 TiDB 生态落地赋能一些业务场景**。例如，虽然同盾的大部分作业是 T+1，但内部也有很多实实在在的实时分析场景，比如实时展示的 BI 系统，通过TiFlash 实时分析查询引擎可以进一步提升分析效率，更及时地满足实时分析需求；同盾国内在线业务针对海量关系型数据库初始使用的是 MyCAT，但是 MyCAT 的运维非常困难，对开发也不是很友好，更像是上一代的分布式数据库产品。后续，类似 MyCAT 这样的场景也很有必要使用 TiDB 进行替换。\n\n近几年，随着出海趋势愈发火热，同盾科技在出海业务势头也非常迅猛，业务涉及东南亚、北美、欧洲等多个区域，这就需要在谷歌云、AWS、阿里云等通用公有云上，有一款标准的分布式数据库服务，帮助其在全球快速布局业务。**而 TiDB Cloud 已经在各大主流公有云上提供服务，这也给同盾科技构建坚实的技术底座提供了更好的选择。**","author":"PingCAP","category":4,"customUrl":"tidb-in-tongdun","fillInMethod":"writeDirectly","id":452,"summary":"同盾科技是中国领先的人工智能科技企业。为了确保服务的低延迟和高可用性，同盾的技术团队不断寻找最佳的技术架构。经过长时间调研，他们最终选择了新一代分布式数据库 TiDB 作为离线层的核心数据库，基于 TiDB 打造的实时数据架构为风控智能决策保驾护航。","tags":["TiDB","技术出海"],"title":"同盾科技 x TiDB丨实时数据架构为风控智能决策保驾护航"}}]}}},
"staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}