{
    "componentChunkName": "component---src-templates-blog-blog-detail-tsx",
    "path": "/blog/how-to-achieve-real-time-and-full-data-under-the-growth-of-mass-data",
    "result": {"pageContext":{"blog":{"id":"Blogs_477","title":"方案精讲丨电商数据技术栈，在海量数据增长下如何实现实时与全量兼得？","tags":["TiDB","技术出海"],"category":{"name":"产品技术解读"},"summary":"在跨境电商领域中，TiDB 得到了广泛的应用。本文分析了电商出海的现状与挑战，同时介绍了 TiDB 的产品能力，并结合实际案例介绍了对应的解决方案。","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![商品中心.png](https://img1.www.pingcap.com/prod/_05dac307d9.png)\n\n商品中心是电商平台提供服务的具体内容，大量商品和内容信息会在平台进行曝光展示，用户看到商品信息后产生消费意愿，最终完成下单。商品内容在电商整个业务链条中会被多次依赖，在特定的时间或者特定的活动下（如购物节），会产生爆发式的流量增长。此时，商品内容模块的流量可能达到平时数倍以上。所以，在面向 C 端平台的这些核心模块必须保证数据服务的可靠性及稳定性，通常对 SLA 的要求是非常高的，数据量也非常大。\n\nTiDB 基于原生的分布式架构，可以根据业务的实际情况灵活扩展计算及存储节点。同时，TiDB 也具有数据强一致性能力，可以做到故障自动恢复，为商品中心提供可靠的数据存储，应对大促带来的流量高峰。\n\n### 订单中心\n\n![订单中心.png](https://img1.www.pingcap.com/prod/_0651a00813.png)\n\n订单中心在电商交易的链路中扮演着一个非常重要的角色。它向上对接用户信息，将用户订单信息转化为订单数据，并且管理并追踪整个订单过程，是整个公司在线交易中不可或缺的一个环节。同时，订单中心还承接了其他系统的功能，如促销、仓储、会员和支付等，扮演着关键的承上启下的作用。\n\n订单中心对 SLA 有很高的要求，同时订单的数据规模非常大，订单状态还要保持持续跟踪，这就造成订单中心的吞吐量也相当大。\n\n与传统解决方案和基于 MySQL 的分布式解决方案相比，TiDB 在吞吐量、数据处理和查询能力、可扩展性等方面具有显著优势。过去，为了解决查询问题，传统解决方案必须扩展大量的读写节点，导致系统数据冗余，同时又只能扩展读能力，写能力无法得到扩展。而 TiDB 提供了一种高效的解决方案，可以同时扩展读写能力，是管理大量订单的最佳选择。\n\n### IM 场景\n\n![不同数据库在 IM 场景的对比.png](https://img1.www.pingcap.com/prod/IM_6e9b08afca.png)\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![TiDB 在实时风控中的应用.png](https://img1.www.pingcap.com/prod/Ti_DB_c3330db13f.png)\n\n借助 TiFlash 一体化的 HTAP 能力，TiDB 可以很好地处理需要实时性非常高的风控业务。与此同时，风控业务中也有一类负载比较重的 SQL 查询，但执行时间很难预测，这些查询可能是突发性流量或有周期性的，而不是持续存在的。如果计算资源始终按照最高需求或峰值提供，将会造成极大的浪费。因此，TiFlash 的 Serverless 可以很好地为这类负载降低总体拥有成本（TCO）。\n\n## 跨境电商行业解决方案\n\n除了传统经典的亚马逊、eBay 等老牌第三方电商平台，近年来，独立站逐渐在跨境电商中流行起来。其趋势正不断增长，其中包括 DTC 自建、SaaS 建站和开源建站等多种方式。\n\n提到独立站，就不得不提 SaaS 平台。SaaS 平台中有大量租户数据需要管理，这些数据要怎样才能更好地进行管理呢？通常这些数据需要满足以下需求：如隔离性，即多个租户之间的隔离；敏捷性，即数据需要能够快速创建；可扩展性，面对未来的业务增长需求，数据可以快速扩缩；性能方面希望每个租户都能够拥有比较隔离的资源，以避免邻居争用，也就是所谓的“吵闹的邻居”，这可能会导致性能争用等问题。另外，希望 SaaS 用户的数据能够合法合规，并且存储在他们所要求的地区内。\n\n![SaaS 平台多租户.png](https://img1.www.pingcap.com/prod/Saa_S_7ade81b76d.png)\n\n过去常见的部署方式可能有以下几种：一、每个租户都有独立的数据库实例部署；二、将所有租户共享在一张表中。但这些方式有各自的优点和问题。例如，共享方式的隔离性较低，但独立实例的成本又相对较高。\n\n![多租户常见部署方式.png](https://img1.www.pingcap.com/prod/_060bdf5753.png)\n\n![多租户常见部署方式-2.png](https://img1.www.pingcap.com/prod/2_de16b82acb.png)\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 一栈式实时数据分析能力，也让数据实时分析成为可能，帮助企业提升运营效率，赢得市场先机。","date":"2023-03-24","author":"李坤","fillInMethod":"writeDirectly","customUrl":"how-to-achieve-real-time-and-full-data-under-the-growth-of-mass-data","file":null,"relatedBlogs":[{"relatedBlog":{"body":"vivo 是一个专注于智能手机领域的国际化品牌，市场不断变化，新零售热潮扑面而来。在数字化转型过程中，vivo 的基础平台架构也面临着更多的挑战。在自主研发的同时，vivo 依托包括 TiDB、TiKV 在内的众多开源项目进行迭代和设计，打造了全新的数据库与存储平台，覆盖通用存储产品运维和研发需求。\n\n本文来源于 vivo 互联网技术，根据 vivo 存储技术团队研发总监肖博在 2021 vivo 开发者大会上的分享整理而成，**从数据库与存储平台的建设背景、能力介绍、探索思考、未来展望四个角度进行了整体的介绍**。\n\n## 一、数据库与存储平台建设背景\n\n![01.jpeg](https://img1.www.pingcap.com/prod/01_9069c434b6.jpeg)\n\n以史为鉴，可以知兴替，做技术亦是如此，在介绍平台之前，我们首先回顾下 vivo 互联网业务近几年的发展历程。  \n\n我们将时间拨回到三年前，2018 年 11 月，vivo 移动互联网累计总用户突破 2.2 亿；2019 年应用商店、浏览器、视频、钱包等互联网应用日活突破千万大关；2020 年浏览器日活突破 1 亿，2021 年在网总用户（不含外销）达到 2.7 亿，数十款月活过亿的应用，数据库和存储产品也达到了 4000 + 服务器和 5 万 + 数据库实例的规模。  \n\n那三年前的数据库和存储平台是什么样呢?\n\n![02.jpeg](https://img1.www.pingcap.com/prod/02_b73e957869.jpeg)\n\n2018 年的数据库服务现状如果用一个词形容，那我觉得“**危如累卵**”最适合不过了，主要表现为以下几点：  \n\n- 数据库线上环境的可用性由于低效的 SQL、人为的误操作，基础架构的不合理，开源产品的健壮性等问题导致可用性经常受到影响。\n- 变更不规范，变更和各种运维操作的效率低下，没有平台支撑，使用命令行终端进行变更，导致数据库使用的成本极高，为了应对日益复杂的业务场景，增加了很多额外的成本。\n- 安全能力不够健全，数据分类分级、密码账号权限等缺乏规范。\n\n我们再看看这些年 vivo 数据库运营数据上的变化趋势。\n\n![03.jpeg](https://img1.www.pingcap.com/prod/03_87c3c0aeeb.jpeg)\n\n从 17 年底，18 年初开始计算，这三年时间里数据库实例的规模增加了接近 5 倍，维护的数据库服务器规模增加了 6.8 倍，数据库实例的单机部署密度增加了 5 倍以上，DBA 人均运维的数据库实例规模增加了 14.9 倍。  \n\n通过以上这些数字，我们可以发现，**近几年 vivo 互联网业务正处于一个高速发展的状态，在这个过程中无论是从用户感受到的服务质量上来看还是从内部的成本效率来看，解决数据存储的问题都是迫在眉睫的**，于是我们在 2018 年启动了自研数据库与存储平台的计划，通过几年时间的建设，我们初步具备了一些能力，现在就这些能力给大家做下简单的介绍。\n\n## 二、数据库与存储平台能力介绍\n\n![04.jpeg](https://img1.www.pingcap.com/prod/04_95dc265508.jpeg)\n\n数据库与存储平台产品主要分为 2 层。**底层是数据库和存储产品**，包括关系型数据库、非关系型数据库和存储服务三大块。**上层主要是工具产品**，包括提供的数据库和存储、统一管控的研发和运维平台、数据传输服务、运维白屏化工具，还有一些 SQL 审核，SQL 优化，数据备份等产品。工具产品主要以自研为主，下面一层的数据库和存储产品我们会优先选用成熟的开源产品，同时也会在开源产品的基础上或者纯自研一些产品，以更好地满足业务发展。\n\n### DaaS 平台\n\n![05.jpeg](https://img1.www.pingcap.com/prod/05_3ebbd46d00.jpeg)\n\n![06.jpeg](https://img1.www.pingcap.com/prod/06_d04d1503ec.jpeg)\n\nvivo 的 DaaS 平台旨在**提供高度自助化、高度智能化、高可用、低成本的数据存储使用和管理的平台**，涵盖了数据库和存储产品从服务申请、部署、维护直至下线的全生命周期。主要从四个方面为公司和用户提供价值。  \n\n第一是提升数据库产品的可用性，通过巡检、监控、预案、故障跟踪等对故障进行事前防范、事中及时处理、事后复盘总结进行全流程闭环；第二是提升研发效能，研发自助使用数据库，提供变更检测、优化诊断等功能，减少人工沟通流程，项目变更规范流程清晰，提升研发效率；第三是提升数据安全性，通过权限管控、密码管控、数据加密、数据脱敏、操作审计、备份加密等一系列手段全方位地保障数据安全性；第四是降低数据库和存储产品的运营成本，首先通过自动化的流程减少 DBA 的重复工作，提高人效，其次通过服务编排和资源调度，提升数据库和存储服务的资源使用效率，持续降低运营成本。  \n\n通过几年时间的建设，以上工作取得了一些进展，其中每月数以千计的需求工单，90% 以上研发同学可以自助完成，服务可用性最近几年都维持在 4 个 9 以上，平台对 6 种数据库产品和存储服务的平台化支持达到了 85% 以上，而且做到了统一能力的全数据库场景覆盖，比如数据变更，我们支持 MySQL、ElastiSearch、MongoDB、TiDB 的变更前语句审查，变更数据备份，变更操作一键回滚，变更记录审计追踪等。\n\n### DTS\n\n![07.jpeg](https://img1.www.pingcap.com/prod/07_4054146a20.jpeg)\n\n![08.jpeg](https://img1.www.pingcap.com/prod/08_4e120b9515.jpeg)\n\nvivo 的 DTS 服务是基于自身业务需求完全自研的数据传输服务，主要提供 RDBMS、NoSQL、OLAP 等数据源之间的数据交互。集数据迁移、订阅、同步、备份的一体化服务，从功能上来看，主要有三个特性：第一是同步链路的稳定性和数据可靠性保障，通过结合各个数据源产品的自身特性可以做到数据不重不丢，给业务提供 99.99% 的服务可用性保障；第二是功能层面支持异构的多种数据库类型，除了同步、迁移、订阅等这些通用功能外，我们还支持变更数据的集中化存储和检索；第三是故障容灾层面，支持节点级别故障容灾，可以做到同步链路秒级恢复，也支持断点续传，可以有效地解决因硬件、网络等异常导致的传输中断问题。\n\n### MySQL 2.0\n\n![09.jpeg](https://img1.www.pingcap.com/prod/09_afaa3f4b71.jpeg)\n\n![10.jpeg](https://img1.www.pingcap.com/prod/10_db42533dbf.jpeg)\n\nMySQL 作为最流行的开源数据库，在 vivo 同样承担了关系型数据库服务的重任，上图的 MySQL 2.0 是我们内部的架构版本。  \n\nvivo 为了快速解决当时面临的可用性问题，基于 MHA+ 自研组件做了MySQL 1.0 版本。目前已经演化到了 2.0 版本，MHA 等组件依赖已经没有了，从架构上看，2.0 版本的服务接入层我们支持业务使用 DNS 或者名字服务接入，中间加入了一层自研的代理层 Proxy，这一层做到了 100%与 MySQL 语法和协议兼容，在 Proxy 上面我们又实现了三级读写分离控制，流量管控，数据透明加密，SQL 防火墙，日志审计等功能。  \n\nProxy 层结合底层的高可用组件共同实现了 MySQL 集群的自动化、手动故障转移，通过 Raft 机制保障了高可用管控组件自身的可用性，当然 MySQL 用的还是主从架构，在同地域可以跨 IDC 部署，跨地域同步可以用前面提到的 DTS 产品解决，跨地域多活目前还未支持，这部分将在规划中的 3.0 架构实现。\n\n### Redis 服务\n\n![11.jpeg](https://img1.www.pingcap.com/prod/11_167656fd55.jpeg)\n\n![12.jpeg](https://img1.www.pingcap.com/prod/12_ff8d149494.jpeg)\n\nRedis 作为非常流行和优秀的 KV 存储服务，在 vivo 得到了大量的应用，在 vivo 互联网的发展历程中，有使用过单机版的 Redis，也有使用过主从版本的 Redis。到目前为止，已经全部升级到集群模式，集群模式的自动故障转移，弹性伸缩等特性帮我们解决了不少问题。  \n\n但当单集群规模扩大到 TB 级别和单集群节点数扩展到 500+以后还是存在很多问题，基于解决这些问题的诉求，我们在 Redis 上面做了一些改造开发，主要包括三部份：  \n\n第一是 Redis Cluster 的多机房可用性问题，为此我们研发了基于 Redis Cluster 的多活版本 Redis。  \n\n第二是对 Redis 的数据持久化做了加强，包括 AOF 日志改造，AEP 硬件的引入，包括正在规划中的 Forkless RDB 等。  \n\n第三是 Redis 同步和集群模式的增强，包括异步复制，文件缓存，水位控制等，还有对 Redis Cluster 指令的时间复杂度优化，Redis Cluster 指令的时间复杂度曾经给我们的运维带来了很多的困扰，通过算法的优化，时间复杂度降低了很多，这块的代码目前已经同步给社区。\n\n### 磁盘 KV 存储服务\n\n我们在 Redis 上做了这些优化后，发现仅仅有内存型的 KV 存储是无法满足业务需要，未来还有更大的存储规模需求，必须有基于磁盘的 KV 存储产品来进行数据分流，对数据进行分层存储，为此我们基于 TiKV 研发了磁盘 KV 存储产品。\n![13.jpeg](https://img1.www.pingcap.com/prod/13_8246d924cf.jpeg)\n\n![14.jpeg](https://img1.www.pingcap.com/prod/14_89cb057453.jpeg)\n\n我们在启动磁盘 KV 存储服务研发项目时就明确了业务对存储的基本诉求。第一是兼容 Redis 协议，可以很方便地从原来使用 Redis 服务的项目中切换过来；第二是存储成本要低，存储空间要大，性能要高，结合运维的一些基本诉求比如故障自动转移，能够快速地扩缩容等。最终我们选择了以 TiKV 作为底层存储引擎实现的磁盘 KV 存储服务，我们在上层封装了 Redis 指令和 Redis 协议。其中选择 TiKV 还有一个原因是 vivo 整体的存储产品体系中有使用到 TiDB 产品，这样可以降低运维人员学习成本，能够快速上手。  \n\n我们还开发了一系列周边工具，比如 Bulk load 批量导入工具，支持从大数据生态中导入数据到磁盘 KV 存储，数据备份还原工具，Redis 到磁盘 KV 同步工具等，这些工具大大地降低了业务的迁移成本，目前我们的磁盘 KV 存储产品已经在内部广泛使用，支撑了多个 TB 级别的存储场景。\n\n### 对象存储服务\n\n![15.jpeg](https://img1.www.pingcap.com/prod/15_508970371c.jpeg)\n\n![16.jpeg](https://img1.www.pingcap.com/prod/16_fc6d3087aa.jpeg)\n\n我们知道业务运行过程中除了需要对一些结构化或者半结构化的数据有存取需求之外，还有大量的非结构化数据存取需求。vivo 的对象与文件存储服务正是在这样的背景下去建设的。  \n\n对象和文件存储服务使用统一的存储底座，存储空间可以扩展到 EB 级别以上，上层对外暴露的有标准对象存储协议和 POSIX 文件协议，业务可以使用对象存储协议存取文件、图片、视频、软件包等，标准的 POSIX 文件协议可以使得业务像使用本地文件系统一样扩展自己的存取需求，比如 HPC 和 AI 训练场景，可以支撑百亿级别小文件的 GPU 模型训练。针对图片和视频文件，还扩展了一些常用的图片和视频处理能力，比如水印、缩略图、裁剪、截帧、转码等。\n\n前面简单介绍了 vivo 数据库与存储平台的一些产品能力，那么下面我们再来聊聊在平台建设过程中，我们对一些技术方向的探索和思考。\n\n## 三、数据库与存储技术探索和思考\n\n### 运维研发效率提升\n\n![17.jpeg](https://img1.www.pingcap.com/prod/17_69393c4e30.jpeg)\n\n![18.jpeg](https://img1.www.pingcap.com/prod/18_45f4a2dfda.jpeg)\n\n在平台建设方面，运维研发效率提升是老生常谈的话题，在业内也有很多建设得不错的平台和产品，但是关于如何在数据存储这一层提升运维研发效率相关的探索还比较少。  \n\n我们的理解是：**首先是资源的交付要足够敏捷，要屏蔽足够多的底层技术细节**，为此我们将 IDC 自建的数据库、云数据库、云主机自建数据库进行云上云下的统一管理，提供统一的操作视图，降低运维和研发的使用成本；同时**要提升效率就不能只关注生产环境**，需要使用有效的手段将研发、测试、预发、生产等多种环境统一管控起来，做到体验统一，数据和权限安全隔离。  \n\n此外，我们运用 DevOps 解决方案的思想，将整个平台在逻辑上分为两个域，一个是研发域，一个是运维域。  \n\n在研发域，我们需要思考如何解决研发同学关于数据库和存储产品的效率问题。交付一个数据库实例和支持他们在平台上可以建库建表是远远不够的，很多操作是发生在编码过程中的，比如构造测试数据，编写增删改查的逻辑代码等等。我们希望在这些过程中就和我们的平台发生交互，最大程度的提升研发效率。  \n\n在运维域，目前有一个比较好的衡量指标就是日常运维过程中需要登录服务器操作的次数，现在我们在做的工作就是将运维的动作全部标准化、自动化，并且未来有一些操作可以智能化。  \n\n在研发和运维交互的部分，我们的建设目标是减少交互，流程中参与的人越少效率就越高，让系统来做决策，实现的方案是做自助化。  \n\n### 数据安全管理\n\n![19.jpeg](https://img1.www.pingcap.com/prod/19_7235bdd577.jpeg)\n\n![20.jpeg](https://img1.www.pingcap.com/prod/20_092f919738.jpeg)\n\n安全无小事，为此我们将数据库安全和数据安全的部分单独拿出来进行规划和设计，基本的原则就是权责分明。数据库体系涉及到账号密码等，我们联合 SDK 团队共同研发了密码加密传输使用方案，数据库的密码对研发、运维而言都是密文，在项目的配置文件中依然是密文，使用时对接公司的密钥管理系统进行解密。  \n\n针对数据的部分，我们联合安全团队对敏感数据做了自动标注识别，分类分级，对敏感数据的查询、导出、变更上做了严格的管控，比如权限管控、权限升级、通过数字水印技术进行使用追踪，通过事后的审计可以追溯到谁在什么时刻查看了什么数据。针对敏感数据我们也做了透明加解密操作，落盘到存储介质的数据是经过加密存储的。  \n\n同理，备份的数据和日志也做了加密存储，这些是目前我们做的事情，未来在安全上我们还有很多的工作要做。\n\n### 数据变更管理\n\n![21.jpeg](https://img1.www.pingcap.com/prod/21_287e17ba15.jpeg)\n\n![22.jpeg](https://img1.www.pingcap.com/prod/22_33a0f94200.jpeg)\n\n针对数据变更的场景，我们关注的主要有两点：  \n\n第一是数据变更本身会不会影响已有的业务，为此我们建设了不锁表结构、不锁表数据的变更能力，针对上线前、上线中、上线后三个环节设置三道防线。杜绝一些不好的 SQL 或者 Query 流入到生产环境，针对变更过程中或者变更结束后如果想回滚，我们也做了一键回滚方案。  \n\n第二是变更效率问题，针对多个环境、多个集群我们提供了一键同步数据变更方案，同时为了更好地提升用户体验，我们也提供了 GUI 的库表设计平台。有了这些基础之后，我们将整个场景的能力全部开放给研发同学，现在研发同学可以 24 小时自助进行数据变更操作，极大地提升了变更效率。  \n\n### 数据存储成本管控\n\n![23.jpeg](https://img1.www.pingcap.com/prod/23_5bbd17b8a3.jpeg)\n\n关于成本我们主要从四个方面进行管理：  \n\n第一是预算的管控，资源去物理化，业务以资源为粒度进行预算提报，在预算管控层面对服务器的消耗进行预测和不断的修正，保证水位的健康。  \n\n第二是数据库服务的部署，这块我们经历了几个阶段，最早期是单机单实例，浪费了很多资源，后面发展为标准化套餐部署，同一类型的存储资源不同的套餐混合，通过算法的优化不断的提升资源的使用效率。  \n\n第三是不同属性资源的混合部署，比如数据库的代理层和对象存储的数据节点混合部署，这两种资源一个是 CPU 型的，一个是存储型的，正好可以互补，再往后发展的下一个阶段应该是云原生存储计算分离，还在探索中。  \n\n第四是服务部署之后还需要不断的关注运行中的状况，对容量做巡检和预警，对集群及时的做升降配操作，保障整个运行状态有序。同时需要关注业务运行状态，及时回收下线数据存储集群，减少僵尸集群的存在。  \n\n成本部分还有一个重点就是硬件资源的迭代，这里就不做展开了。  \n\n### 对象与文件储存建设与思考\n\n![24.jpeg](https://img1.www.pingcap.com/prod/24_df500f8909.jpeg)\n\n![25.jpeg](https://img1.www.pingcap.com/prod/25_1b313cd6bf.jpeg)\n\n对象与文件存储这块我们主要关注的有两点：  \n\n第一是成本，关于成本这块我们在数据冗余策略这块使用了 EC，并且做了跨 IDC 的 EC，单个 IDC 全部故障也不会影响我们的数据可靠性。我们还引入了高密度大容量存储服务器，尽可能多地提升单机架存储密度，需要注意的是服务器采购之后的运行成本也不可忽视，依然有很大的优化空间。我们还提供了数据无损和透明压缩的能力和生命周期管理的能力，及时清理过期数据和对冷数据进行归档。通过多种手段持续降低存储成本。  \n\n第二是性能，关于性能这块我们提供了桶&对象粒度底层存储引擎 IO 隔离，通过引入一些开源组件如 alluxio 等提供了服务端+客户端缓存，提升热点数据读取性能，在底层存储引擎我们引入了 opencas 和 IO_URING 技术，进一步提升整机的磁盘 IO 吞吐。\n\n以上就是我们目前在建设的能力的一些探索和思考，最后再来看下我们未来的规划。\n\n## 四、数据库与存储平台规划\n\n![26.jpeg](https://img1.www.pingcap.com/prod/26_6e6dfc750f.jpeg)\n\n在整个存储服务层，我们会不断地完善存储服务矩阵，打磨产品，提供更多元的存储产品，更好地满足业务发展诉求。同时在存储服务层会基于现有存储产品做一些 SAAS 服务来满足更多的业务诉求。在功能层，我们拆解为 4 部分：  \n\n- **数据基础服务**，这部分提供存储产品基本功能，包括部署、扩缩容、迁移、监控告警、备份恢复，下线回收等等。\n- **数据服务**，存储产品本质上是存储数据的载体，针对数据本身我们也有一些规范，最基本的比如数据的查询变更性能优化，数据治理和如何深入到业务编码过程中去。\n- **存储自治服务**，初步划分为性能自治、容量自治、智能诊断、场景服务四大块，通过自治服务一方面可以提升 DBA 工作的幸福感，一方面也可以大大的提升我们系统本身的健壮性和稳定性。\n- **数据安全服务**，目前虽然建设了一些能力，但是不够体系化，未来会继续加大投入。\n\n未来整个存储服务体系会融入到公司整体的混合云架构中，给用户提供一站式和标准化的体验。","author":"肖博","category":4,"customUrl":"construction-and-exploration-of-vivo-database-and-storage-platform","fillInMethod":"writeDirectly","id":351,"summary":"本文根据 vivo 存储技术团队研发总监肖博在 2021 vivo 开发者大会上的分享整理而成，从数据库与存储平台的建设背景、能力介绍、探索思考、未来展望四个角度进行了整体的介绍。","tags":["TiKV"],"title":"vivo 数据库与存储平台的建设和探索"}},{"relatedBlog":{"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![640.png](https://img1.www.pingcap.com/prod/640_54a5dc1d9f.png)\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![640-2.png](https://img1.www.pingcap.com/prod/640_2_45817df395.png)\n\n在选择全球化技术合作伙伴方面，有以下几个必选项：\n\n1. 选择技术领先的企业，因为技术领先直接影响到业务的竞争力。\n2. 中国企业出海必然面临多云的选择，因此必须选择一个云中立的厂商，以保证一次应用适配，同时还能节省成本。\n3. 合作伙伴必须具备全球化的合规经验，全球化的支持能力，包括用户服务支持当地的需求。\n4. 全球范围内均有技术团队，既需要当地的人员，也要有核心技术团队在中国，这对于中国数字原生企业来说是非常重要的。\n\nTiDB 在日本、印度等困难的地方仍能获得用户信任的原因在于自主开源的模式，这让用户相信其领先的技术，并且无风险。全球大型客户的部署案例和多云部署经验对于中国企业的出海也是重要的参考。同时，多云部署模式的出现，如将 OLTP 放在 A 云，OLAP 分析放在 B 云，以及全球化的社区支持，都是全球化带来的价值。\n\n最后也是最重要的一个方向是友好的上下游技术生态。基于开源的多云技术生态，很容易与数据湖、大数据技术栈以及应用开发技术栈、低代码人工智能技术栈形成良好的融合。现在数字技术中最重要的云原生、数据技术、人工智能技术、低代码技术，以及新一代的 SaaS 都是开源的，TiDB 在北美、印度等地也与多家技术厂商形成多元化的技术合作关系，包括云厂商 AWS、Google、阿里云等。这些合作经验使得作为一家数字原生企业不必担心未来集成的成本，因为都已在技术厂商内部进行了预集成和消化。\n\n**只有真正全球化的公司才能服务全球化客户**\n\n![640-3.png](https://img1.www.pingcap.com/prod/640_3_53ac452caa.png)\n\nPingCAP 相信，只有全球化的公司才能服务好全球化的客户，中国的企业海外扩张仅仅是第一步，最终的目标是成为一家全球化的公司。以 TiDB 为例，它已经拥有超过 3000 家全球用户，其中大多数是数字原生企业，涵盖了金融、互联网、物流、游戏、智能制造等领域，这些全球化用户的部署经验可以成为中国企业海外扩张的重要参考和支持。此外，PingCAP 自身的全球化也处于中国技术公司中较为领先的水平，从早期的全球化开源到现在的多云架构，再到与云厂商的合作，它所积累的全球化经验可以与中国企业共享。\n\n团结协作，共同走向一个数字原生企业全球化的目标，虽然前路艰难，但 PingCAP 希望与中国出海企业长期保持一起共创共赢的关系，通过共同努力，赢得全球化用户的尊重，为全球化用户企业带来更多价值。\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-digital-native-enterprise\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n  </div>\n</div>","author":"PingCAP","category":5,"customUrl":"the-trend-and-technology-choice-of-digital-native-enterprise","fillInMethod":"writeDirectly","id":463,"summary":"本文将以全球化的视野观察中国数字原生企业出海的新趋势，包括 DNB（ 数字原生企业）主要行业的发展特点，目前发展阶段的热点和未来转向，再从这些行业趋势来看中国出海企业面临的技术挑战。","tags":["TiDB","DNB","技术出海"],"title":"技术出海丨数字原生企业的出海趋势和技术选择"}},{"relatedBlog":{"body":"## 导读\n\n从蒸汽机时代到电气时代再到信息时代，背后的制造工厂都有显著的变化，从早期的英国、德国手工打造蒸汽机到风靡一时的福特流水生产线，再到大规模的集成自动化设备投入使用，每一个时代都有与其特点相对应的制造工厂。如今随着从信息时代迈向智能时代，全球制造业正在经历工业 4.0 的变革，大量工厂要接受数字化转型的洗礼，追求智能工厂的精益求精。\n\n随着智能制造成为制造企业的重点，如何快速打通数据通路将成为企业转型成功的关键要素。文章通过案例解析，展示了 TiDB 在智能制造的各个数据流动环节中都可以发挥其独特的价值，包括数据获取、集成和应用展示等。随着 TiDB 整体产品形态不断丰富和完善，TiDB 在智能制造行业将会发挥出更大的价值。\n\n## 智能制造以数据流动为根本\n\n在工业 4.0 时代，需要智能工厂、销售企业和消费者多方协同配合来满足市场需求。其中，对于高端制造企业而言，整个智慧工厂要用数字化、系统化和自动化来取代人工流水线操作，通过更加科学合理的生产流程、更加精准的加工工艺以及智能供应链保证持续稳定的产能，提供单条产线加工多种产品的能力来降低整体生产成本。企业销售侧，则需对产品使用过程中上报的数据和用户行为、用户反馈等数据进行收集、加工和分析，来对产品进行升级迭代、更好优化用户体验、提升用户黏性，同时也能更准确预估市场需求，帮助企业做出合理的经营策略。\n\n这种多方协同配合最终会形成一个如下图所示的相互关联、相互驱动的飞轮。而让飞轮持续高效运转的关键是让智能制造各个环节的数据流动起来。可以说，智能制造是以数据流动为根本，通过应用智能技术如工业互联网、云计算和人工智能等来解决研发、生产和运营等环节的痛点与难点，从而实现智能研发和生产，为客户提供智能产品和智能服务。\n\n![智能制造数据流动.png](https://img1.www.pingcap.com/prod/_b350ff490f.png)\n\n\n## 智能制造行业数据架构的挑战\n\n在理想的情况下，制造企业整体数据的流动应该包含了数据获取、数据集成和数据应用三大模块。以数据获取模块为例，数据获取的来源主要包含两方面：（1）物联网的信息接入层。接入层包含了制造过程中的数据，涉及装备、物料、产品加工过程的工况状况参数以及远程设备上报的信号数据，其特点是数据种类多，比如包含键值对 、视频、图片、文本等数据类型；（2）企业的管理控制类系统。比较常见的有企业资源管理系统 ERP、产品生命周期管理系统 PLM ，以及供应链管理系统 SRM 等。这些系统涉及企业从设计、研发、生产、销售、物流、客户运营等各方面的数据。其数据特点是基本以结构化关系型数据为主。\n\n![制造企业整体数据的流动示意.png](https://img1.www.pingcap.com/prod/_0b0e1e1b52.png)\n\n\n但在现实的情况下，数据流动过程当中的获取、集成和应用都会存在各种挑战。主要体现在三个方面：\n\n- 第一，在数据获取层面，接入层数据种类多，海量数据的存储容量挑战大，传统的单机数据库难以应对海量数据的增长；\n- 第二，在数据集成层面，智能制造企业通常内部会有众多的管理控制类系统，系统间的关联性较差，容易形成数据孤岛，缺少统一的数据中台底座；\n- 第三，在数据应用层面，企业的运营决策报表、实时 BI 报表对于数据分析的实时性要求越来越高，传统的 T+1 模式不能够满足实时性需求。\n\n面对以上挑战，传统的数据库解决方案主要有：\n\n- 垂直扩容：在物理机层面通过垂直扩容 CPU 、内存和磁盘来缓解问题，但该方案治标不治本，无法从根本上解决问题；\n- 分库分表：通常使用分库分表中间件实现，但该方案也会带来一系列问题，比如缺乏弹性扩容能力、对业务有侵入性，以及对于复杂关联查询支持不够友好等；\n- 增加只读节点：只能有限地提升读取能力，数据写入压力依然落在主节点上，且传统的主备架构会存在数据同步延迟、主从切换维护复杂等问题。\n\n新一代分布式云原生数据库 TiDB 可以从根本上解决上面所提到的一些问题。TiDB 支持一键水平扩缩容和分布式事务，单集群数据存储容量可达数百 TB 规模，并拥有实时 HTAP 能力。借助 TiDB 这些特性，智能制造企业可有效应对数据获取、数据集成和数据应用等数据流动环节所面临的挑战。\n\n## TiDB 支撑制造业数据获取的场景\n\n![TiDB 支撑制造业数据获取层的场景.png](https://img1.www.pingcap.com/prod/Ti_DB_0077bcc82f.png)\n\n在数据获取层面，对于大型智造企业的信息管理类系统而言，TiDB 弹性水平扩展能力可有效解决单机数据库在计算存储资源不足时无法快速扩展的问题。而在很多中小型智造企业中，企业信息管理系统的数据通常存储在多种单机数据库中，单个数据库容量相对较小，难以充分利用硬件资源，同时维护多套数据库也增加了运维成本。此时可借助 TiDB 多业务融合能力（Placement rule in SQL），将多个管理系统数据融合在一套 TiDB 集群中，从而统一技术栈，降低硬件和运维成本。\n\n此外，TiKV 可以独立于 TiDB，与 PD 构成 KV 数据库（此时产品形态为 RawKV）。RawKV 可以绕过事务处理层，提供更高的写入性能和更短的 Latency，具备 Time-To-Live 功能，自动清理不需要长期存储的数据。相较于 TiDB 部署形态， RawKV 更加适合高频写入的物联网接入层场景，比如用于存储物联设备上报的信号数据。\n\n## TiDB 支撑制造业数据集成/展示的场景\n\n![TiDB支撑制造业数据展示层的场景.png](https://img1.www.pingcap.com/prod/Ti_DB_2131d559b4.png)\n\n在数据集成和应用层面，智能制造企业同样可以运用 TiDB 灵活的水平扩展能力，通过将多源数据统一汇聚，打破数据壁垒，解决数据孤岛问题，为智造企业提供融合统一的数据中台底座（比如实时数仓、财务中台等）。同时借助 TiDB 的实时分析能力，帮助企业更加快速准确地在工厂智造、产品营销等方面做出经营决策。\n\n另外，TiDB 6.0 正式推出的数据放置框架（ Placement rule in SQL 功能），可以在同一套集群实现海量数据的冷热存储，即将新的热数据存入 SSD，历史冷数据存入 HDD。该功能在智造企业的数据中台类应用场景非常适用，可自动归档中台历史数据，大幅度降低使用 TiDB 的硬件成本和运维管理成本。\n\n以上我们按照数据分层的结构，分别介绍了 TiDB 在智能制造数据集成、数据集成和应用展示可以支撑的业务场景，下面将通过三个具体用户案例来做进一步的说明。\n\n## 用户案例\n\n### 涂鸦智能——设备信息上报存储\n\n![涂鸦智能案例.png](https://img1.www.pingcap.com/prod/_ee020fae9f.png)\n\n涂鸦智能是一个全球化 loT 开发平台，基于全球公有云，实现智慧场景和智能设备的互联互通，提供从技术到营销渠道的全面赋能。目前，涂鸦在国内外已有超过十万家合作伙伴，生态客户数量达到 32 万+。\n\n在涂鸦智能设备信息上报存储场景中，其将智能设备的各种定时触发信息上报至涂鸦 Zeus 平台，这种方式的特点是数据量巨大，响应时间要求非常低。涂鸦早期采用 Aurora 方案，但很快就出现了无法支撑物联网设备数据暴涨的问题，即使采用分库分表也很难满足业务快速增长的需求。此后涂鸦智能又尝试使用 Apache Ignite 的方式，虽然解决了部分扩容问题，但又面临着 Apache Ignite 在扩容时需停机的挑战，而在物联网的业务场景中，很难提供停机维护窗口。\n\n为解决当前业务面临的痛点，涂鸦团队在市面上调研和测试一系列产品后最终选择了 RawKV ，而业务上线后也获得了诸多收益：\n\n- 通过 TiDB 一键线性扩展可以支撑涂鸦智能业务数据的暴涨，且满足零停机时间要求。\n- 在 RawKV 集群上线后 TPS 可以轻松突破 20 万，P99 时延在最低时可低于 1ms。\n- 出于节省硬件成本的考虑，后期将 RawKV 集群从 x86 架构换成 ARM 架构，整体硬件成本降低到原本四分之一。\n\n### 某智能手机制造商——供应链系统\n\n![某智能手机制造商——供应链系统案例.png](https://img1.www.pingcap.com/prod/_9171c6b482.png)\n\n该智能手机制造商会通过定时微批的模式实时监控整个产品生产物料和产能数据的匹配情况，由于系统和整体产线高度关联，该供应链系统需要保证 7×24 可用。最初该智能手机制造商采用的数据库架构是 PG 集群主备模式，但很快就遇到两个问题：1、单机集群模式很难支撑未来的数据增长；2、随着数据的增长，定时跑批任务耗时越来越长，让业务方难以忍受，同时会对集群内的在线业务有明显影响。\n\n![某智能手机制造商——供应链系统2.png](https://img1.www.pingcap.com/prod/2_ee4528ccdd.png)\n\n目前，该制智能手机造商使用 TiDB 整体替换了原来的 PG 主备架构，在业务上获得以下收益：\n\n- 通过 TiDB 的 HTAP 能力使得整套业务系统具备实时数据分析能力。\n- 缩短整个生产物料供应的时间周期，整个 SQL 查询任务的运行时间从原来架构的 30 分钟缩短到 10 分钟。\n- TiDB 能够有效支持大规模数据写入，单表存储可以达到百亿级别以上，轻松地支持系统每日数亿的数据增量，并在该数据规模下也能满足复杂查询的性能要求。\n\n### 某高科技汽车的制造厂商——实时决策\n\n![某高科技汽车的制造厂商——实时决策.png](https://img1.www.pingcap.com/prod/_b6affc8516.png)\n\n该车企以用户为中心，立足 DTC 战略，将实时决策平台作为最主要的战略洞察平台，主要供两类人员使用：\n\n- 面对 C-Level 提供全新实时业务决策能力；\n- 面向门店经理、销售等业务方提供实时报表分析能力。\n\n该车企原架构采用 ETL+Hive 实现 T+1 数据汇聚，再通过 Spark 、MR 夜间跑批，将结果写入 MySQL 供外部查询，明细数据会通过汇聚库来对外提供查询。原架构在改造前面临着如下痛点：1、整体技术架构复杂，运维开发成本高；2、原有汇聚数据库已经无法承载日益增长的数据量；3、明细数据和报表数据存在时间差，数据的准确性很难得到保证。\n\n![某高科技汽车的制造厂商——实时决策2.jpeg](https://img1.www.pingcap.com/prod/2_18ae95caf4.jpeg)\n\n该车企经过各方调研和测试后，最终采用了 TiDB 分布式数据库方案，并获得了如下收益：\n\n- 通过 DM 及 CDC 工具将销售订单支付、智能工厂、车库系统、智能算法等高价值的业务数据统一汇聚写入到 TiDB 中，将整体技术栈统一收敛到 TiDB 中，简化开发运维，使用标准 SQL 即可完成复杂的 AP 查询需求。\n- 该车企还借助于 TiDB TP 和 AP 的数据实时强一致同步，有效保障了业务实时统计分析数据和明细数据间的一致性。在将业务迁移至 TiDB 后整体性能也得到了 10 倍提升。\n- 基于 TiDB 的 HTAP 能力，该车企打造出一套全新的实时业务决策系统，帮助企业管理层快速做出准确决策，在瞬息万变的市场中赢得商机。\n\n## 总结\n\n如今，智能制造正成为世界经济全球化背景下制造企业的重点，传统制造企业纷纷在寻求转型为智造企业的方法，如何快速打通制造企业在数据获取、集成和应用展示的数据通路将成为企业转型成功的关键要素。\n\n而通过上面的案例解析，我们可以清晰地看到 TiDB 在智能制造的各个数据流动环节中都可以发挥其独特的价值，而随着 TiDB 整体产品形态不断丰富和完善（比如 TiDB Cloud Serverless），我们有理由相信 TiDB 将会在智能制造行业发挥出更大的价值，助力越来越多的制造企业迈向全新的智造时代！","author":"PingCAP","category":4,"customUrl":"practice-of-tidb-in-intelligent-manufacturing","fillInMethod":"writeDirectly","id":468,"summary":"文章通过案例解析，展示了 TiDB 在智能制造的各个数据流动环节中都可以发挥其独特的价值，包括数据获取、集成和应用展示等。随着 TiDB 整体产品形态不断丰富和完善，TiDB 在智能制造行业将会发挥出更大的价值。","tags":["TiDB","技术出海","智能制造"],"title":"技术出海｜TiDB 在智能制造中的应用实践"}}]}}},
    "staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}