成为全栈式数据管控平台，CloudQuery 1.4 概述

「近年来，新兴的互联网服务领域，以及电信、金融和交通等各传统行业出现了数据资产的爆炸性增长，这些数据资产的类型以非结构化和半结构化为主，如何低成本且高效率地存储和处理 PB 甚至 EB 量级的数据成了极大的挑战。」

——摘自《Hbase 权威指南》 ”随着大数据时代

数据量不断增长、企业规模不断扩大、业务系统更加多元，我们面对同源、异源数据的分析处理能力无时无刻在经受巨大的考验，分布式系统对数据一致性要求极高，同时大量的业务数据以及数据上云的时代趋势数次证明了数仓的便利性，但在数仓的实际工作中只有20%的时间花费在数据挖掘上，其余时间大多用来数据同步、任务调度、数据清洗等等构造符合条件的数据上。本文从该时代背景出发来介绍本次 CloudQuery 1.4 版本整体新增的功能点以及未来迭代规划。

引入「DTS」概念，数据工具大集成

上文中提到数仓工作中大量的时间用来进行数据处理，CloudQuery 本意旨在解决用户在数据操作中遇到的问题。1.4 之前的版本我们将重心放在优化编辑器体验以及攻克重难点上，在我们逐步完善数据操作工作台时也发现以 SQL 方式（手写 SQL 或可视化数据查询编辑、终端操作）来进行数据操作只是数据库相关人员工作中的一部分，更多时候我们需要跟数据进行批量交互，如批量数据导入、数据迁移等，此时再采用SQL或终端的形式则远远达不到我们对于该功能的期望。

因此 CloudQuery 在1.4版本提出「DTS」概念，意为「数据库工具箱服务」。「导入导出」作为「DTS」的一个子模块，为 DBA 、运维等角色提供了数据传输上的便利。

1.4.0 版本，我们首先推出 MySQL 和 Oracle 数据库的 dump 格式导出数据功能，后续会根据每个数据源进行针对性的数据工具支持，例如 PostgreSQL dump 相关导入导出功能，同时数据库工具也纳入权限管控，用户使用数据库工具需要管理员进行授权。

此外，在1.4的迭代过程中，「数据迁移」也会作为一个工具加入「CloudQuery DTS」大家庭。我们在设计「数据迁移」模块时考虑到当前分布式业务系统通常不会使用单一数据源进行数据存储的情况，提出了「同源/异源迁移」，同时根据数据库结构的异同会存在「同构/异构迁移」的情况，所以提供的迁移形式也更加多样化，具体如下：

• 迁移数据量
  • 全量
  • 增量
• 迁移时机
  • 实时
  • 定时
• 迁移端
  • 同源
  • 异源
    • 关系型 to 关系型
    • 关系型 to 非关系型
    • 关系型/非关系型 to 大数据/数仓
  • 同构
  • 异构
• 选择性迁移
  • 水平分割
  • 垂直分割

因为「数据迁移」的设计相对复杂且包含范围较广，所以「数据迁移」功能我们会在 1.4 版本中持续推出完善，也希望大家在使用中提出自己的建议，我们在认真分析之后会对功能进行调整。

「可视化」模块，数据操作无需有求于人

如果说「DTS」贴近数据库底层数据，那么「可视化」则更贴近业务场景。CloudQuery 1.4 版本推出的第二大功能就是「可视化」，包括两个模块：「可视化辅助查询」和「ER建模」。

可视化辅助
查询企业中并非每一个用户都能熟练使用 SQL 语句，对于没有 SQL 基础但需要进行数据查询的用户就需要「可视化」来辅助。

CloudQuery 1.4.0 版本新增「可视化辅助查询」功能，让用户以图形化的方式进行数据操作，添加查询、筛选、排序等条件时更加简便易懂，即使不懂 SQL 或不懂数据库也能得到自己需要的结果数据。

同时，我们后续也会支持用户查询画布保存或生成 SQL 语句保存，方便在以后的使用中直接获取结果。

ER 建模
「ER 建模」则针对相对高阶用户，以 ER 图的形式来渲染数据库下表关系，让主外键以及约束关系更加直观。

同时在 ER 图呈现画布上支持针对表结构的变更操作，例如 添加表、设计表、删除表、添加约束等。ER 图画布同样支持图片格式导出，方便 DBA 进行数据库元素关系整理，在业务内部传阅。

新增数据源支持，覆盖全类型数据库

CloudQuery 作为数据库统一入口，数据源支持是最基础的功能，同时作为以社区为重心的产品，用户的需求至关重要。我们在 1.3 版本迭代过程中持续收集社区用户的使用建议，经过评估后我们会在1.4迭代过程中加入以下数据源：

• Hive
• Es
• DB2
• PolarDB
• OceanBase

CloudQuery在持续扩充数据源种类的同时也不会忽略每个数据源自身的特性，同时在未来不久的版本中会对数据操作区的自动提示、结果集展示进行整体优化。

OpenAPI，发挥社区的力量

CloudQuery 是在社区中持续成长的产品，但同时我们自身能做的事情又十分有限。所以在我们功能迭代的路上将持续开放API，方便有开发能力的用户来进行企业内部第三方应用、组织架构以及其他资源接入。

接下去我们会优先开放「用户」模块的部分接口，但在调用接口前需要系统管理员在平台内部开发者中心进行指定用户的开发者身份激活，身份激活后会得到 appID 和对应的 secret，以此作为密钥来进行 API 接口的鉴权和调用。

总结

以上就是 CloudQuery 在未来的1.4版本中整体的功能以及迭代规划。后面我们对针对 1.4 版本的新功能出系列文章，详细阐述每个新功能点及其背后技术，让大家更好地了解 CloudQuery 的体系。同时我们会持续完善自身的基础能力，为社区用户带来更加便利、快捷的数据操作与交互体验。

官网地址：https://cloudquery.club/