RisingWave 1.9 发布!新增 Snowflake sink 连接器

文摘   科技   2024-06-11 15:10   北京  
我们非常高兴地宣布:RisingWave1.9 版本正式发布!此次我们带来了许多重要更新,例如:优化了许多上游和下游连接器、新增了 Snowflake sink 连接器、弃用此前的 s3 连接器,转为指定 AWS S3 source 连接器为 s3_v2等。此外,本版本还新增了许多实用的 SQL 命令和函数,例如创建订阅功能等。一起来了解本次更新的主要亮点吧!

1Recover 命令

我们自 1.9 版本开始支持RECOVER 命令。该命令可以触发临时性的恢复,当存在较高延迟时可能需要使用。需要注意的是,只有超级用户才能使用 RECOVER 命令,以限制可以触发恢复的用户范围。此外,RisingWave 仅能从已提交的时间点进行恢复,且该命令不会等待恢复完成。
执行此命令后,可以调整流速限制确保 RisingWave 持续稳定运行,并且任何 DROP 或 CANCEL 命令都将立即生效
更多细节,请查看:
  • RECOVER命令[1]

2配置全局参数

您可以使用 ALTER SYSTEM 命令在整个服务器上设置运行时参数或系统参数。使用此命令后,新参数值也将成为每个新会话的默认值。如果您喜欢使用不同的参数运行每个 RisingWave 会话,用此命令可以更轻松地设置每个会话。
例如,以下 SQL 命令将运行时参数 rw_enable_join_ordering 设置为 true
ALTER SYSTEM SET rw_enable_join_ordering TO true
您可以使用 SHOW ALL 命令查看所有运行时参数,如果想查看当前运行时某个特定运行时参数的值,可使用 SHOW parameter_name 命令。如果想查看所有系统参数及其当前值,则可使用 SHOW PARAMETERS 命令。
更多细节,请查看:
  • ALTER SYSTEM 命令[2]
  • 查看和配置运行时参数[3]
  • 查看和配置系统参数[4]

3增强时间连接

我们现在支持非仅追加模式的时间连接 (Non-append-only temporal joins), 意味着时间连接的外部或左侧不需要是一个仅追加模式的源或表。该功能在所有情况下使用相同的语法。此次改进可以让您更加灵活地连接数据。
假设 stream_source 是一个非仅追加的源 prod 是一个表,则以下 SQL 命令使用了时间连接来连接两个表。
SELECT * 
FROM stream_source
JOIN prod FOR SYSTEM_TIME AS OF PROC_TIME()
ON source_id = prod_id;
更多细节,请查看:
  • 非仅追加模式的时间连接[5]

4支持订阅和订阅游标

此版本更新后,您可以从表和物化视图创建订阅队列,并为订阅队列创建游标。这些新功能旨在使数据检索更加方便。
请使用 CREATE SUBSCRIPTION 命令创建订阅。您还可以删除、修改和显示现有的订阅。创建订阅时可以选择增量数据的保留时间以及订阅可以访问的时间。以下是 SQL 查询在物化视图上创建订阅,并将数据保留一天的示例。
CREATE SUBSCRIPTION sub1 FROM tbl1 WITH (retention = '1D' );
此外,您还可以修改订阅的名称、所有者、模式和并行性。
您也可以为订阅创建游标,其功能是以更小的批次读取查询结果,一次检索几行,以避免内存溢出。要使用游标,需要先创建游标,然后从游标中提取结果。以下是一个示例,为上文创建的订阅创建游标。
DECLARE cursor1 SUBSCRIPTION CURSOR FOR sub1;
接下来,您可以从游标中提取结果。
FETCH NEXT FROM cursor1;

----结果
col1 | col2 | col3 | op | rw_timestamp
----+----+----+----+-------------------
  1  |   2  |   3  |  1 |
(1 行)
col1col2  col3 是订阅的表中的列op 则是生成的特殊列。op 的值可以是 123  4,分别对应于 INSERTDELETEUPDATE_DELETE  UPDATE_INSERTUPDATE 语句在这里被转换为 UPDATE_DELETE  UPDATE_INSERT。请注意,每次从游标中提取时,只会返回表中的一行数据。要查看其他行的数据,必须再次调用 FETCH 命令。
更多细节,请查看:
  • 订阅[6]

5使用 Iceberg source 进行 Time travel

对于 Iceberg source,您现在可以使用 AS OF 语法从特定时间段或版本中选择数据。RisingWave 目前仅支持从 Iceberg source 进行批量查询,拥有此功能后,随着时间推移跟踪数据集的变化会更容易。同时,从特定版本选择数据则使得数据可重现性增强,这对于调试非常重要:如果在数据中检测到错误,您可以轻松选择之前版本的数据。
以下是选择历史版本的示例, 我们通过特定的快照 ID 中选择了 Iceberg source 的数据。
SELECT * FROM iceberg_source FOR system_version AS OF 1567123456789;
以下是选择时间段的示例, 我们从 Iceberg source 中选择了特定时间戳之后的数据。
SELECT * FROM iceberg_source FOR system_time AS OF '2006-09-21 00:00:00+00:00';
更多细节,请查看:
  • 从 Apache Iceberg 中摄取数据[7]

