【全球云观察 ｜ 科技热点关注】
“虽然业务已经布局全球的企业仍以大企业为主，但是63%的中小企业已开始计划出海。”这是亚马逊云科技《中国企业出海现状和意愿》的调研数据。
然而，所有出海的大企业、中小企业走向全球化，如何实现更快速，更有韧性，更灵活的发展之路，这是摆在大家面前的重要课题。
在现实中，外部环境变得越来越复杂，许多企业都渴望成功出海并走得更远，那么，这就需要企业找到开展业务全球化运营的关键钥匙。
说来也巧，前不久，专业分析机构沙利文联合PingCAP发布了一份《中国企业全球化运营白皮书》，为大家找到了关键钥匙。一致认为：AI、数据技术、云计算三大技术是出海企业提升数智化进而实现全球化运营的关键支撑。
全球云观察分析指出，当数据业已成为企业的资产，企业要出海，数据必先行。有了数据价值的洞察，才能走出去开疆扩土并实现再创新；没有洞察数据价值的能力，出海可谓寸步难行。因此，对于当前的出海企业而言，数据驱动成为了新的商业发展趋势。
「数据驱动创新」，一场大变革才刚刚开始
数据驱动成为新商业规则，并非是一个偶然。
你也想出海，我也想出海，企业要出海，数据成了引擎。但出海企业面临与数据相关的痛点，你是否都了解？
对此，PingCAP首席解决方案架构师房晓乐分析指出，传统开发范式开始巨变，业务开发范式越来越由数据驱动，开发创新逻辑也随着改变。以前的旧逻辑是从业务需求到应用场景再到数据支撑，这是一个线性思维。现在面临出海的新现实，从数据洞察到场景创新再到业务重构，形成一个闭环的驱动体系。
比如一个电商出海企业，通过用户行为数据的洞察与分析，反推产品创新，然后再将创新后的产品推向海外市场，成功之处在于数据驱动对业务开发范式的创新价值越来越高。倘若这样的电商企业出海继续按照从业务需求到应用场景再到数据支撑的旧逻辑行事，不仅很难找到更适合自己发展的海外业务机会，同时也难以快速找到产品创新的新机遇。即便有可能根据海外用户需求找到自己的市场机会，但如何快速构建创新应用场景，并实现快速的数据支撑，更关键的是没有数据支撑如何构建新产品。
既然业务开发范式越来越由数据驱动，那么数据架构就至关重要，但是令人心痛的是数据架构选型的惯性思维带来了隐性成本问题，比如说，大家知道 MySQL 在互联网时代被广泛使用，尤其在中国有很好的生态和从业者，但今天很多数据密集型的场景，MySQL 并不是最佳选择，反而 MySQL 过度使用会带来“三高”问题，集群规模增长高、数据副本无序扩大高，数据技术栈治理复杂度高，而这“三高”是影响很多企业实现范式变革成败的根本原因。
需要明确的是，在企业组织中，不同部门或系统之间存在数据不一致、难以共享或冗余的问题。由于技术架构、数据存储和接口集成等问题，导致不同信息系统、业务部门或数据存储之间相互隔离，数据无法顺畅流通、共享和整合，形成数据孤岛化，导致机会成本可能相当高昂，并影响企业的效率、决策、扩展、客户体验等各个方面。比如零售出海企业，线上线下数据的流通、共享与融合，对其业务拓展意义重大。否则，零售企业出海举步维艰。
企业出海走向全球化，不仅要首先考量这些痛点，而且也需要重视基于数据的开发范式的变革，拥抱数据架构的发展趋势。
回顾过去的十多年，展望未来五年，数据架构演进的三次革命你是否都清楚？总结起来就是，原生分布式、云原生、AI原生。
数据架构变革的分布式觉醒发生在2010年前后，原生分布式架构（Distributed-Native Architecture）带来弹性基因，让在线扩缩容变得容易，实现多活容灾也成为现实，分布式架构有效的解决了数据大容量与数据访问高吞吐量的问题，在这个基础上，数据技术还是加速进行“三大融合”，包括 HTAP（TP与AP融合），多模（结构化数据与半结构化数据融合）、数据融合（多租户、多业务模块的融合），“三大融合”才是解决“三高”的关键路径，能从根本避免数据集群规模过大、数据副本无序扩展、数据技术栈过多的问题。
到了2015年前后，云化浪潮汹涌而来，云原生(Cloud-Native)带来敏捷进化论，存算分离架构成为了业界热点，秒级弹性不再是挑战，充分利用Kubernetes（K8s）的原生特性，构建弹性、可扩展、高可用和易于管理的应用系统成为行业发展大趋势。
数据技术在云平台上，继续进化，基于三大发现进行了结构性提升。
一是，更加极致的弹性。业界称之为 Database Serverless，可以根据业务需求，随时启动集群、扩容集群、关闭节点等。
二是，成本结构性下降。云上对象存储（比如 AWS S3）已经是存储的新的事实标准，新一代数据库可以将更多的数据， 比如冷数据放置在对象存储上，进而实现结果性的成倍下降。
三是，资源使用效率提升。数据库尤其是关系型数据库，有很多约束（Database constraints），维护这些约束需要大量额外资源和后台任务（比如 DDL、LSM Compaction 等）。在云时代，这些后台任务可以尽量剥离出来，比如，我们可以通过在 S3 上独立进行LSM Compaction，最终大大提升常用数据资源的使用效率。
从原生分布式到云原生，数据架构变革从中得以创新，然而到了2020年智能化涌现时，AI原生（AI-Native）的到来，以前所未有的力量，驱动着数据架构范式的跃迁，从人工规则升级到模型驱动。从而，数据库技术找到新的三大发展方向。
方向一，通用数据库将接入向量引擎、图数据库引擎、全文检索等。
方向二，数据库的计算能力将成为核心竞争力包括优化器增加加算子能力丰富，优化器能识别更多存储引擎并更加智能。
方向三，SQL仍然具有强大生命力，同时SQL将与机器学习融合，逐步实现用 SQL完成AI任务。
由此而言，从数据库选型不合理（比如 MySQL过度使用）带来的“三高”影响，成为企业实现范式变革成败的根本原因。到数据技术加速进行“三大融合”，致力于解决“三高”问题。然后在云平台上，数据技术继续进化，基于三大发现进行了结构性提升。如今，AI原生（AI-Native）驱动着数据架构范式的跃迁，数据库技术终于找到了新的三大发展方向。数据架构三次革命性的演进过程，就是数据库技术每一次创新的精彩展示。
房晓乐再次指出，TiDB 以原生分布式的开源数据库为起点，现在已经完成原生分布式×云原生的进化，正在进入原生分布式×云原生×AI就绪的阶段。
TiDB起初以分布式奠基，采用分布式内核，实现实时HTAP，同时通过云化重构支持云原生，开放多云就绪，在多个公有云上呈现一致性的用户体验，进而支持用户的Serverless化。Serverless部署模式让出海企业能够根据需求灵活组合模块化、API化、即插即用的服务，无需担心底层技术的管理与维护，从而专注于业务开发，显著提高效率和资源利用率，同时降低资源开销，提高投入产出比，让成本投入聚焦于出海及全球化发展的业务价值。
随着AI融合，采用AI增强的智能引擎，支持千亿级非结构化数据的向量化检索，时序预测自动扩容，提升资源利用率。还有内置自适应智能选择索引功能，有利于用户提高查询效率、优化决策过程。从而，TiDB为出海企业带来了商业价值转化的创新路径，通过实现数据实时性，提升决策敏捷度，构建市场响应速度的正向循环。加上采用金融级数据强一致保障方案，为出海企业提供更优的风险防控体系，实现数据安全出海。
事实上，数据驱动创新并不能一蹴而就，数据架构演进历经原生分布式、云原生、AI原生的三次进化，这是一个整体的系统工程。随着开发范式、数据架构思维与趋势都出现新变革，AI正在重构众多行业，这场变革已经拉开帷幕。
「出海企业到底想要500辆小轿车」，还是10辆大巴车？
既然数据驱动创新成为了全球科技行业的大变革与大趋势，那么出海企业如何驾驭自己的发展，遴选数据库是要500辆小轿车还是10辆大巴车更合适？
既然要选择，那么先明确一下小轿车与大巴车的区别可好。初步一看就是一个小、一个大而已，然而，进一步分析具体载客量大小、设计用途和出行服务效率，两者却有着很大的不一样。
在载客量大小上有着大不同：小轿车的载客量有限，车身尺寸设计较小，一般为5到7个座位，倘若车主想让更多的亲戚朋友同车同行，小轿车实难满足不同数量的乘客出行需求，只是适合人数较少的三三两两家庭成员出行。
大巴车的载客量较大，车身尺寸也设计较大，一般在20座以上，也有30-60座，既可以满足少量乘客出行需要，也可以一次性满足大量乘客出行需求。
对于出海企业来说，首要考虑车载客量能否可大可小，才不至于因为人多人少而不停换车。这好比数据库的架构弹性，弹性是基础设施核心问题，这是业务敏态开发范式具化要求之一，关乎出海企业现在联结未来发展的成败。以业务增长的发展眼光来看出海，虽然当下发展对每个企业都很重要，但是拥有未来眼光的企业才能在纷繁复杂的出海业务上获得长足发展。
在设计用途上有着很大不同：小轿车设计为个人或家庭日常出行需要，很难融合不同家庭类型的乘客，更不要说是不同出行目的的乘客，不同居住位置片区的乘客，不同旅途需求的乘客。小轿车偏个性化的单一用途明显，很难融合更多乘客的用途需求。
大巴车可以融合不同出行目的的乘客，不同家庭类型的乘客，不同居住位置片区的乘客，不同旅途需求的乘客。大巴车内所有设施、公共资源满足车内乘客的共享使用。从设计之初，大巴车就融合了不同乘客的用途需求。
对于出海企业而言，不仅需要架构弹性支持业务的敏捷发展，而且需要一个融合不同乘客用途需求的大巴车那样，具备更强的数据融合能力，将业务数据融合在一起，以此支撑业务创新的敏捷。
针对多业务模块的数据融合，通过将不同业务模块的数据整合到一个统一的视图或数据库中，以便进行深入分析，以及实现跨业务的数据洞察。作为一种分布式NewSQL数据库，TiDB可以作为一个强大的平台来存储和查询不同业务模块的数据，如商品数据、订单数据等。
针对不同数据类型的融合，涉及到不同数据类型之间的转换，兼容不同的数据类型。TiDB的多模设计支持多种数据类型，包括数值、字符串、日期时间、JSON等类型，可以按照不同的应用需求选择合适的数据模型。对于需要复杂查询的应用，继续使用标准的SQL模式。对于需要高性能键值操作的场景，可以利用TiKV的键值API。对于时间序列数据的应用处理，可以借助时序数据库特性给予良好支持。对于需要存储复杂文档的应用，可以使用JSON数据类型。出海企业可以通过TiDB实现多模一体的数据架构，利用其强大的功能和灵活性来满足多样化的业务需求。
针对不同数据分片的融合，TiDB实现了冷温热数，因有兴趣试用TiDB Cloud的业内朋友可以点开文章末尾的阅读原文。为数据库的访问频度、SLA等级随数据热度的降低而降低，按照热、温、冷水平拆分三类集群，在分片规则上引入了相对时间、绝对时间的概念。只有热、温集群间涉及数据ETL作业，保证热集群的容量相对稳定，温集群预留足够空间，满足业务创新的敏捷扩展。
针对多租户的融合，独立数据库是一个租户独享一个数据库实例，租户的数据彼此物理不可见，租户间更难实现数据共享。出海企业往往有不少从事SaaS业务，由于SaaS同时支持多个租户，每个租户又有很多用户，这对支撑软件的数据库平台的性能、稳定性和扩展性提出很大挑战，需要平衡数据的共享、安全隔离和性能的关系，达成多租户的数据融合。
现在看来，PingCAP的TiDB就是一辆数据库领域的大巴车。作为一款同时支持在线事务处理（OLTP）与在线分析处理（OLAP）的融合型分布式HTAP数据库产品，不仅兼容MySQL协议和生态，支持在本地和云上部署，而且TiDB在向量数据库能力方面也不断突破。2024年6月，TiDB Cloud Severless率先支持向量搜索特性。目前，TiDB引入了向量数据类型和多个向量函数，支持存储高达16383维的向量。
作为大模型的外置数据“大脑”，向量数据库结合AI大语言模型LLM，可以更好实现语料的持久化存储。为此，TiDB Servelress作为AI就绪（AI-Ready）的新一代数据库服务，不断完善AI结合的能力，支持向量搜索，让MySQL用户可以直接在TiDB数据库中方便构建RAG(检索增强生成，Retrieval-Augmented Generation）相关的AI应用。
在房晓乐看来，作为业务敏捷的第二大关键，数据融合也是大势所趋。在数智化时代，数据来源广泛且形式多样，HTAP（混合事务分析处理）、多模一体、向量与关系数据一体、多租户融合等各种形式的数据融合都避免不了。唯有通过数据融合，企业才能打破数据孤岛，将不同类型、不同来源的数据整合在一起，进行综合分析，从而获得更全面、深入的洞察。例如，将交易数据与客户行为数据融合，能为企业精准营销提供有力支持。这也充分表明，数据架构技术伙伴应拥有先进的数据融合技术与工具，帮助出海企业实现数据的无缝对接与深度融合，释放数据的最大价值。
数据一箩筐，什么都可往里装。出海企业通过TiDB数据库平台，将业务数据融合在一起，寻求海外的业务创新也就有了新底气。
或许，在这个时候，不少朋友已经看出来了，大部分出海企业因实际业务发展的敏捷性需要，选大巴车似乎更稳妥，而非多辆小轿车。毕竟大巴车拥有的架构弹性与数据融合能力更为强大，这正好也是实现业务敏捷的两大关键能力。
不过，别急，这还没比完。在出行过程中所有乘客享受的服务效率不同：小轿车更注重乘客的个人舒适性和个性化审美需求，比如搭配多功能座椅与豪华内饰，但是小轿车空间较小，运输行李有限。在出行过程中，同行者下车寻求公路服务站设施才能实现喝茶、用餐、洗手、如厕等需求，这需要时间上的等待，无法随时随地在车上实现。小轿车的低下服务效率好比开发传统范式，一切需要在出行途中去实现，出海企业的业务逻辑和计算大部分通过应用开发层来实现，其结果不仅周期长，成本也大。
大巴车对于乘客出行服务考虑更全面，在大巴车内配备行李舱可以实现多件行李同步运输，高端大巴车还有豪华内饰和功能性设施，满足旅途中乘客在车上享受移动WIFI、茶水、餐食、洗手间等需求。更有甚者，大巴车还有配置单人床，满足长途乘客的躺平需要。在大巴车这样一个平台上，可以完成数人的出行需要，整个出行效率获得明显提高。
采取计算下沉的方式，让更多的业务逻辑和计算在数据库或者数据架构中完成，这就好比大巴车一样，乘客旅途吃喝拉撒睡都可以在车上灵活完成，不需要下车，更不需要等待。如此一来，整个业务的开发效率会大大提升。对于出海企业而言，通过采用计算能力强的数据架构，选择距离数据更近的地方进行计算，实现计算下沉，应用开发的复杂度将获得大幅度降低，提升了整个业务架构的敏捷性。
由此来看，为了满足出海企业的业务敏态发展，架构弹性、数据融合、计算下沉三大能力一个都不能少。架构弹性是首要基础，而数据融合是核心能力的集中体现，同时对于计算下沉能力的重视，也将成其为未来的核心竞争力。载客量大小好似架构弹性，设计用途好比数据融合，出行服务效率犹如计算下沉。到底选小轿车，还是大巴车，到这个节骨眼儿上，你是否觉得一切都变得豁然开朗了呢？
题外话：假如出海企业已经有了小轿车，突然心血来潮，想要更换大巴士，该如何是好呢？别急，TiDB对MySQL数据库协议有着很好的兼容，同时还提供数据库迁移系列工具，保障出海企业数据迁移安全，提供基于整个数据生命周期的解决方案。此外，有兴趣免费试用TiDB Cloud的业内朋友可以点开文章末尾的阅读原文，按照页面指引进行即可。
「出海风高浪急」，三大要素不可少
即便富有眼光的出海企业，从一开始就选择了大巴车，然而出海发展业务和在国内地区还是有所不同，受到国际氛围与全球经济影响，外部环境毕竟越来越复杂，在风高浪急中如何把船开得更稳当，就显得非常重要。这在很大程度上，决定了企业出海能否劈波斩浪，扬帆远航。
为此，房晓乐分析指出，企业出海想要行稳致远，三大要素不可少，开源与多云、全球服务体系，以及数据合规与安全，每一样都值得重视起来。
第一要素，不能被技术绑死，必须考虑开源与多云。
在企业出海过程中，企业应优先考虑开源与多云策略。开源数据库可以为企业降低技术绑定风险，开源技术以其代码的开放透明性、社区的广泛协作性和开发的高度可定制性，为企业带来更多的信任与可靠性。通过开源，企业能够深入了解技术细节，根据自身应用场景和数据处理需求进行优化，避免因依赖单一商业数据库技术而出现高昂的许可费用投入，保持技术选择的灵活性，降低未来技术优化与升级的风险。
PingCAP自成立初就以开源为核心发展理念，所有的商业性选择都建立在开源之上。产研都是基于开源体系和社区持续发展。由此诞生的TiDB产品不仅能快速地获取反馈，而且理解并应对全球用户不同需求，建立起用户的持续信任。目前，PingCAP已在全球范围内与大规模的社区用户与商业用户形成连接，驱动TiDB在真实场景下持续演进。
同时，多云策略与云中立性有助于出海企业避免单云锁定（lockin）。不同云服务提供商在功能、性能和价格上各有优势，采用多云架构，企业能够根据业务需求灵活选择最合适的云服务，降低成本，提高业务的稳定性与灵活性。数据架构技术伙伴应具备丰富的开源技术应用经验和多云架构搭建能力，助力企业在开源与多云的道路上稳步前行。当前，TiDB提供了多云支持，企业可以根据业务需求和合规性要求灵活迁移。
第二要素，全球服务体系尤其重要，本地化技术支持更快速及时有效。
对于出海企业来说，拥有一个具有全球服务体系的合作伙伴至关重要。在主要区域具备本地服务，意味着企业在海外运营时能够获得及时、有效的技术支持。通过全球服务体系的支持，有利于降低跨文化协作成本，本地团队对市场环境和客户需求的深度理解，可减少沟通误差，能够快速响应企业的数据架构需求，解决技术难题，提升技术落地的精准性。
值得注意的是，专业的数据架构选型和容量规划服务能力也不可或缺。数据架构技术伙伴应根据企业的业务特点、发展规划以及海外市场的实际情况，为企业量身定制最适合的数据架构方案，并精准规划数据存储与计算容量，确保企业在数据架构方面的投入既满足业务需求，又实现资源的最优配置。
基于开源触达全球大规模用户的基础，PingCAP通过不断完善全球化组织架构与多元生态体系，打造面向全球的商业模式，已经在欧美日发达经济体和亚太新兴市场都获得客户和市场认可。
一方面，多元生态有助于理解并适应不同地区的市场需求。如PingCAP通过亚马逊云科技等全球云厂商的生态协同，快速接入全球区域市场的主流技术栈，加速企业全球化部署。
另一方面，全球组织架构使PingCAP能更好地提供本地化服务。PingCAP在东京、新加坡、阿姆斯特丹、硅谷等海外多地构建了本地化客户服务体系，能够为全球化企业提供本地化的技术支持，帮助企业更好地应对出海过程中的技术挑战。
目前，PingCAP正在持续优化和增强TiDB Cloud的能力，为出海企业低成本敏捷实施全球化战略提供支持。TiDB Cloud Serverless等新形态的推出，助力出海企业能够将更多精力投入到核心业务创新上。
第三要素，数据合规与数据安全，已成为全球范围内企业运营的生命线。
出海企业拓展海外业务，实现数据库应用的落地，合规安全必须放在第一位。不同国家和地区对于数据保护、隐私政策等有着严格且各异的法规要求。如欧洲的GDPR、中国的《数据安全法》，以及ISO质量体系等。数据是出海企业的命根，也是出海企业的资产，很显然数据安全非常重要，实现备份与容灾机制也是拓展出海业务的刚需，以及注重做好数据加密、审计等也十分有必要。
因此，出海企业遴选的数据架构技术伙伴必须具备全球合规和安全保障能力，熟悉各国的数据法规，采取先进的安全技术手段，确保企业数据在存储、传输和使用过程中的安全性与合规性，并能快速响应与合规适配。如PingCAP在东京、新加坡、阿姆斯特丹等关键区域部署本地团队，能够实时响应企业需求，结合当地数据安全法规，如欧盟GDPR、东南亚数据本地化政策等，优化技术方案。
此外，携手云厂商共建合规工具链，如AWS合规加密工具与PingCAP的TiDB密钥存储管理结合，可以更好地自动化满足各地区数据隐私法规。PingCAP还构建了数据审计工具，便于出海企业快速获取数据审计资料，节省审计资料提交时间，
据《中国企业全球化运营白皮书》分析，国家发出“一带一路”倡议，并出台鼓励中国科技企业出海的政策，出海已经成为一种新的企业时尚，一些企业出海不足5年就已经获得快速的业务增长，出海真的可以遇到蓝海。可见，在新一轮发展浪潮中，企业出海已成为拓展市场、增强竞争力的重要途径。想要实现劈波斩浪，不仅要重视开源与多云、全球服务体系、数据合规与安全三大要素，更要将每一项落到实处，方能直挂云帆闯蓝海。
「小结」：顺势而为，扬帆远航
无论是中国企业全球化和海外企业全球化，出海企业遴选数据库技术伙伴，首先需要明白自己的刚需，顺应数据驱动的大变革趋势，选好属于自己的大巴车。从开发范式的变革到思维的转变，从拥抱数据架构发展趋势到满足业务敏捷的各项要求，从开源与多云策略到全球服务体系与合规安全保障，做好多重考量与准备，每一个环节都紧密相连，关乎企业出海的成败。
一旦选择了合适的、富有前瞻性的、拥有全球眼光的数据库技术伙伴，企业才能在海外市场发挥出数据驱动的潜力与价值。毕竟出海业务说变就变，不仅要考虑眼前需求，而且还要考虑业务获得发展后的变化。
因此，风高浪急不要怕，风浪越大鱼也大。扬帆远航，做大做强。对于企业出海遴选数据库技术伙伴，你还有什么建议，欢迎一起来讨论。
- END-
你怎么看？
欢迎文末评论补充！
【全球云观察｜全球存储观察 ｜科技明说｜阿明观察】专注科技公司分析，用数据说话，带你看懂科技。本文和作者回复仅代表个人观点，不构成任何投资建议。
