能力说明

Domino 流计算引擎是从 YMatrix 6.0 版本推出的流计算功能模块,通过增量的维护计算结果,从而实现数据分析及查询的效率提升。

快速开始

Domino v2 从 YMatrix 6.4.X 版本开始,默认启用,无需专门设置。

更多 GUC 使用可参考技术参数

架构与核心模块

Domino 总体架构分为 执行框架计算引擎 两部分。

  • 执行框架 负责流的调度和元数据管理
  • 计算引擎 负责解码、查询改写和执行

主要差异

Domino v2 的核心目标是在保证查询延迟不变的情况下,支持更多流计算任务,解决 v1 版本在流数量增加时资源争抢、负载过高的问题。
核心差异主要体现在资源管理和执行方式上,v2 通过优化设计实现更高的流支持能力与稳定性:

资源管理

1.共享解码工具(Decoder)

  • v1 中每个流单独解码,流越多解码的工作量越大。
  • v2 中每个数据库共用一个解码器,解码结果存到 TLog 文件,解码工作量只和数据变更量有关,不会因流数量增加而变多。

2.共享工作进程(Worker)

  • v1 每个流会占用固定的工作进程,流越多占用的进程越多。
  • v2 通过设置全局工作进程数量,所有流轮流使用这些进程,控制总资源消耗,避免因流多而资源争抢。

3.小步执行:

  • v1 一次处理较大范围(从上次结束位置至最新位置)的 XLog,可能导致日志堆积。
  • v2 增加 Ticker 模块,用 Ticker 控制每次只处理小范围(默认每次向前扫描一个 Tick,比如多少 MB 或时间)的XLog,推进更快,减少堆积。

4.功能方面:功能上两者无显著差异。

5.兼容性:v1 和v2 可同时存在,但如果数据库降级,V2的流会不可用,V1不受影响。

执行方式

Domino v2 重点优化了执行框架,核心模块如下:

1.Ticker
用于切分 XLog。控制单次流计算的范围(最小为一个Tick),避免流计算产生大事务导致系统变慢;但创建 WITH DATA 流时处理历史数据的大事务不受此限制。

2.Scheduler
负责流的调度。通过复用 Worker 进程,限制总体 CPU 用量,同时提高单个 Worker 的 CPU 使用率。

3.Decoder
用于解析 XLog。生成供流计算消费的 Tuple 和快照( TLog )。

4.TLog
存储解码后的变更记录。作为 Decoder 与流计算之间的中间存储,供流计算读取和处理。

能力概述

能力项 支持状态 说明
上游表存储引擎 HEAP / MARS3
上游表分布类型 Hash 分布/随机分布/segment set 模式 不支持 master-only 表和 replicated 表 作为上游表
上游表分区 支持
流表存储引擎 HEAP / MARS3 / AO
流表的分布键 支持自由选择分布键,可以和上游表不同 最优解决方案是保持一致。尤其是对于聚集流,相同的分布键可以讲流计算本地化
流表的存储特征 流表可以进行独立的引擎、分区、分布键选择
上游表多字段支持 支持 可支持上游表字段 ≥ 300
一表多流 支持 同级多个数据流的上游表可以是同一个。“一表”指的是同一上游表
扩维计算 支持 支持关联 ≥ 10 的维度表
聚集计算 支持 支持分组字段 ≥32;内部会合并自动多个字段的类型为一个类型,然后产生一个组合类型的字段,进行后续的聚集计算
上游表 DDL 支持 不支持 上游表创建索引,不会对下游流表的发挥作用。上游表删除索引,可能导致下游流无法执行
流表 DDL 支持 不支持 流表上暂不支持字段类的 DDL 变更,如需变更,需要重建流。后续会支持部分DDL功能。 注:如果流表的上游表也发生DDL,同样建议进行流的重建
流表索引 支持 流表可以独立进行索引创建和维护
维度过滤 支持 扩维关联计算时,支持进行维表的过滤条件添加
故障转移 支持 segment节点发生主备切换后,流可以继续稳定工作;但有一定概率丢失切换时间点的少量事务
性能损耗 上游表的写入几乎无影响,流表的计算结果秒级以内延迟
大事务能力 支持 内部优化了分批处理机制和以及事务日志解码的内存使用,对于大事务的处理更加稳定。但是相对来说,存在大事务变更的表还是慎用流处理
上游表历史数据处理 支持 创建流的时候,可以通过WITH DATA选项指定处理上游表的历史数据。若上游表的数据量巨大,会产生一个非常大事务,在事务结束前,会阻塞其他流的创建
双流 JOIN 支持 支持非等值连接,上游表之间不同分布键,上游表与流可以是不同分布键

其他说明

1.流表对象不能被 JDBC 元数据获取,需要通过独立的语句进行查询。
2.流对象的创建,只能是管理员用户。
3.定义流的 SELETE 部分需保证不存在重名字段。尤其是聚集流定义使用聚集函数后,最好是给字段起个不同的别名,如select avg(col1) as avg_col1,avg(col2) as avg_col2。也可通过CREATE STREAM 部分进行字段投影。
4.尽量限制直接对流表上的数据进行 DML 操作(GUC mx_stream_internal_modify)。
5.不能在流定义中使用 WITH 子句。
6.聚集流使用限制:

  • 流定义中,FROM STREAMING 只能出现一个。
  • GROUP BY 分组键必须包含对应流表的所有分布键
  • 不允许不带 GROUP BY 的全局聚集计算
  • 不允许试用 HAVING 子句。或者以嵌套子查询,外层 WHERE 过滤的类 HAVING 功能
  • 聚集表达式,不能再次参与其他表达式计算。如 avg(col1)+1,但支持 avg(col+1) 这种写法。

7.双流 JOIN 使用限制

  • 不能在双流 JOIN 的计算中试用 GROUP BY
  • 目前只能实现两个上游表的等值 INNER JOIN 计算,不能使用双流做 UNION 计算和 LEFT JOIN 计算,以及和其他非流式订阅的表关联计算
  • 不能在双流 JOIN 的计算中使用 DISINTCT、SUM、MAX 等聚集函数
  • 不能再双流 JOIN 的计算中使用窗口函数
  • 不支持 ORDER BY 子句

8.多级流中,中间环节的流不能是聚集流。