6PostgreSQL 和 MySQL 连接器的新配置

本版本新增了一系列配置选项,大多数用于 MySQL 和 PostgreSQL CDC source。这为您在创建 CDC 表时提供了更多的控制和灵活性,以满足独特的需求和用例。以下是其中一些新配置选项。

配置 SSL/TLS

对于 MySQL 和 PostgreSQL CDC source,现在可以使用 ssl.mode 参数设置 SSL/TLS 加密级别。配置 SSL/TLS 可确保传输的数据的完整性和机密性,保护敏感信息免受威胁和攻击。许多监管标准和最佳实践也使用 SSL/TLS,这使得它成为许多用户关心的重要功能。
ssl.mode 参数接受disabledpreferred  required这三个值,默认值为 disabled
CREATE SOURCE pg_source WITH (
    connector = 'postgres-cdc',
    hostname = '127.0.0.1',
    port = '5432',
    username = 'user',
    password = 'password',
    database.name = 'mydb',
    slot.name = 'mydb_slot',
    ssl.mode = 'required'
);

配置快照

除了为 CDC 表配置快照之外,您现在还可以配置屏障间隔和批次大小。在与 MySQL 或 PostgreSQL 数据库建立连接时,您可以创建 CDC source 或 CDC 表。CDC source 连接到整个数据库,而 CDC 表连接到单个 MySQL 或 PostgreSQL 表。快照相关的参数选项仅适用于创建表时。

新参数 snapshot.interval 可以设置开始快照读取时的屏障间隔;snapshot.batch_size 可以配置快照读取的批次大小。

配置超时

最后,我们还新增了一项运行时参数来更改 CDC source 的超时配置。某些 CDC source 建立连接可能需要消耗一些时间,造成这一点的原因有很多,比如大量的数据或复杂的表结构。默认情况下,超时设置为 30 秒,但这个时间在某些极端情况下可能不够。如果您的 CDC source 创建由于控制流中的错误而失败,可以尝试使用运行时参数 cdc_source_wait_streaming_start_timeout 来增加超时阈值。
SET cdc_source_wait_streaming_start_timeout to 90;
更多细节,请查看:
  • 从 MySQL CDC 中摄取数据[8]
  • 从 PostgreSQL CDC 中摄取数据[9]

7支持更多 Sink 连接器

本版本还新增了一项 Sink 连接器,并对现有 Sink 连接器进行增强。Sink 连接器在数据流水线中扮演着关键角色,助力与各种下游系统的无缝集成。如果您对某个连接器感兴趣,请查看我们的集成页面[10],了解我们目前支持的内容,并投票选择您想要的连接器。我们一直致力于改进数据集成功能,让 RisingWave 能够轻易与任何流处理管道集成。

支持 Snowflake sink 连接器

Snowflake 是一种云原生、多功能的数据仓库平台,具有极强的可扩展性。它提供了全面的托管服务,可以安全地存储和分析大量数据。由于 Snowflake 仅支持从外部存储中接收数据,因此数据将在传输到 Snowflake 之前被上传到外部存储系统。目前,RisingWave 仅支持 Amazon S3 作为外部存储。
在 RisingWave 中创建 Snowflake sink 非常简单。如果您已经设置了 Amazon S3 bucket,只需使用 CREATE SINK SQL 语句即可完成。
CREATE SINK snowflake_sink FROM mv WITH (
    connector = 'snowflake',
    type = 'append-only',
    snowflake.database = 'db',
    snowflake.schema = 'schema',
    snowflake.pipe = 'pipe',
    snowflake.account_identifier = '<ORG_NAME>-<ACCOUNT_NAME>',
    snowflake.user = 'user',
    snowflake.rsa_public_key_fp = 'fp',
    snowflake.private_key = 'pk',
    snowflake.s3_bucket = 's3_bucket',
    snowflake.aws_access_key_id = 'aws_id',
    snowflake.aws_secret_access_key = 'secret_key',
    snowflake.aws_region = 'region',
    snowflake.max_batch_row_num = '1030',
    snowflake.s3_path = 's3_path',
);

支持 BigQuery sink 的 upsert 类型

