CloudQuery的过去、现在和未来

CloudQuery (后续简称「CQ」)这个产品从设计/研发到现在，一晃已经 5 年多时间了，在不断的完善中，也积累了不少的社区/企业用户，我意识到，CQ 已经从一个 Idea 变成了公众软件，开始有它的使命、责任和价值主张。很多用户（客户）非常关注 CQ 的进展和规划，作为产品的第一负责人，来跟大家说说 CQ 的发展历程，对过去做个总结，对未来做个展望。

一、CQ 的诞生

2018 年公司刚成立不久，我们框定了数据库领域，先后尝试了数据库代理(Proxy)和复制迁移，开始做 Web SQL，即把 SQL 客户端运行在 Web 上，因为我坚信绝大部分不需要本地复杂计算的软件都需要迁移到 Web 上，这样才能融合到整个云背景中，或者可称之为 Cloudware。

Web SQL 最初的产品名称叫做 Daios(Database All In One Studio)，目标是一个类似于 DBEaver 的 Cloudware，但做出来之后，发现市场对于这类纯客户端的反应并不大，以某位老大哥的话来讲，这是痒点，不是痛点。正好碰到上海一个客户需要针对数据库做细粒度、精确的审计，同时管理用户对数据库的各种操作以及动态脱敏，于是我们「误打误撞」地跑到了数据安全赛道。

产品搞了，第一个客户也落定了，但每个接触过 Daios 的人都不知道怎么念，拗口的名称极大得影响了产品的推广。考虑到这个产品的 Cloudware 设定，并且主要针对数据库查询类做安全产品，也考虑过叫 CloudSecureQuery，但为了便于称呼，最终定为 CloudQuery。

二、V1：艰难起步

在 CQ v1.0 时期，产品团队只有 3 个人，我们对于功能的规划是尽量「抓大放小」，即：

• 突出以权限为主的安全三核心，即权限、脱敏和审计。
• 在数据库操作上只支持 Query，数据仅保留公共的表、视图，最早期的版本连物化视图都没有，更不用说同义字、dblink等。
• 数据库的支持主要以「五大」为主，即 Oracle、SQLServer、MySQL、MongoDB 和 Redis（后来换成了 PostgreSQL）。

这个时期的产品虽然功能弱，但在技术上我们力求扩展性，坚持自研，并因此走了不少弯路，这是因为 CQ 的定位是一个门户类的平台产品，如果不关注技术，最终会被技术债吞噬。

一年多的探索下来，我们确定了一个数据库管控平台的几个核心技术点：

• 编辑器： 怎么适用于各种 SQL 的补全、高亮、格式化等。经过多方考察，最终确定VSCode 分离出来的 monaco。monaco 提供了良好的 api 和扩展点，比如 textmate 的高亮语法，以及用于编辑交互的 LSP。
• 结果集： 怎么处理 SQL 和未来 NoSQL 的呈现和交互。这需要一个强大且高效的 Grid，CQ 使用的是 aggrid 社区版。aggrid 提供了很多实现复杂后台交互的 api 和 callback。
• 数据源模块化： 为保证数据源并行开发，且互相不干扰，必须实现带隔离的模块化。这个模块我们参考 Tomcat 的 war 包扩展机制，实现了 CQ 自己的数据源模块化机制，内部称之为 Database Modular System，简称 DMS。每个模块可以有自己的元素列表，行为交互，特征列表（比如是否支持事务、是否有 Schema 等）。
• 细粒度权限控制： 最初的想法是做一个跟业务结合（比如限时、限量）的数据库权限中间件，以 RBAC 为核心模型，基于开源 Fortress（完整实现了 RBAC/ARBAC 97）去扩展。这个选型给我们带来了一些痛苦。一个是底层的 AphacheDS(后换成openldap) 不稳定，另一个问题是 Fortress 的 LDAP 存储模型与 CQ 默认的 PG 关系模型完全不同，无法便捷地进行数据关联。这些问题则加速了 CQ V2 大重构。
• 连接管理： CQ 作为一个 Web 综合数据库管理器，需要高效地创建、使用、回收各种异构多源数据库，并能够实时监控和分析。参考数据库面连接池（Pooling），我们结合 Web Rest 和自身业务需要实现 Connection Manager。
• 语义分析： 语义分析包含两部分，一个是前端的快速分局（Statement Splitter），这个好理解；另外是 Universal AST(UAST)，通过 SQL 语句分析判断用户执行的是哪个表、改的是哪个字段。这个从最初我们就基于 Antlr 来实现，因为 Antlr 有着大量的语言分析存量资产，且基本都是开源的，便于扩展。
• 审计分析： 基于传统的 kimball 模型做分析，列存使用了 PG 的扩展 cstore_fdw。
  现在看来，这个版本功能其实远离了数据库核心，且体验「处处漏风」，但也服务了 20 多个客户，我也分析了为什么它会有市场。

