乐趣区

关于数据库:成为全栈式数据管控平台CloudQuery-14-概述

作者：

jiezi

在

「近年来，新兴的互联网服务畛域，以及电信、金融和交通等各传统行业呈现了数据资产的爆炸性增长，这些数据资产的类型以非结构化和半结构化为主，如何低成本且高效率地存储和解决 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/

更多文章