CloudQuery 的过去、现在和未来

发布时间:2024年01月03日

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,但做出来之后,发现市场对于这类纯客户端的反应并不大,以某位老大哥的话来讲,这是痒点,不是痛点。正好碰到上海一个客户需要针对数据库做细粒度、精确的审计,同时管理用户对数据库的各种操作以及动态脱敏,于是我们「误打误撞」地跑到了数据安全赛道。

image.png

产品搞了,第一个客户也落定了,但每个接触过 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 就是唯一的一道门,且进出的路上有大量的安全配置。

image.png

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阐明下观点:

image.png

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

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

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

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

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

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

2、改进用户体验和效率

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

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

3、持续进化

image.png

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

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

4、走出去

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

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

七、花开叶落,初心不改

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

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

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

助手订阅号二维码.jpeg

文章来源:https://blog.csdn.net/weixin_46201409/article/details/135357635
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。