三、为什么 CQ 可以

任何一个能被认可的产品都是时代和环境的产物，这其中有 3 个关键因素影响了类 CQ 软件被接受并运用到实际数据生产中。

1、Cloud 时代

就需要大量交互的功能软件来说，Web 体验远比不上桌面，但是大中小都在上云，上云之后最好的软件形态就是 Webware，这里 Web 就是个云端数据中心软件的 Agent，理论上拥有可以连接和整合企业IT设施的无限能力。对比于单薄的桌面，功能上享受到的收益大于体验上获得的收益，这对高效工作很重要，比如 SSO，Dashboard，再比如 Portal 等等。并且随着前端技术的发展和浏览器厂家的海量投入，体验也在快速跟上。

2、数据崛起

随着互联网，特别是移动互联网的蔓延，世界的数据总量基本两年翻一番，这促成了数据相关的繁荣，比如存储、存取、转换、分析、安全、可视化等等，企事业开始接受对数据相关产品付费。数据对人们的生产生活影响越来越大，人们意识到，数据也应该像软硬件、网络设备那样被当作资产。上一代的企业 IT 资产通用保护装置「堡垒机」（或跳板机），主要用来保护主机和网络设备，无法有效&深入地对数据资产进行保护，当前堡垒机的不足推动了 DBA 和数据相关安全人员选择更为专业的数据管控类产品。

3、信创支持

多年来，国际巨头几乎垄断了中国的数字化基础设施基础软硬件，这既包含数据库/大数据，也包含繁荣的生态配套，就此共生了大概40、50年时间。随着全球 IT 生态格局的演变，迫使中国必须要建立基于安全的 IT 底层架构和标准。近几年信创产业的大力发展，逐步解决了一些关键问题的 0 到 1，但在一些配套和优化上仍是缺失。信创数据库是刚需，那么配套的客户端、复制迁移、监控以及安全等等也是刚需，这是独属于中国中小软件公司的机会。

CQ 会顺着这个路径继续完善下去，CQ 可以，我相信很多数据安全类的软件云化也可以。

四、ToB 与社区版

曾经一个做堡垒机的大佬说「在企业市场打死我都不搞免费和开源，这很不商业」，因为付出和收益不对等。

这几年的 ToB 下场实践，我发现愿意付费、能付费对客户项目的成功是一件好事，这能在最大程度上保障业务需求的贴合和产品的稳定性。但对于软件公司来说，除了点对点地服务好客户，市场上的声音更是推动产品发展和前进的「燃料」。

为了获取更多市场对于 CQ 这类产品的反馈和需求，我决定尝试社区这条路径。但由于对知识产权保护缺乏信心，所以我暂时放弃开源（opensource），而是选择免费路线（freeware）。我们能坚定不移地搞社区的原因，也有几点：

• 互联网一代站起来了： 过去的企业软件使用者/决策者更习惯通过会议、销售上门、平面媒体等方式获取产品及行业信息。而现在网络成为了获取信息的最重要方式。大家也愿意尝试和参与这类软件的建设，比如下载使用、评论反馈等等。
• 在市场触达上， 社区可以让 ToB 典型的两个组织的互动简化为两个人（使用者和开发者）之间的互动，能够提升产品版本迭代的同时，极大地降低了互动的成本和顾虑。
• 在技术上， 国外创新层出不穷对比国内的乏善可陈可能有很多原因。其中一个重要因素我认为是连接和互动。就跟大模型一样，连接点越多越强大，越容易「涌现」。把于此相关的人和事连接在一起，就是我期望社区达到的一个目标。这能够加速想法和反馈的流动，在软件技术或功能创新上或许会有更多可能性。