此前我们只支持创建 append-only 类型的 BigQuery sink,这意味着只有 INSERT 操作会传递到 BigQuery 表中。现在,1.9 版本新增支持 upsert 类型的 Sink,允许传递 UPDATE  DELETE 操作。创建 upsert Sink 时,需要在 BigQuery 中进行额外的配置,并且必须设置相应的权限和主键。
CREATE SINK big_query_sink
FROM mv
WITH (
    connector = 'bigquery',
    type = 'upsert',
    bigquery.s3.path= '${s3_service_account_json_path}',
    bigquery.project= '${project_id}',
    bigquery.dataset= '${dataset_id}',
    bigquery.table= '${table_id}',
    access_key = '${aws_access_key}',
    secret_access = '${aws_secret_access}',
    region = '${aws_region}',
);

Delta Lake sink 支持 GCS

您现在可以使用 Google Cloud Storage 作为 Delta Lake 文件的存储位置来创建 Delta Lake sink。此前我们只支持 AWS S3 和 MinIO 对象存储。Google Cloud Storage 被普遍用于数据存储,此功能会使 Delta Lake sink 连接器更加便捷。
创建 Delta Lake sink 时若使用 GCS,请使用匹配参数的 CREATE SINK 命令。
CREATE SINK s1_sink FROM s1_source
WITH (
    connector = 'deltalake',
    type = 'append-only',
    location = 'gs://bucket-name/path/to/file',
    gcs.service.account = '{type: service_acct,
                project_id: id,
                private_key:key,
               client_email: email}'

);
更多信息,请查看:
  • 将数据从 RisingWave 导出到 Snowflake[11]
  • 将数据从 RisingWave 导出到 BigQuery[12]
  • 将数据从 RisingWave 导出到 Delta Lake[13]

8总结

以上只是 RisingWave 1.9 版本新增的部分功能,如果您想了解本次更新的完整列表,请查看更详细的发布说明[14]
参考资料
[1]

RECOVER 命令: https://docs.risingwave.com/docs/current/sql-recover/

[2]

ALTER SYSTEM 命令: https://docs.risingwave.com/docs/current/sql-alter-system/

[3]

查看和配置运行时参数: https://docs.risingwave.com/docs/current/view-configure-runtime-parameters/

[4]

查看和配置系统参数: https://docs.risingwave.com/docs/current/view-configure-system-parameters/

[5]

非仅追加模式的时间连接: https://docs.risingwave.com/docs/current/query-syntax-join-clause/#process-time-temporal-joins

[6]

订阅: https://docs.risingwave.com/docs/current/subscription/

[7]

从 Apache Iceberg 中摄取数据: https://docs.risingwave.com/docs/current/ingest-from-iceberg/#time-travel

[8]

从 MySQL CDC 中摄取数据: https://docs.risingwave.com/docs/current/ingest-from-mysql-cdc/

[9]

从 PostgreSQL CDC 中摄取数据: https://docs.risingwave.com/docs/current/ingest-from-postgres-cdc/

[10]

集成页面: https://docs.risingwave.com/docs/current/rw-integration-summary/

[11]

将数据从 RisingWave 导出到 Snowflake: https://docs.risingwave.com/docs/current/sink-to-snowflake/

[12]

将数据从 RisingWave 导出到 BigQuery: https://docs.risingwave.com/docs/current/sink-to-bigquery/

[13]

将数据从 RisingWave 导出到 Delta Lake: https://docs.risingwave.com/docs/current/sink-to-delta-lake/

[14]

发布说明: https://docs.risingwave.com/release-notes/


关于 RisingWave 

RisingWave 是一款基于 Apache 2.0 协议开源的分布式流数据库,致力于为用户提供极致简单、高效的流数据处理与管理能力。RisingWave 采用存算分离架构,实现了高效的复杂查询、瞬时动态扩缩容以及快速故障恢复,并助力用户极大地简化流计算架构,轻松搭建稳定且高效的流计算应用。
RisingWave 始终聆听来自社区的声音,并积极回应用户的反馈。目前,RisingWave 已汇聚了近 150 名开源贡献者和近 3000 名社区成员。全球范围内,已有上百个 RisingWave 集群在生产环境中部署。

往期推荐

技术内幕

如何上手 RisingWave 👉 新手入门教程

RisingWave 中文用户文档上线,阅读更高效!

深入探索 RisingWave 中的高可用性与容错机制

深入理解 RisingWave 流处理引擎(三):触发机制

深入理解 RisingWave 流处理引擎(二):计算模型

深入理解 RisingWave 流处理引擎(一):总览

用户案例
视源股份(CVTE)IT 流计算应用历程
尘锋 SCRM 如何使用 RisingWave 实时打宽
RisingWave 在超百亿管理规模对冲基金公司中的应用
金融科技公司 Kaito 使用 RisingWave 实现实时智能化
龙腾出行如何通过 RisingWave 实现实时数据分析
RisingWave 助力乾象投资打造实时监控平台

RisingWave中文开源社区
RisingWave 是一款开源分布式 SQL 流数据库,致力于大幅降低流计算使用门槛与复杂度。RisingWave 已为全球超百家企业构建新一代流处理与分析平台。
 最新文章