近期，我们为海外某国最大的银行进行了分布式数仓 PoC，并最终赢下该项目。该项目的现场 PoC 经历让我们第一次从国外客户的视角审视了数据仓库究竟要满足客户的什么需求，给予了我们很多启发。
接下来，我们会通过详细介绍 YMatrix 在该项目现场 PoC 的一些经历与思考，和大家分享我们认知到的海外客户对数据库的不同产品观和评价体系。
客户是某国 Top 1 银行， 当前使用 Oracle 作为数据仓库，主要支撑报表、BI 工具的分析型查询。
作为一个典型的金融行业数仓，客户的主要工作流程是：
夜间增量同步：业务低谷时段，将当天业务数据同步到数仓；
数据加工：在数仓中进行数据的清洗、计算和加工；
次日查询：早晨工作日开始后，用户通过报表和 BI 系统访问数据。
该银行客户在关于数仓建设方面的经验非常丰富，经过几轮沟通，最后由客户主导确定了测试内容。整个测试内容没有使用任何 Benchmark, 均是根据直接的业务需求和痛点设计，所有测试数据和测试查询均直接来源于生产环境，可以说简洁、全面、务实的特点，同时也为每个测试项设计了可衡量的标准。
数据摄入
客户每天夜间同步的数据占用约 50% 的时间窗口（约 4 小时），白天还有部分 UPDATE/DELETE 操作。因此，客户主要关注数据加载性能，并关注是否具备 UPDATE/DELETE 能力。
同时，根据规划，原来由 Hadoop 承载的 ODS(贴源层）数据未来也会纳入到新的数仓中，因此数据量在未来3-5年将大幅增长。因此，数据压缩比作为评估存储成本的重要指标，也被纳入为重要考量指标。
数据加工与查询
性能是此次测试的关键。根据实际数据加工与查询负载，客户提供了数个关键 SQL，既有数据加工类的超大查询，也有上层应用生成的中小体量的分析型查询。
在所有测试查询中，最为关键的一个 SQL不但涉及数据量大，需要对数十亿行的大表的与千万~百万行级的小表的 JOIN，且逻辑复杂；该在原系统中无法一次性完成执行，必须拆分成小区间分别计算后再合并计算结果。
最终的采用的测试方案是，在 1，10，100并发条件下，计算所有查询使用不同条件执行 100 次的总时间，以此评定数据库性能表现。
其他功能
除了数据加载和查询性能测试，测试用例中还覆盖备份与恢复、高可用、对象存储和扩容能力，甚至性能和易用性。这些功能测试，不简单是支持或不支持，也引入了量化的指标，比如备份和恢复分别用时，扩容的耗时等等。
两周的测试过程并不简单，YMatrix 最终成功 PK 掉了国外知名分析型数据库赢得项目。在现场与客户反复沟通的过程中，我们也发现海外客户在 PoC 的目标和设计逻辑上，和我们过去经历的项目有着诸多不同之处，他们更关注使用者的“真实感受”。
数据与 SQL 高度拟真
客户提供的测试数据和 SQL 与生产环境完全一致，仅对敏感信息脱敏。而过去，我们在国内的许多项目目的测试中，为了简化测试流程，降低对生产环境的影响，经常通过程序自行造数，或借助一些经典的 Benchmark 对性能进行测试。
虽然这样的测试也能很大程度上反映产品的功能和性能表现，但终究和实际生产环境一致性差距较大，因此一旦投产，也很可能出现和PoC测试表现不一致的情况。以压缩比为例，造数程序可能会生产出规律性比较强的数据，从而导致PoC中得到非常高的压缩比结果，而一旦投产，这个压缩比可能就大打折扣，导致实际硬件需求和估算的相差较大。
关注最差情况
针对客户提供的最复杂的SQL, 我们进行了深度分析，发现实际由于敏感字段的缺失，导致该SQL 需要进行大量无用的数据扫描，而如果进行一些调整和重写，速度能够大大加快。在与客户进行确认后，我们得到的答复是：“没关系，我们了解这个问题，在测试中，我们更想知道你们在最差情况下的表现。”
这一逻辑也是我们在过去的项目中从未见到的，也让我们大有启发。通过观测最差情况的表现，就能够通过PoC明确未来在最差情况下系统表现是否满足最底线要求；由于绝大多数情况，效果总会好于最差情况，如果最差情况都能够满足设计要求，那么投产后效果只会更好而不会更差。
这种逻辑能够最大程度发挥PoC价值 ——摸清产品在生产环境中的实际表现。
不依赖深度调优
SQL 编写是一个技术活，特别是在分布式数据库中，同一个逻辑 SQL 通过各种调参性能经常能够提升数倍数十倍。在不少项目的测试过程，客户更关注最佳性能表现，所以在很多项目中，针对SQL进行调优和等价重写是非常普遍的。
然而在此次PoC中，客户明确表示“我们是来测试产品，而不是测试你们的调优技能的”，并在开始明确表示不能使用任何调优手段。虽然在后面的沟通过程中，客户认可了使用hint 以及调整部分参数调整，但是始终禁止改写SQL。理由是未来使用产品的是普通用户，并不具备专业的 SQL 编写能力，也很难写出“完备”的SQL，因此，基于重写 SQL 和深度调优即便能得到最佳的“跑分成绩”，也不能代表产品在真实使用中的效果，与 PoC 目标不符。
安全与合规是强要求
流程方面，除了开始的各种保密协议等，在PoC过程中，我们向服务器上传任何文件都需要经过严格审核；数据方面，源于真实的生产环境的测试数据与SQL，包括列名在内，都进行了非常严格的脱敏，以确保数据安全；在功能测试方面，除了测试高可用性，备份恢复等功能，在包括对象存储功能在内的所有涉及网络连接的测试，都要求使用 SSL, 以保证未来在实际使用中能够符合数据安全的要求；除此之外，客户还针对该国的法律要求，设计了关于数据脱敏、审计等功能的测试。
这次海外项目经历，让我们得以以全新视角思考到底达到什么样的要求，才算是一个合格的数据库产品。
性能表现的下限比上限重要
作为研发人员，很多时候我们可能更关注单点的技术突破，比如某类查询的加速，或者某个 Benchmark更好的得分，而衡量一个数据库的性能，仅靠单一查询、性能性能的上限可能是片面甚至远远不够的。
在真实的使用环境中，用户对于产品的抱怨，一定是源于那个跑了数十分钟，甚至数小时的 SQL, 这它才是是影响用户体验最大的因素，而对于分析型查询，很多情况下一个 SQL 从 数秒 加速至几百毫秒，并不能够明显提升用户体验。
查询无论写得好坏都要得跑的了跑得快
不可否认，通过提供灵活丰富的参数和调优手段，让深度调优后的 SQL 跑出最佳成绩，能够一定程度体现出一个数据库产品的产品力，然而这与实际的用户体验还有很大差距。
实际使用数据库的用户，很多时候都不具备写出最佳 SQL 能力，只有不断降低使用 SQL 的门槛，让绝大多数会用 SQL 的基础用户的人编写的查询都能跑的出，跑的快，才是最能够影响用户体验的关键产品力。就像家小区门口的饭馆，要想经营的好，关键不是能够出品米其林级别的菜品，而是能够做到道道不踩雷。
没有完善的安全能力，产品会被一票否决
金融行业相较其他行业有着更为严格的合规要求，且不同国家和地区需要遵循不同的法规，例如凡是需要处理欧盟数据的企业，不管是否是欧盟境内的组织，都必须符合 GDPR 标准，因此，许多数据安全与合规功能，不仅是必须的，且涉及的细节很多。但无论是在哪里，类似透明加密（TDE)、数据脱敏、审计等都是必须的功能，这是产品能落地海外金融行业的前置条件。因此，在基础的产品能力之上对于安全合规方面法规的深入理解，相关能力的加强也是在数据库产品出海过程中必须增加投入的方向。
真正优秀的数据库产品，应该让用户“用得放心”，而不仅仅是“跑得炫目”。从某种意义上说，这次赢单不是一次性能竞赛，而是一场价值观的双向选择。
对 YMatrix 来说，出海并不只是产品走向海外，更是对做事方式的一次检验。海外金融客户在 PoC 中所坚持的标准，与我们对数据库长期价值的理解高度一致：以真实业务场景为前提，以稳定的性能下限为目标，并将安全与合规视为产品设计的基础，而非附加条件。我们始终相信，数据库能否走得远，取决于它是否能够在真实业务中持续兑现对客户的承诺。
YMatrix 期待以长期主义与工匠精神，持续服务好真实业务场景下的全球客户，让数据库成为一项真正值得长期依赖的基础设施。