社区是个融合了我对技术、产品和市场看法的创新实践，期望能够在现实环境下以产品公司的底色发展壮大的同时，还能够提供最广泛的客户价值。

五、V2：大重构

经过两年各式项目的增强，CQ 无论外在还是内在都已「千疮百孔」，已经无法进一步支撑客户需求，思考再三，决定进行大重构。从开始编写目标到第一个 V2 客户测试，足足花了 1 年多时间。 而产品的变化主要来自三个方面：

1、定义的变迁

如果说 V1 的 CQ 是一个挂载了安全功能的简易数据库 Web 客户端，那么 V2 根据大量的客户沟通和实践，CQ 则被定义为「数据安全入口」。这个数据不仅指数据库的数据，也包括应用的数据、网络的数据、其他存储的数据等等。如果把数据仓比作一个园区，那么 CQ 就是唯一的一道门，且进出的路上有大量的安全配置。

2、功能扩展

功能上主要围绕两个面展开，一个是对数据库种类（包括 nosql）进行大量支持。截至当前，CQ V2 系列已经完整支持 28 种国内外数据库。 尤其是大数据库方面如 hive/vertica，已经成为很多企业数据开发人员的首选工具。同时我们也会在 V2 周期内实现主流国产数据库覆盖，既包括 OceanBase、GaussDB、达梦等 TP 数据库，也包括 TiDB、StarRocks、DWS 等 AP 数据库。

另外一个是围绕安全三剑客 “权限、脱敏、审计” 进行完善，其功能对标国内主流安全厂家的产品，其中：

• 权限控制除了常规的手动授权，增加了分级授权（管理大规模数据库有用）和自动授权机制，并提供权限看板，便于全局观察权限状态。
• 数据脱敏增加了数据仿真，即伪数据，并开发「简易静态脱敏」。
• 审计分析改进是这个版本的重点，把方方面面的操作比如导出、授权等都收纳入了审计，且对一些审计人员比较关注的维度进行了统计。除此之外，还增加了一些行为分析指标，如数据删除、越权等，系统可以根据指标设置进行告警。

在这个版本，我们已经有意识有计划地根据用户反馈改进操作体验，主要集中在导出、执行日志、结果展示、脱敏、审计展示等方面。

3、技术改进

能让我们顺利进行功能深度改造的核心是技术的大重构，我们几乎重写了底层所有的关键代码，主要包括以下方面：

• Pipeline 流水线： 针对不同的数据库类型、场景以及各种安全设置，形成不同的执行流水线。
• UAST 统一语法树： 用统一语法树改进结构 API，稳定解析相关的质量。
• DW 数仓： 基于 ClickHouse 的新一代数仓取代老式的 PG+ 列存扩展。
• 数据复制： 既可用于数据脱敏，也可用于以后的同构/异构数据库的表/列等复制。
• RDB 版本的权限中间件： 基于 RBAC/ARBAC/PRBAC 模型重写了权限中间件，为复杂授权提供有力支撑。
• 集群能力： 支持对各种关键组件的水平扩展，并与 K8S 兼容
• ......

六、V3：展望

虽然我们是「偶然」拐到数据安全领域的，但我们也发现，在当前阶段，数据安全还没有很好地被分析和对待。很大一个原因是安全行业的成功者基本都来自于网络安全领域，如果依旧用同样的技术手段、产品模式甚至商业模式去解决新的数据问题，就很难成功。

数据是什么？是业务承载，所以数据安全刨开技术问题，很大程度上是个业务问题。这意味着数据安全的解决方案要关注更多“层”面，用我的一张PPT阐明下观点：

或者说，数据安全需要以全栈或者平台的思路去解决，需要干一些「脏活累活」（目前正火的 AI 正好可派上用场) ，需要处理好通用性和可扩展性的平衡，这也是 CQ 在 V3 周期的主体思路。我们将会把 CQ 建设成为一个“数据安全平台”，沿数据生命周期，对各式数据进行高效接入和全面保护。

站在产品角度，安全虽然能合法合规，但经常会降低工作效率，为提升使用者的获得感，必须要通过提升效率来对冲安全带来的消耗，即不仅安全，还好用。围绕这个核心目标，我们将会继续做以下工作：

1、完善产品矩阵（1+N)

除了「入口」，我们将开发更多子产品，使之遍布在“园区”各处，更全面地满足各种场景，形成 「CloudQuery 产品家族」，即 1+N 体系。当前明确的主要有：

• SQL 审核： 实现在执行、变更等事前的审核，减轻 DBA 压力；逐步完善规则库，并可以根据数据元素一键配置。
• 账号分析： 通过分析应用、组织人员、数据库之间的账号关联，识别潜在的账号风险、比如弱密码、账号泄露、非法访问等。
• 应用脱敏： 在不改造应用的情况下，对应用按需/按用户进行动态脱敏，也就是俗称的业务脱敏。
• 静态脱敏： 完善 CQ 平台中的「简易静态脱敏」，将其建设为独立产品，可针对生产/开发，在线/离线进行拷贝式的脱敏。

后续还可能有 API 安全网关、数据分级分类、数据加密等等。

2、改进用户体验和效率

之前的版本，我们一直在「赶功能」，对于用户体验这一块有很多的负债。这个版本，我们将针对一些典型问题进行持续清算，主要包括：

• 定制安装： 提供模块化能力，用户可根据自己的需求，安装必须的模块，减少使用资源开销。
• 改善执行环节： 提升执行过程的效率，尽量减少安全计算带来的影响；对结果集进行更多选项和配置，方便定位和查看数据；以及日志、事务控制、进度等等。
• 场景化的权限配置： 根据行业、管理团队大小以及所在组织的管理习惯，能够匹配更贴近的权限管理模式，比如主/客授权、批量自动模式、审批流程等。
• 审计告警： 对用户的数据操作行为，增设更多的审计指标，并加强告警及处理机制。
• 数据复制： 可以在同构和异构数据库之间拷贝列、拷贝行、拷贝表和 schema 等。
• 结果展示： 增强 json、图片、文件、空间、网页等结构的呈现，进一步完善对大数据的支持。
• 流程改进： 为各种操作流程增设更多的自定义环节。

3、持续进化

CQ 将会沿着图尔兹的产品战略持续进化，持续带给用户更多的价值：

• 运维效率相关： 原生 K8S 支持、更丰富更完整的 OpenAPI/SDK、自助诊断、智能调度、SQL 分析和建议。
• 安全相关： 提升敏感数据的识别和关联、高危动作及风险分析、数据的分级分类/资产标识/目录、数据监控和态势。
• 信息的关联： 围绕数据主体和使用人对信息进行更全面的链接、聚合。

4、走出去

社区运营的过程中，陆续有人希望我们推出英文版，当前英化已经搞定，这个季度我们会在国内外发布英文版。另外从 2024 年开始，将正式出海推广，并尝试支持更多的语言，比如西班牙语、日语等。希望通过跟国外同类产品同台竞技，为用户带来更多的可能性。

在产品更完善的同时，我们能坚守的承诺就是社区只会越来越开放，一些企业级功能会逐渐下放，开放文档会更细节。 此外，我们也会吸纳外部公司/开发者，以源代码共享的模式共建一些扩展功能模块。

七、花开叶落，初心不改

最初搞这个产品时，是希望安全类的产品除了合规，也能好用，更立体地解决用户对数据的关切。但在行业呆久了问题变成另外一个：做软件尤其是技术软件怎么在当前环境下，保证生存发展的同时还能坚持创新？这是软件创业者共同面对的难题。

软件在国内 IT 史里除了零散的喝彩，从来没长时间雄起过，甚至在向“人天”和准外包剧烈地倒退。社会要进一步发展（提升效率），各行各业细分的高质量软件必不可少，甚至比 AI/大数据重要的多，而搞好软件的关键是人才及创新精神。

人才需要利润支撑，在温饱都不普遍的情形下如何获取？创新如果缺乏法律和文化的坚实保护，又该如何有“技巧”地落实？这需要坚定的战略，也需要灵巧的步伐。走了 5 年多，我们还是要坚决的突破，最大化地连接技术、云、互联网和社区等要素，走出一条可复制的软件路来。