From 99adcc2110fa29ce03c0538208ad02ce06db6463 Mon Sep 17 00:00:00 2001 From: GitHub Action Date: Wed, 2 Jul 2025 10:50:45 +0000 Subject: [PATCH] docs(ja): sync translations from c55404f to 48e5828 --- ja_JP/changes/all-changes-ee.md | 4 +- ja_JP/changes/changes-ee-v5.md | 91 ++++- .../data-integration/data-bridge-rocketmq.md | 134 +++---- ja_JP/data-integration/snowflake.md | 326 +++++++++++------- ja_JP/last_translation_commit | 2 +- 5 files changed, 363 insertions(+), 194 deletions(-) diff --git a/ja_JP/changes/all-changes-ee.md b/ja_JP/changes/all-changes-ee.md index 5fdfe1a9c..d5487867b 100644 --- a/ja_JP/changes/all-changes-ee.md +++ b/ja_JP/changes/all-changes-ee.md @@ -1,13 +1,15 @@ # EMQX Enterprise リリースノート -EMQX Enterprise のリリースノートページでは、各バージョンに含まれるアップデート、機能強化、および修正の詳細な記録を提供しています。 +EMQX Enterprise のリリースノートページでは、各バージョンに含まれる更新内容、機能強化、および修正の詳細な記録を提供しています。 ## v5.9 +- [5.9.1](./changes-ee-v5.md#_5-9-1): 2025-07-02 - [5.9.0](./changes-ee-v5.md#_5-9-0): 2025-05-02 ## v5.8 +- [5.8.7](./changes-ee-v5.md#_5-8-7): 2025-07-02 - [5.8.6](./changes-ee-v5.md#_5-8-6): 2025-03-25 - [5.8.5](./changes-ee-v5.md#_5-8-5): 2025-02-25 - [5.8.4](./changes-ee-v5.md#_5-8-4): 2024-12-26 diff --git a/ja_JP/changes/changes-ee-v5.md b/ja_JP/changes/changes-ee-v5.md index 1db1bbeff..df68617c3 100644 --- a/ja_JP/changes/changes-ee-v5.md +++ b/ja_JP/changes/changes-ee-v5.md @@ -1,5 +1,77 @@ # EMQX Enterprise Version 5 +## 5.9.1 + +*Release Date: 2025-07-02* + +Make sure to check the breaking changes and known issues before upgrading to EMQX 5.9.1. + +### Enhancements + +- [#15364](https://github.com/emqx/emqx/pull/15364) Added support for custom HTTP headers in the OpenTelemetry gRPC (over HTTP/2) integration. This enhancement enables compatibility with collectors that require HTTP authentication. + +- [#15160](https://github.com/emqx/emqx/pull/15160) Added the `DELETE /mt/bulk_delete_ns` API for multi-tenancy management, which allows deleting namespaces in bulk. + +- [#15158](https://github.com/emqx/emqx/pull/15158) Added new `emqx ctl conf remove x.y.z` command, which removes the configuration key path `x.y.z` from the existing configuration. + +- [#15157](https://github.com/emqx/emqx/pull/15157) Added support for specifying private key file path for Snowflake Connector instead of using password. + + Users should either use password, private key, or neither (set parameters in `/etc/odbc.ini`). + +- [#15043](https://github.com/emqx/emqx/pull/15043) Instrument the DS Raft backend with basic metrics to provide insights into cluster status, database overview, shard replication, and replica transitions. + +### Bug Fixes + +#### Data Integration + +- [#15331](https://github.com/emqx/emqx/pull/15331) Fixed an issue in the InfluxDB action where line protocol conversion failed if the `timestamp` in `WriteSyntax` was left blank and no timestamp field was provided in the rule. + Now the system's current millisecond value is used instead, and millisecond precision is enforced. + +- [#15274](https://github.com/emqx/emqx/pull/15274) Improved the resilience of Postgres, Matrix, and TimescaleDB connectors by triggering a full reconnection on any health check failure. Previously, failed health checks could leave the connection in a broken state, causing operations to hang and potentially leading to out-of-memory issues. + +- [#15154](https://github.com/emqx/emqx/pull/15154) Fixed a rare race condition in Actions running in aggregated mode (e.g., S3, Azure Blob Storage, Snowflake) that could lead to a crash with errors like: + + ``` + ** Reason for termination == + ** {function_clause,[{emqx_connector_aggregator,handle_close_buffer,[...], ... + ``` + +- [#15147](https://github.com/emqx/emqx/pull/15147) Fixed an issue where some Actions failed to emit trace events during rule testing with simulated input data, even after request rendering. + + Affected Actions: + + - Couchbase + - Snowflake + - IoTDB (Thrift driver) + +- [#15383](https://github.com/emqx/emqx/pull/15383) Fixed a potential resource leak in the MQTT bridge. When the bridge failed to start, the topic index table was not properly cleaned up. This fix ensures that the index table is correctly deleted to prevent resource leaks. + +#### Smart Data Hub + +- [#15224](https://github.com/emqx/emqx/pull/15224) Fixed an issue where updating an External Schema Registry via the Dashboard would unintentionally overwrite the existing password with `******`. The password is now correctly preserved during updates. +- [#15190](https://github.com/emqx/emqx/pull/15190) Enhanced Message Transformation by allowing hard-coded values for QoS and topic. + +#### Observability + +- [#15299](https://github.com/emqx/emqx/pull/15299) Fixed a `badarg` error that occurred when exporting OpenTelemetry metrics. + +#### Telemetry + +- [#15216](https://github.com/emqx/emqx/pull/15216) Fixed a crash in the `emqx_telemetry` process that could occur when plugins were activated. + +#### Access Control + +- [#15184](https://github.com/emqx/emqx/pull/15184) Fixed the formatting of error messages returned when creating a blacklist fails. + +#### Clustering + +- [#15180](https://github.com/emqx/emqx/pull/15180) Reduced the risk of deadlocks during channel registration by fixing improper handling of `badrpc` errors in the `ekka_locker` module. These errors previously led to false positives in lock operations, potentially causing inconsistent cluster state and deadlocks. + +#### Security + + +- [#15159](https://github.com/emqx/emqx/pull/15159) Improved handling of Certificate Revocation List (CRL) Distribution Point URLs by stopping their refresh after repeated failures (default: 60 seconds). This prevents excessive error logs from unreachable URLs and improves overall system stability. + ## 5.9.0 *Release Date: 2025-05-02* @@ -118,7 +190,7 @@ Make sure to check the breaking changes and known issues before upgrading to EMQ - [#14892](https://github.com/emqx/emqx/pull/14892) Enhanced cluster load rebalancing: - Fixed load imbalance in core/replicant cluster. Previously, under certain conditions, all transactions from the replicants could be sent to a single core node. - + - Add CLI commands for rebalancing replicant nodes in relation to core nodes: - `emqx_ctl cluster core rebalance plan` @@ -434,6 +506,23 @@ Make sure to check the breaking changes and known issues before upgrading to EMQ - [#14775](https://github.com/emqx/emqx/pull/14775) QUIC Listener: Fixed issue where zone configurations are not applied after a config reload. +## 5.8.7 + +*Release Date: 2025-07-02* + +### Enhancements + +- [#15364](https://github.com/emqx/emqx/pull/15364) Added support for custom HTTP headers in the OpenTelemetry gRPC (over HTTP/2) integration. This enhancement enables compatibility with collectors that require HTTP authentication. + +### Bug Fixes + +- [#15383](https://github.com/emqx/emqx/pull/15383) Fixed a potential resource leak in the MQTT bridge. When the bridge failed to start, the topic index table was not properly cleaned up. This fix ensures that the index table is correctly deleted to prevent resource leaks. +- [#15331](https://github.com/emqx/emqx/pull/15331) Fixed an issue in the InfluxDB action where line protocol conversion failed if the `timestamp` in `WriteSyntax` was left blank and no timestamp field was provided in the rule. Now the system's current millisecond value is used instead, and millisecond precision is enforced. +- [#15274](https://github.com/emqx/emqx/pull/15274) Improved the resilience of Postgres, Matrix, and TimescaleDB connectors by triggering a full reconnection on any health check failure. Previously, failed health checks could leave the connection in a broken state, causing operations to hang and potentially leading to out-of-memory issues. +- [#15224](https://github.com/emqx/emqx/pull/15224) Fixed an issue where updating an External Schema Registry via the Dashboard would unintentionally overwrite the existing password with `******`. The password is now correctly preserved during updates. +- [#14989](https://github.com/emqx/emqx/pull/14989) Optimized the Kinesis Connector and Action to significantly reduce the number of AWS API calls during startup and health checks. This change helps prevent exceeding AWS Kinesis API rate limits (e.g., `ListStreams` and `DescribeStream`), which previously led to frequent health check failures when using larger connection pools or multiple connectors. +- [#15299](https://github.com/emqx/emqx/pull/15299) Fixed a `badarg` error that occurred when exporting OpenTelemetry metrics. + ## 5.8.6 *Release Date: 2025-03-25* diff --git a/ja_JP/data-integration/data-bridge-rocketmq.md b/ja_JP/data-integration/data-bridge-rocketmq.md index 2cc7db057..e3e8cdd14 100644 --- a/ja_JP/data-integration/data-bridge-rocketmq.md +++ b/ja_JP/data-integration/data-bridge-rocketmq.md @@ -1,52 +1,52 @@ -# Bridge MQTT Data into RocketMQ +# RocketMQへのMQTTデータブリッジ -EMQXは[RocketMQ](https://rocketmq.apache.org/)へのデータブリッジをサポートしており、MQTTメッセージやクライアントイベントをRocketMQに転送できます。例えば、RocketMQを使ってデバイスからのセンサーデータやログデータを収集することが可能です。 +EMQXは[RocketMQ](https://rocketmq.apache.org/)へのデータブリッジをサポートしており、MQTTメッセージやクライアントイベントをRocketMQに転送できます。例えば、RocketMQを利用してデバイスからのセンサーデータやログデータを収集することが可能です。 -本ページでは、EMQXとRocketMQ間のデータ連携の詳細な概要と、データ連携の作成および検証に関する実践的な手順を提供します。 +本ページでは、EMQXとRocketMQ間のデータ統合について詳細に解説し、データ統合の作成および検証手順を実践的に説明します。 ::: tip 注意 -Alibaba CloudがホストするRocketMQサービスを利用する場合、このデータ連携はバッチモードをサポートしていません。 +Alibaba Cloudが提供するRocketMQサービスを利用する場合、本データ統合はバッチモードをサポートしていません。 ::: -## 動作原理 +## 動作概要 -RocketMQデータ連携は、EMQXに標準搭載された機能であり、EMQXのリアルタイムデータキャプチャと送信機能をRocketMQの強力なメッセージキュー処理機能と組み合わせています。組み込みの[ルールエンジン](./rules.md)コンポーネントにより、EMQXからRocketMQへのデータ取り込みが簡素化され、複雑なコーディングが不要になります。 +RocketMQデータ統合はEMQXに標準搭載された機能であり、EMQXのリアルタイムデータキャプチャと送信能力をRocketMQの強力なメッセージキュー処理能力と組み合わせています。組み込みの[ルールエンジン](./rules.md)コンポーネントにより、EMQXからRocketMQへのデータ取り込みを簡素化し、複雑なコーディングを不要にします。 -以下の図は、EMQXとRocketMQ間の典型的なデータ連携アーキテクチャを示しています。 +以下の図は、EMQXとRocketMQ間のデータ統合の典型的なアーキテクチャを示しています。 ![EMQX Integration RocketMQ](./assets/emqx-integration-rocketmq.png) -MQTTデータをRocketMQに取り込む流れは次の通りです： +MQTTデータをRocketMQに取り込む流れは以下の通りです： -1. **メッセージのパブリッシュと受信**：産業用IoTデバイスはMQTTプロトコルを通じてEMQXに正常に接続し、リアルタイムMQTTデータをEMQXにパブリッシュします。EMQXがこれらのメッセージを受信すると、ルールエンジン内でマッチング処理を開始します。 -2. **メッセージデータの処理**：メッセージが到着するとルールエンジンを通過し、EMQXで定義されたルールによって処理されます。ルールは事前定義された条件に基づき、RocketMQにルーティングすべきメッセージを判別します。ペイロードの変換が指定されている場合は、データ形式の変換、特定情報のフィルタリング、追加コンテキストによるペイロードの強化などが適用されます。 -3. **RocketMQへのデータ取り込み**：ルールによる処理が完了したメッセージは、RocketMQへの転送アクションがトリガーされます。処理済みデータはシームレスにRocketMQに書き込まれます。 -4. **データの保存と活用**：データがRocketMQに保存された後、企業はそのクエリ機能を活用して様々なユースケースに対応できます。例えば金融業界では、RocketMQを信頼性の高い高性能メッセージキューとして利用し、決済端末や取引システムからのデータを管理します。これにより、リスク管理、不正検知・防止、規制遵守などの要件を満たすためのデータ分析や規制プラットフォームと連携可能です。 +1. **メッセージのパブリッシュと受信**：産業用IoTデバイスはMQTTプロトコルを通じてEMQXに正常に接続し、リアルタイムのMQTTデータをEMQXにパブリッシュします。EMQXがこれらのメッセージを受信すると、ルールエンジン内でマッチング処理を開始します。 +2. **メッセージデータの処理**：メッセージが到着するとルールエンジンを通過し、EMQXで定義されたルールに基づいて処理されます。ルールは事前定義された条件に従い、RocketMQにルーティングすべきメッセージを判別します。ペイロード変換が指定されている場合は、データ形式の変換、特定情報のフィルタリング、ペイロードの付加情報による拡充などの変換処理が適用されます。 +3. **RocketMQへのデータ取り込み**：ルールによる処理が完了すると、メッセージをRocketMQに転送するアクションがトリガーされます。処理済みデータはシームレスにRocketMQに書き込まれます。 +4. **データの保存と活用**：データがRocketMQに保存されることで、企業はそのクエリ機能を活用して様々なユースケースに対応できます。例えば金融業界では、RocketMQを高信頼・高性能なメッセージキューとして利用し、決済端末や取引システムからのデータを管理します。これにより、リスク管理、不正検知・防止、法令遵守などの要件を満たすためのデータ分析や規制プラットフォームとの連携が可能となります。 -## 特長と利点 +## 特長とメリット -RocketMQとのデータ連携は、以下の特長と利点をビジネスにもたらします： +RocketMQとのデータ統合がもたらす主な特長と利点は以下の通りです： -- **信頼性の高いIoTデータメッセージ配信**：EMQXはMQTTメッセージを信頼性高くバッチ送信でき、IoTデバイスとRocketMQおよびアプリケーションシステムの統合を実現します。 -- **MQTTメッセージの変換**：ルールエンジンを活用し、EMQXはMQTTメッセージの抽出、フィルタリング、強化、変換を行い、RocketMQに送信します。 -- **クラウドネイティブな弾力的スケーリング**：EMQXとRocketMQは共にクラウドネイティブアーキテクチャで構築されており、Kubernetes（K8s）をはじめとしたクラウドネイティブエコシステムとの親和性が高く、ビジネスの急速な成長に対応する無限の弾力的スケールが可能です。 -- **柔軟なトピックマッピング**：RocketMQデータ連携はMQTTトピックとRocketMQトピックの柔軟なマッピングをサポートし、RocketMQメッセージ内のキー（Key）や値（Value）の設定を簡単に行えます。 -- **高スループットシナリオでの処理能力**：RocketMQデータ連携は同期・非同期の両書き込みモードをサポートし、シナリオに応じてレイテンシとスループットのバランスを柔軟に調整可能です。 +- **信頼性の高いIoTデータメッセージ配信**：EMQXはMQTTメッセージを確実にバッチ送信でき、IoTデバイスとRocketMQおよびアプリケーションシステムの統合を実現します。 +- **MQTTメッセージの変換**：ルールエンジンを用いてMQTTメッセージのフィルタリングや変換が可能です。データ抽出、フィルタリング、拡充、変換を経てRocketMQに送信できます。 +- **クラウドネイティブな弾力的スケーリング**：EMQXとRocketMQは共にクラウドネイティブアーキテクチャ上に構築されており、Kubernetes（K8s）に対応しクラウドネイティブエコシステムと統合可能です。ビジネスの急速な成長に合わせて無限に弾力的にスケールできます。 +- **柔軟なトピックマッピング**：RocketMQデータ統合はMQTTトピックからRocketMQトピックへの柔軟なマッピングをサポートし、RocketMQメッセージのキー（Key）や値（Value）の設定を容易に行えます。 +- **高スループットシナリオでの処理能力**：RocketMQデータ統合は同期・非同期の両書き込みモードをサポートし、用途に応じてレイテンシとスループットのバランスを柔軟に調整できます。 ## はじめる前に -このセクションでは、RocketMQデータ連携を作成する前に必要な準備とRocketMQサーバーのセットアップ方法を説明します。 +本節では、RocketMQデータ統合の作成を開始する前に必要な準備、特にRocketMQサーバーのセットアップ方法について説明します。 ### 前提条件 -- EMQXデータ連携の[ルール](./rules.md)に関する知識 -- [データ連携](./data-bridges.md)に関する知識 +- EMQXデータ統合の[ルール](./rules.md)に関する知識 +- [データ統合](./data-bridges.md)に関する知識 ### RocketMQのインストール -1. RocketMQをセットアップするためのdocker-composeファイル`rocketmq.yaml`を準備します。 +1. RocketMQをセットアップするためのdocker-composeファイル `rocketmq.yaml` を用意します。 ```yaml version: '3.9' @@ -81,7 +81,7 @@ services: - mqnamesrv ``` -2. RocketMQの実行に必要なフォルダと設定を作成します。 +2. RocketMQの実行に必要なフォルダと設定を準備します。 ```bash mkdir rocketmq @@ -90,7 +90,7 @@ mkdir rocketmq/store mkdir rocketmq/conf ``` -3. 以下の内容を`rocketmq/conf/broker.conf`に保存します。 +3. 以下の内容を `rocketmq/conf/broker.conf` に保存します。 ```bash brokerClusterName=DefaultCluster @@ -123,7 +123,7 @@ flushDiskType=ASYNC_FLUSH docker-compose -f rocketmq.yaml up ``` -5. コンシューマーを起動します。 +5. コンシューマを起動します。 ``` docker run --rm -e NAMESRV_ADDR=host.docker.internal:9876 apache/rocketmq:4.9.4 ./tools.sh org.apache.rocketmq.example.quickstart.Consumer @@ -131,40 +131,40 @@ docker run --rm -e NAMESRV_ADDR=host.docker.internal:9876 apache/rocketmq:4.9.4 ::: tip -Linux環境では、`host.docker.internal`を実際のIPアドレスに変更してください。 +Linux環境では、`host.docker.internal` を実際のIPアドレスに変更してください。 ::: ## コネクターの作成 -このセクションでは、SinkをRocketMQサーバーに接続するためのコネクター作成方法を説明します。 +本節では、SinkをRocketMQサーバーに接続するためのコネクター作成方法を示します。 -以下の手順は、EMQXとRocketMQをローカルマシンで実行している場合を想定しています。リモートで実行している場合は設定を適宜調整してください。 +以下の手順はEMQXとRocketMQをローカルマシンで実行していることを前提としています。リモート環境で実行している場合は適宜設定を調整してください。 -1. EMQXダッシュボードに入り、**Integration** -> **Connectors**をクリックします。 -2. ページ右上の**Create**をクリックします。 -3. **Create Connector**ページで**RocketMQ**を選択し、**Next**をクリックします。 -4. **Configuration**ステップで以下を設定します： +1. EMQXダッシュボードにアクセスし、**Integration** -> **Connectors** をクリックします。 +2. 画面右上の **Create** をクリックします。 +3. **Create Connector** ページで **RocketMQ** を選択し、**Next** をクリックします。 +4. **Configuration** ステップで以下の情報を設定します： - **Connector name**：コネクター名を入力します。英数字の組み合わせで、例：`my_rocketmq` - - **Servers**：`127.0.0.1:9876`を入力 - - **Namespace**：RocketMQサービスにネームスペースが設定されていなければ空欄のまま。 - - **AccessKey**、**SecretKey**、**Secret Token**：サービス構成に応じて空欄または入力 - - その他はデフォルトのまま -5. 詳細設定（任意）：[Sinkの機能](./data-bridges.md#features-of-sink)を参照 -6. **Create**をクリックする前に、**Test Connectivity**でRocketMQサーバーへの接続確認が可能です。 -7. ページ下部の**Create**ボタンをクリックしてコネクター作成を完了します。ポップアップで**Back to Connector List**か**Create Rule**を選択可能です。ルール作成については、[メッセージ保存用RocketMQ Sinkのルール作成](#create-a-rule-with-rocketmq-sink-for-message-storage)および[イベント記録用RocketMQ Sinkのルール作成](#create-a-rule-with-rocketmq-sink-for-events-recording)を参照してください。 + - **Servers**：`127.0.0.1:9876` と入力します。 + - **Namespace**：RocketMQサービスにネームスペース設定がある場合のみ入力し、なければ空欄のままにします。 + - **AccessKey**、**SecretKey**、**Secret Token**：RocketMQサービスの設定に応じて入力、または空欄のままにします。 + - その他はデフォルトのままにします。 +5. 詳細設定（任意）：詳細は[Sinkの特長](./data-bridges.md#features-of-sink)を参照してください。 +6. **Create**をクリックする前に、**Test Connectivity** をクリックしてコネクターがRocketMQサーバーに接続できるかテストできます。 +7. 画面下部の **Create** ボタンをクリックしてコネクターの作成を完了します。ポップアップダイアログで **Back to Connector List** または **Create Rule** を選択可能です。ルールを作成してRocketMQへのデータ転送やクライアントイベントの記録を指定する場合は、[メッセージ保存用RocketMQ Sinkのルール作成](#create-a-rule-with-rocketmq-sink-for-message-storage)および[イベント記録用RocketMQ Sinkのルール作成](#create-a-rule-with-rocketmq-sink-for-events-recording)を参照してください。 ## メッセージ保存用RocketMQ Sinkのルール作成 -このセクションでは、ダッシュボードでソースMQTTトピック`t/#`のメッセージを処理し、処理済みデータを設定済みのSink経由でRocketMQトピック`TopicTest`に転送するルールの作成方法を説明します。 +本節では、ソースMQTTトピック `t/#` からのメッセージを処理し、処理済みデータを設定済みのSinkを介してRocketMQトピック `TopicTest` に転送するルールをダッシュボード上で作成する方法を示します。 -1. EMQXダッシュボードで**Integration** -> **Rules**をクリックします。 +1. EMQXダッシュボードで **Integration** -> **Rules** をクリックします。 -2. ページ右上の**Create**をクリックします。 +2. 画面右上の **Create** をクリックします。 -3. ルールIDに`my_rule`を入力します。メッセージ保存用ルールのSQL文は以下の通りです。これはトピック`t/#`配下のMQTTメッセージをRocketMQに保存することを意味します。 +3. ルールIDに `my_rule` と入力し、メッセージ保存用のルールとして以下のSQL文を **SQL Editor** に入力します。これはトピック `t/#` 配下のMQTTメッセージをRocketMQに保存することを意味します。 - 注意：独自のSQL文を指定する場合は、Sinkが必要とするすべてのフィールドを`SELECT`句に含めてください。 + 注意：独自のSQL文を指定する場合は、Sinkが必要とするすべてのフィールドを `SELECT` 部分に含めてください。 ```sql SELECT @@ -175,47 +175,47 @@ Linux環境では、`host.docker.internal`を実際のIPアドレスに変更し ::: tip - 初心者の方は**SQL Examples**や**Enable Test**を使ってSQLルールの学習とテストが可能です。 + 初心者の方は、**SQL Examples** をクリックし、**Enable Test** を有効にしてSQLルールの学習とテストを行うことを推奨します。 ::: -4. + **Add Action**ボタンをクリックし、ルールでトリガーされるアクションを定義します。このアクションによりEMQXはルールで処理したデータをRocketMQに送信します。 +4. + **Add Action** ボタンをクリックし、ルール発動時にトリガーされるアクションを定義します。このアクションにより、EMQXはルールで処理したデータをRocketMQに送信します。 -5. **Type of Action**ドロップダウンから`RocketMQ`を選択します。**Action**はデフォルトの`Create Action`のままにします。既存のSinkがあれば選択可能ですが、ここでは新規Sinkを作成します。 +5. **Type of Action** ドロップダウンリストから `RocketMQ` を選択します。**Action** はデフォルトの `Create Action` のままにします。既に作成済みのSinkがあれば選択可能ですが、本デモでは新規Sinkを作成します。 -6. Sinkの名前を入力します。英数字の組み合わせで指定してください。 +6. Sink名を入力します。英数字の組み合わせで入力してください。 -7. **Connector**ドロップダウンから先に作成した`my_rocketmq`を選択します。新規コネクターはドロップダウン横のボタンで作成可能です。設定パラメータは[コネクターの作成](#create-a-connector)を参照してください。 +7. **Connector** ドロップダウンから先に作成した `my_rocketmq` を選択します。新規コネクターを作成する場合はドロップダウン横のボタンをクリックしてください。設定パラメータの詳細は[コネクターの作成](#create-a-connector)を参照してください。 -8. **RocketMQ Topic**欄に`TopicTest`を入力します。 +8. **RocketMQ Topic** フィールドに `TopicTest` と入力します。 -9. **Template**はデフォルトで空欄のままにします。 +9. **Template** はデフォルトで空欄のままにします。 ::: tip - 空欄の場合、メッセージ全体がRocketMQに転送されます。実際にはJSONテンプレートデータです。 + この値が空欄の場合、メッセージ全体がRocketMQに転送されます。実際の値はJSONテンプレートデータです。 ::: -10. **Fallback Actions（任意）**：メッセージ配信失敗時の信頼性向上のため、1つ以上のフォールバックアクションを定義できます。詳細は[Fallback Actions](./data-bridges.md#fallback-actions)を参照してください。 +10. **Fallback Actions（オプション）**：メッセージ配信失敗時の信頼性向上のため、1つ以上のフォールバックアクションを定義できます。詳細は[フォールバックアクション](./data-bridges.md#fallback-actions)を参照してください。 -11. **詳細設定（任意）**：[Sinkの機能](./data-bridges.md#features-of-sink)を参照してください。 +11. **詳細設定（オプション）**：詳細は[Sinkの特長](./data-bridges.md#features-of-sink)を参照してください。 -12. **Create**をクリックする前に、**Test Connectivity**でSinkがRocketMQサーバーに接続できるか確認できます。 +12. **Create** をクリックする前に、**Test Connectivity** をクリックしてSinkがRocketMQサーバーに接続できるかテストできます。 -13. **Create**ボタンをクリックし、Sink設定を完了します。新しいSinkが**Action Outputs**に追加されます。 +13. **Create** ボタンをクリックしてSink設定を完了します。新しいSinkが **Action Outputs** に追加されます。 -14. **Create Rule**ページに戻り、設定内容を確認後、**Create**ボタンをクリックしてルールを生成します。 +14. **Create Rule** ページに戻り、設定内容を確認して **Create** をクリックしルールを生成します。 -これでRocketMQ Sink用のルール作成が完了しました。**Integration** -> **Rules**ページで新規作成したルールを確認できます。**Actions(Sink)**タブをクリックすると新しいRocketMQ Sinkが表示されます。 +これでRocketMQ Sink用のルールが正常に作成されました。**Integration** -> **Rules** ページで新規ルールを確認でき、**Actions(Sink)** タブで新しいRocketMQ Sinkを確認できます。 -また、**Integration** -> **Flow Designer**でトポロジーを確認すると、トピック`t/#`配下のメッセージがルール`my_rule`で解析され、RocketMQに送信・保存されていることがわかります。 +また、**Integration** -> **Flow Designer** をクリックするとトポロジーが表示され、トピック `t/#` 配下のメッセージがルール `my_rule` によって解析され、RocketMQに送信・保存されていることが確認できます。 ## イベント記録用RocketMQ Sinkのルール作成 -このセクションでは、クライアントのオンライン／オフライン状態を記録し、イベントデータを設定済みSink経由でRocketMQトピック`TestTopic`に転送するルールの作成方法を説明します。 +本節では、クライアントのオンライン／オフライン状態を記録し、イベントデータを設定済みのSinkを介してRocketMQトピック `TestTopic` に転送するルールの作成方法を示します。 -ルール作成手順は[メッセージ保存用RocketMQ Sinkのルール作成](#create-a-rule-with-rocketmq-sink-for-message-storage)とほぼ同様ですが、SQLルールの文法が異なります。 +ルール作成手順は[メッセージ保存用RocketMQ Sinkのルール作成](#create-a-rule-with-rocketmq-sink-for-message-storage)とほぼ同様ですが、SQLルール文が異なります。 オンライン／オフライン状態記録用のSQLルール文は以下の通りです： @@ -228,23 +228,23 @@ FROM ::: tip -便宜上、オンライン／オフラインイベントの受信用に`TopicTest`トピックを再利用します。 +利便性のため、オンライン／オフラインイベントの受信には `TopicTest` トピックを再利用します。 ::: ## ルールのテスト -MQTTXを使ってトピック`t/1`にメッセージを送信し、オンライン／オフラインイベントをトリガーします。 +MQTTXを使ってトピック `t/1` にメッセージを送信し、オンライン／オフラインイベントをトリガーします。 ```bash mqttx pub -i emqx_c -t t/1 -m '{ "msg": "hello RocketMQ" }' ``` -Sinkの稼働状況を確認すると、新規の受信メッセージと送信メッセージが1件ずつあるはずです。 +Sinkの稼働状況を確認すると、新規の受信メッセージと送信メッセージがそれぞれ1件ずつあるはずです。 -データが`TopicTest`トピックに転送されているか確認してください。 +データが `TopicTest` トピックに転送されているか確認してください。 -以下のようなデータがコンシューマーに表示されます。 +以下のデータがコンシューマにより出力されます。 ```bash ConsumeMessageThread_please_rename_unique_group_name_4_1 Receive New Messages: [MessageExt [brokerName=broker-a, queueId=3, storeSize=581, queueOffset=0, sysFlag=0, bornTimestamp=1679037578889, bornHost=/172.26.83.106:43920, storeTimestamp=1679037578891, storeHost=/172.26.83.106:10911, msgId=AC1A536A00002A9F000000000000060E, commitLogOffset=1550, bodyCRC=7414108, reconsumeTimes=0, preparedTransactionOffset=0, toString()=Message{topic='TopicTest', flag=0, properties={MIN_OFFSET=0, MAX_OFFSET=8, CONSUME_START_TIME=1679037605342, CLUSTER=DefaultCluster}, body=[...], transactionId='null'}]] diff --git a/ja_JP/data-integration/snowflake.md b/ja_JP/data-integration/snowflake.md index 1d7858735..91d8f4cfd 100644 --- a/ja_JP/data-integration/snowflake.md +++ b/ja_JP/data-integration/snowflake.md @@ -1,93 +1,146 @@ -# Snowflake への MQTT データ取り込み +# SnowflakeへのMQTTデータ取り込み -[Snowflake](https://www.snowflake.com/en/) は、クラウドベースのデータプラットフォームであり、高いスケーラビリティと柔軟性を備えたデータウェアハウジング、分析、および安全なデータ共有のソリューションを提供します。構造化データおよび半構造化データの処理に優れ、大量のデータを高速なクエリ性能で保存し、さまざまなツールやサービスとシームレスに統合できるよう設計されています。 +[Snowflake](https://www.snowflake.com/en/) は、クラウドベースのデータプラットフォームであり、データウェアハウジング、分析、および安全なデータ共有のための高いスケーラビリティと柔軟性を提供します。構造化データおよび半構造化データの処理に優れており、大量のデータを格納しつつ、高速なクエリ性能とさまざまなツールやサービストとのシームレスな統合を実現するよう設計されています。 -本ページでは、EMQX と Snowflake 間のデータ統合について詳しく紹介し、ルールおよび Sink の作成方法について実践的なガイドを提供します。 +本ページでは、EMQXとSnowflake間のデータ統合について詳細に紹介し、ルールとSinkの作成方法について実践的なガイドを提供します。 ## 動作概要 -EMQX における Snowflake データ統合はすぐに使える機能であり、複雑なビジネス開発にも簡単に設定可能です。典型的な IoT アプリケーションでは、EMQX がデバイス接続とメッセージ送受信を担う IoT プラットフォームとして機能し、Snowflake はメッセージデータの取り込み、保存、分析を担当するデータストレージおよび処理プラットフォームとして利用されます。 +EMQXにおけるSnowflakeデータ統合は、複雑なビジネス開発に対応可能な簡単に設定できる機能です。典型的なIoTアプリケーションでは、EMQXがデバイス接続とメッセージ送信を担うIoTプラットフォームとして機能し、Snowflakeはメッセージデータの取り込み、格納、分析を行うデータストレージおよび処理プラットフォームとして役割を果たします。 ![snowflake-architecture](./assets/snowflake-architecture.png) -EMQX はルールエンジンと Sink を利用してデバイスイベントやデータを Snowflake に転送します。エンドユーザーやアプリケーションは Snowflake のテーブル内のデータにアクセスできます。具体的なワークフローは以下の通りです： +EMQXはルールエンジンとSinkを利用してデバイスイベントやデータをSnowflakeに転送します。エンドユーザーやアプリケーションはSnowflakeのテーブル内のデータにアクセス可能です。具体的なワークフローは以下の通りです。 -1. **デバイスの EMQX への接続**：IoT デバイスは MQTT プロトコルで正常に接続するとオンラインイベントをトリガーします。イベントにはデバイスID、送信元IPアドレスなどの情報が含まれます。 -2. **デバイスメッセージのパブリッシュと受信**：デバイスは特定のトピックを通じてテレメトリや状態データをパブリッシュします。EMQX はメッセージを受信し、ルールエンジン内で比較処理を行います。 -3. **ルールエンジンによるメッセージ処理**：組み込みのルールエンジンはトピックマッチングに基づき特定のソースからのメッセージやイベントを処理します。対応するルールをマッチングし、データ形式変換、特定情報のフィルタリング、コンテキスト情報の付加などの処理を行います。 -4. **Snowflake への書き込み**：ルールはメッセージを Snowflake Stage に書き込み、そこから Snowflake テーブルにロードするアクションをトリガーします。 +1. **デバイスのEMQXへの接続**：IoTデバイスはMQTTプロトコルで正常に接続されるとオンラインイベントをトリガーします。このイベントにはデバイスID、送信元IPアドレスなどのプロパティ情報が含まれます。 +2. **デバイスのメッセージパブリッシュと受信**：デバイスは特定のトピックを通じてテレメトリやステータスデータをパブリッシュします。EMQXはメッセージを受信し、ルールエンジン内で比較処理を行います。 +3. **ルールエンジンによるメッセージ処理**：組み込みのルールエンジンはトピックマッチングに基づいて特定のソースからのメッセージやイベントを処理します。対応するルールにマッチしたメッセージやイベントに対して、データフォーマット変換、特定情報のフィルタリング、コンテキスト情報の付加などの処理を行います。 +4. **Snowflakeへの書き込み**：ルールはSnowflake Stageへのメッセージ書き込みアクションをトリガーし、その後Snowflakeテーブルにロードします。 -イベントやメッセージデータが Snowflake に書き込まれた後は、以下のようなビジネスや技術的な目的で利用可能です： +イベントやメッセージデータがSnowflakeに書き込まれた後は、以下のようなビジネスおよび技術的な目的で利用可能です。 -- **データアーカイブ**：IoT データを Snowflake に安全に長期保存し、コンプライアンスや過去データの利用を保証します。 -- **データ分析**：Snowflake のデータウェアハウジングおよび分析機能を活用し、リアルタイムまたはバッチ分析を行い、予知保全、運用インサイト、デバイス性能評価を可能にします。 +- **データアーカイブ**：IoTデータをSnowflakeに安全に長期保存し、コンプライアンスや履歴データの利用を保証します。 +- **データ分析**：Snowflakeのデータウェアハウジングおよび分析機能を活用し、リアルタイムまたはバッチ分析を実施。予知保全、運用インサイト、デバイス性能評価などを可能にします。 ## 特長と利点 -EMQX の Snowflake データ統合を利用することで、以下の特長と利点が得られます： +EMQXのSnowflakeデータ統合を利用することで、以下の特長と利点がビジネスにもたらされます。 -- **メッセージ変換**：メッセージは EMQX のルール内で高度な処理や変換を経てから Snowflake に書き込まれるため、後続の保存や利用が容易になります。 -- **柔軟なデータ操作**：Snowflake Sink は、書き込むフィールドを選択可能であり、ビジネスニーズに応じた効率的かつ動的なストレージ構成が可能です。 -- **統合されたビジネスプロセス**：Snowflake Sink によりデバイスデータを Snowflake の豊富なエコシステムアプリケーションと組み合わせ、データ分析やアーカイブなど多様なビジネスシナリオを実現します。 -- **低コストの長期保存**：Snowflake のスケーラブルなストレージ基盤は、従来のデータベースに比べて低コストで長期データ保持に最適なソリューションです。大量の IoT データ保存に適しています。 +- **メッセージ変換**：メッセージはSnowflakeへの書き込み前にEMQXルール内で高度な処理や変換が可能であり、その後の格納や利用を容易にします。 +- **柔軟なデータ操作**：Snowflake Sinkは、書き込む特定フィールドの選択が可能であり、ビジネスニーズに応じた効率的かつ動的なストレージ構成を実現します。 +- **統合されたビジネスプロセス**：Snowflake Sinkにより、デバイスデータをSnowflakeの豊富なエコシステムアプリケーションと組み合わせることができ、データ分析やアーカイブなど多様なビジネスシナリオを実現します。 +- **低コストの長期保存**：Snowflakeのスケーラブルなストレージ基盤は、従来のデータベースに比べて低コストで長期データ保持に最適なソリューションを提供し、大量のIoTデータ保存に適しています。 -これらの特長により、効率的で信頼性が高くスケーラブルな IoT アプリケーションを構築し、ビジネスの意思決定や最適化に役立てることができます。 +これらの特長により、効率的で信頼性が高くスケーラブルなIoTアプリケーションの構築と、ビジネス意思決定や最適化の恩恵を受けられます。 ## はじめる前に -このセクションでは、EMQX で Snowflake Sink を作成する前に必要な準備について説明します。 +本節では、EMQXでSnowflake Sinkを作成する前に必要な準備について説明します。 ### 前提条件 -- [ルール](./rules.md) の理解 -- [データ統合](./data-bridges.md) の理解 +- [ルール](./rules.md)の理解 +- [データ統合](./data-bridges.md)の理解 -### Snowflake ODBC ドライバーの初期化 +### Snowflake ODBCドライバーの初期化 -EMQX が Snowflake と通信し効率的にデータ転送を行うために、Snowflake Open Database Connectivity (ODBC) ドライバーのインストールと設定が必要です。これは通信の橋渡し役となり、データの適切なフォーマット、認証、転送を保証します。 +EMQXがSnowflakeと通信し効率的にデータ転送を行うためには、Snowflake Open Database Connectivity（ODBC）ドライバーのインストールと設定が必要です。これは通信の橋渡しを行い、データの適切なフォーマット、認証、転送を保証します。 -詳細は公式の [ODBC Driver](https://docs.snowflake.com/en/developer-guide/odbc/odbc) ページおよび [ライセンス契約](https://sfc-repo.snowflakecomputing.com/odbc/Snowflake_ODBC_Driver_License_Agreement.pdf) を参照してください。 +詳細は公式の[ODBC Driver](https://docs.snowflake.com/en/developer-guide/odbc/odbc)ページおよび[ライセンス契約](https://sfc-repo.snowflakecomputing.com/odbc/Snowflake_ODBC_Driver_License_Agreement.pdf)を参照してください。 #### Linux -以下のスクリプトを実行して Snowflake ODBC ドライバーをインストールし、`odbc.ini` ファイルを設定します： +EMQXはDebian系（Ubuntuなど）向けにSnowflake ODBCドライバーの迅速なデプロイと必要なシステム設定を行う[インストールスクリプト](https://github.com/emqx/emqx/blob/master/scripts/install-snowflake-driver.sh)を提供しています。 +::: tip 注意 + +このスクリプトはテスト用であり、本番環境でのODBCドライバー設定方法の推奨ではありません。公式の[Linux向けインストール手順](https://docs.snowflake.com/en/developer-guide/odbc/odbc-linux)を参照してください。 + +::: + +**インストールスクリプトの実行** + +`scripts/install-snowflake-driver.sh`スクリプトをローカルにコピーし、`chmod a+x`で実行権限を付与後、`sudo`で実行します。 + +```bash +chmod a+x scripts/install-snowflake-driver.sh +sudo ./scripts/install-snowflake-driver.sh ``` -scripts/install-snowflake-driver.sh + +スクリプトはSnowflake ODBCの`.deb`インストールパッケージ（例：`snowflake-odbc-3.4.1.x86_64.deb`）をカレントディレクトリに自動ダウンロードし、ドライバーをインストール後、以下のシステム設定ファイルを更新します。 + +- `/etc/odbc.ini`：Snowflakeデータソース設定を追加 +- `/etc/odbcinst.ini`：Snowflakeドライバーのパスを登録 + +**設定例** + +`/etc/odbc.ini`の設定を確認するコマンド例： + ``` +emqx@emqx-0:~$ cat /etc/odbc.ini -::: tip 注意 +[snowflake] +Description=SnowflakeDB +Driver=SnowflakeDSIIDriver +Locale=en-US +PORT=443 +SSL=on -このスクリプトはテスト用であり、本番環境での ODBC ドライバー設定方法の推奨ではありません。公式の [Linux 向けインストール手順](https://docs.snowflake.com/en/developer-guide/odbc/odbc-linux) を参照してください。 +[ODBC Data Sources] +snowflake = SnowflakeDSIIDriver +``` -::: +`/etc/odbcinst.ini`の設定を確認するコマンド例： + +``` +emqx@emqx-0:~$ cat /etc/odbcinst.ini + +[ODBC Driver 18 for SQL Server] +Description=Microsoft ODBC Driver 18 for SQL Server +Driver=/opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.5.so.1.1 +UsageCount=1 + +[ODBC Driver 17 for SQL Server] +Description=Microsoft ODBC Driver 17 for SQL Server +Driver=/opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.10.so.6.1 +UsageCount=1 + +[SnowflakeDSIIDriver] +APILevel=1 +ConnectFunctions=YYY +Description=Snowflake DSII +Driver=/usr/lib/snowflake/odbc/lib/libSnowflake.so +DriverODBCVer=03.52 +SQLLevel=1 +UsageCount=1 +``` #### macOS -macOS で Snowflake ODBC ドライバーをインストールおよび設定する手順は以下の通りです： +macOSでSnowflake ODBCドライバーをインストールおよび設定するには、以下の手順に従ってください。 -1. unixODBC をインストール（例）： +1. unixODBCをインストールします（例）： ``` brew install unixodbc ``` -2. [iODBC をダウンロードしてインストール](https://github.com/openlink/iODBC/releases/download/v3.52.16/iODBC-SDK-3.52.16-macOS11.dmg)。 +2. [iODBCをダウンロードおよびインストール](https://github.com/openlink/iODBC/releases/download/v3.52.16/iODBC-SDK-3.52.16-macOS11.dmg)します。 -3. [Snowflake ODBC ドライバーをダウンロードしてインストール](https://sfc-repo.snowflakecomputing.com/odbc/macuniversal/3.3.2/snowflake_odbc_mac_64universal-3.3.2.dmg)。 +3. [Snowflake ODBCドライバーをダウンロードおよびインストール](https://sfc-repo.snowflakecomputing.com/odbc/macuniversal/3.3.2/snowflake_odbc_mac_64universal-3.3.2.dmg)します。 -4. 詳細なインストールおよび設定手順は [macOS 向け ODBC ドライバーのインストールと設定](https://docs.snowflake.com/en/developer-guide/odbc/odbc-mac) を参照してください。 +4. 詳細なインストールおよび設定手順は[macOS向けODBCドライバーのインストールと設定](https://docs.snowflake.com/en/developer-guide/odbc/odbc-mac)を参照してください。 -5. インストール後、以下の設定ファイルを更新します： +5. インストール後、以下の設定ファイルを更新します。 - - Snowflake ODBC ドライバーの権限と設定を更新： + - Snowflake ODBCドライバーの権限と設定を更新： ```bash chown $(id -u):$(id -g) /opt/snowflake/snowflakeodbc/lib/universal/simba.snowflake.ini echo 'ODBCInstLib=libiodbcinst.dylib' >> /opt/snowflake/snowflakeodbc/lib/universal/simba.snowflake.ini ``` - - `~/.odbc.ini` ファイルを作成または更新して ODBC 接続を設定： + - `~/.odbc.ini`ファイルを作成または更新し、ODBC接続を設定： ``` cat << EOF > ~/.odbc.ini @@ -108,36 +161,36 @@ macOS で Snowflake ODBC ドライバーをインストールおよび設定す ### ユーザーアカウントとデータベースの作成 -Snowflake ODBC ドライバーをインストールしたら、データ取り込み用のユーザーアカウント、データベース、および関連リソースを設定します。これらの認証情報は後で EMQX のコネクターおよび Sink 設定時に使用します。 +Snowflake ODBCドライバーをインストールしたら、データ取り込み用のユーザーアカウント、データベース、および関連リソースを設定する必要があります。以下の認証情報は後でEMQXのコネクターおよびSink設定時に使用します。 -| フィールド名 | 値 | -| -------------------------- | ------------------------------------------------ | -| Data Source Name (DSN) | `snowflake` | -| ユーザー名 | `snowpipeuser` | -| パスワード | `Snowpipeuser99` | -| データベース名 | `testdatabase` | -| スキーマ | `public` | -| ステージ | `emqx` | -| パイプ | `emqx` | -| パイプユーザー | `snowpipeuser` | -| プライベートキー | `file://` | +| 項目名 | 値 | +| ----------------------- | ------------------------------------------------ | +| データソース名（DSN） | `snowflake` | +| ユーザー名 | `snowpipeuser` | +| パスワード | `Snowpipeuser99` | +| データベース名 | `testdatabase` | +| スキーマ | `public` | +| ステージ | `emqx` | +| パイプ | `emqx` | +| パイプユーザー | `snowpipeuser` | +| プライベートキー | `file://` | -#### RSA キーペアの生成 +#### RSA鍵ペアの生成 -Snowflake への安全な接続のため、以下のコマンドで認証用の RSA キーペアを生成します： +Snowflakeへの安全な接続のため、以下のコマンドでRSA鍵ペアを生成します。 ```bash openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out snowflake_rsa_key.private.pem -nocrypt openssl rsa -in snowflake_rsa_key.private.pem -pubout -out snowflake_rsa_key.public.pem ``` -詳細は [キーペア認証とキーペアローテーション](https://docs.snowflake.com/en/user-guide/key-pair-auth) を参照してください。 +詳細は[鍵ペア認証と鍵ペアローテーション](https://docs.snowflake.com/en/user-guide/key-pair-auth)を参照してください。 -#### SQL を使った Snowflake リソースのセットアップ +#### SQLによるSnowflakeリソースの設定 -ODBC ドライバーのセットアップと RSA キーペア生成後、Snowflake のリソースを設定します。SQL コマンドを使ってデータベース、テーブル、ステージ、パイプを作成します。 +ODBCドライバー設定とRSA鍵ペア生成後、Snowflakeリソースのセットアップを行います。SnowflakeコンソールのSQLワークシートで以下のSQLを実行し、データベース、テーブル、ステージ、パイプを作成します。 -1. Snowflake コンソールの SQL ワークシートを開き、以下の SQL を実行してデータベース、テーブル、ステージ、パイプを作成します： +1. データベース、テーブル、ステージ、パイプの作成： ```sql USE ROLE accountadmin; @@ -161,7 +214,7 @@ ODBC ドライバーのセットアップと RSA キーペア生成後、Snowfla MATCH_BY_COLUMN_NAME = CASE_INSENSITIVE; ``` -2. 新しいユーザーを作成し、そのユーザーに RSA 公開鍵を設定します： +2. 新規ユーザーの作成とRSA公開鍵の設定： ```sql CREATE USER IF NOT EXISTS snowpipeuser @@ -178,11 +231,11 @@ ODBC ドライバーのセットアップと RSA キーペア生成後、Snowfla ::: tip - PEM ファイルの `-----BEGIN PUBLIC KEY-----` および `-----END PUBLIC KEY-----` 行は削除し、残りの内容を改行を保持したまま含めてください。 + PEMファイルの`-----BEGIN PUBLIC KEY-----`および`-----END PUBLIC KEY-----`の行は削除し、残りの内容を改行を保持したまま記載してください。 ::: -3. ユーザーが Snowflake リソースを管理できるように必要なロールを作成し割り当てます： +3. ユーザーに必要なロールを作成し割り当て： ```sql CREATE OR REPLACE ROLE snowpipe; @@ -198,34 +251,62 @@ ODBC ドライバーのセットアップと RSA キーペア生成後、Snowfla ## コネクターの作成 -Snowflake Sink を追加する前に、EMQX で Snowflake への接続を確立するためのコネクターを作成します。 +Snowflake Sinkを追加する前に、EMQXでSnowflakeとの接続を確立するためのコネクターを作成します。 1. ダッシュボードの **Integration** -> **Connector** ページに移動します。 + 2. 右上の **Create** ボタンをクリックします。 + 3. コネクタータイプとして **Snowflake** を選択し、次へ進みます。 + 4. コネクター名を入力します。英数字の組み合わせで、ここでは `my-snowflake` と入力します。 + 5. 接続情報を入力します。 - - **Account**：Snowflake の組織IDとアカウント名をハイフン（`-`）で区切って入力します。これは Snowflake プラットフォームの URL の一部で、Snowflake コンソールで確認可能です。 - - **Server Host**：Snowflake のエンドポイント URL で、通常 `-.snowflakecomputing.com` の形式です。`-` はご自身の Snowflake インスタンス固有のサブドメインに置き換えてください。 - - **Data Source Name(DSN)**：ODBC ドライバー設定時に `.odbc.ini` ファイルで設定した `snowflake` を入力します。 - - **Username**：前述の設定で作成した `snowpipeuser` を入力します。 - - **Password**：前述の設定で定義した `Snowpipeuser99` を入力します。 -6. 暗号化接続を確立したい場合は、**Enable TLS** のトグルスイッチをオンにします。TLS 接続の詳細は [TLS for External Resource Access](../network/overview.md/#tls-for-external-resource-access) を参照してください。 -7. 詳細設定（任意）：[Advanced Settings](#advanced-settings) を参照してください。 -8. **Create** をクリックする前に、**Test Connectivity** ボタンでコネクターが Snowflake に接続できるかテストできます。 -9. 最後に、ページ下部の **Create** ボタンをクリックしてコネクター作成を完了します。 + - **Server Host**：SnowflakeのエンドポイントURLで、通常は `-.snowflakecomputing.com` の形式です。`-` はSnowflakeインスタンス固有のサブドメインに置き換えてください。 + + - **Data Source Name(DSN)**：ODBCドライバー設定時に`.odbc.ini`ファイルで設定した`snowflake`を入力します。 + + - **Account**：Snowflakeの組織IDとアカウント名をハイフン（`-`）で区切ったものを入力します。これはSnowflakeプラットフォームにアクセスするURLの一部で、Snowflakeコンソールで確認可能です。 + + - **Username**：前述のセットアップで作成した`snowpipeuser`を入力します。 + + - **Password**：ODBC経由でユーザー名／パスワード認証を行う場合のパスワードです。任意入力です。 + + - ここに`Snowpipeuser99`などのパスワードを入力するか、 + - `/etc/odbc.ini`に設定するか、 + - 鍵ペア認証を使用する場合は空欄にします。 + + ::: tip + + 認証はパスワードかプライベートキーのいずれか一方を使用してください。両方設定しない場合は、適切な認証情報が`/etc/odbc.ini`に設定されていることを確認してください。 + + ::: + + - **Proxy**：HTTPプロキシサーバー経由でSnowflakeに接続する場合の設定です。HTTPSプロキシはサポートされていません。デフォルトはプロキシなしです。プロキシを有効にするには`Enable Proxy`を選択し、以下を入力します。 + - **Proxy Host**：プロキシサーバーのホスト名またはIPアドレス + - **Proxy Port**：プロキシサーバーのポート番号 + - **Private Key Path**：ODBC経由でSnowflakeに鍵ペア認証を行う際のプライベートRSA鍵の絶対ファイルパス。クラスター内の全ノードで同一パスかつEMQXアプリケーションユーザーがアクセス可能である必要があります。`file://`で始まるパスを指定します（例：`file:///etc/emqx/certs/snowflake_rsa_key.private.pem`）。 + - **Private Key Password**：プライベートRSA鍵ファイルが暗号化されている場合の復号パスワード。OpenSSLの`-nocrypt`オプションで生成した鍵は暗号化されていないため空欄にします。 + +6. 暗号化接続を確立したい場合は、**Enable TLS**のトグルスイッチをオンにします。TLS接続の詳細は[外部リソースアクセスのTLS](../network/overview.md/#tls-for-external-resource-access)を参照してください。 -これでコネクターの作成が完了し、次にルールと Sink を作成してデータの書き込み方法を指定できます。 +7. 詳細設定（任意）：[詳細設定](#advanced-settings)を参照してください。 -## Snowflake Sink を使ったルールの作成 +8. **Create**をクリックする前に、**Test Connectivity**をクリックしてコネクターがSnowflakeに接続できるかテスト可能です。 -このセクションでは、EMQX でソース MQTT トピック `t/#` からのメッセージを処理し、処理結果を設定済みの Snowflake Sink を通じて Snowflake に書き込むルールの作成方法を示します。 +9. 最後に、画面下部の**Create**ボタンをクリックしてコネクター作成を完了します。 + +これでコネクター作成が完了し、次にルールとSinkを作成してデータのSnowflakeへの書き込み方法を指定できます。 + +## Snowflake Sinkを用いたルールの作成 + +本節では、EMQXでソースMQTTトピック`t/#`のメッセージを処理し、処理結果を設定済みのSnowflake Sinkを通じてSnowflakeに書き込むルールの作成方法を示します。 1. ダッシュボードの **Integration** -> **Rules** ページに移動します。 2. 右上の **Create** ボタンをクリックします。 -3. ルールID に `my_rule` と入力し、SQL エディターに以下のルール SQL を入力します： +3. ルールIDに `my_rule` を入力し、SQLエディタに以下のルールSQLを入力します。 ```sql SELECT @@ -239,97 +320,94 @@ Snowflake Sink を追加する前に、EMQX で Snowflake への接続を確立 ::: tip - SQL に不慣れな場合は、**SQL Examples** をクリックし、**Enable Debug** を有効にしてルール SQL の結果を学習・テストできます。 + SQLに不慣れな場合は、**SQL Examples**や**Enable Debug**をクリックしてルールSQLの学習やテストが可能です。 ::: - ::: tip - - Snowflake 連携では、選択するフィールドが Snowflake 側で定義したテーブルのカラム数および名前と完全に一致していることが重要です。余分なフィールドを追加したり、`*` で全選択することは避けてください。 - + + Snowflake連携では、選択するフィールドがSnowflakeのテーブル定義のカラム数および名前と正確に一致することが重要です。余分なフィールドを追加したり、`*`で全選択することは避けてください。 + ::: -4. アクションを追加し、**Action Type** ドロップダウンリストから `Snowflake` を選択します。アクションのドロップダウンはデフォルトの `create action` のままにするか、既存の Snowflake アクションを選択します。ここでは新しい Sink を作成してルールに追加します。 - -5. Sink の名前（例：`snowflake_sink`）と簡単な説明を入力します。 - -6. 先に作成した `my-snowflake` コネクターをコネクタードロップダウンから選択します。ドロップダウン横の作成ボタンをクリックしてポップアップで新規コネクターを素早く作成することも可能です。必要な設定パラメータは [Create a Connector](#create-a-connector) を参照してください。 +4. アクションを追加し、**Action Type**のドロップダウンから`Snowflake`を選択します。アクションのドロップダウンはデフォルトの`create action`のままにするか、既存のSnowflakeアクションを選択します。ここでは新規Sinkを作成しルールに追加します。 -7. 以下の設定を行います： +5. Sinkの名前（例：`snowflake_sink`）と簡単な説明を入力します。 - - **Database Name**：`testdatabase` を入力。EMQX データ保存用に作成した Snowflake データベースです。 - - **Schema**：`public` を入力。`testdatabase` 内のデータテーブルがあるスキーマです。 - - **Stage**：`emqx` を入力。Snowflake でデータをテーブルにロードする前に保持するステージです。 - - **Pipe**：`emqx` を入力。ステージからテーブルへのロード処理を自動化するパイプです。 - - **Pipe User**：`snowpipeuser` を入力。パイプ管理権限を持つ Snowflake ユーザーです。 - - **Private Key**：RSA プライベートキーのパス（例：`file://`）または RSA プライベートキーファイルの内容を入力します。これは安全な認証に使用され、Snowflake パイプへの安全なアクセスに必要です。ファイルパスを使用する場合は、クラスタ内のすべてのノードでパスが一貫しており、EMQX アプリケーションユーザーがアクセス可能である必要があります。 +6. 先ほど作成した`my-snowflake`コネクターをコネクタードロップダウンから選択します。隣の作成ボタンをクリックしてポップアップで新規コネクターを素早く作成することも可能です。設定パラメーターは[コネクターの作成](#コネクターの作成)を参照してください。 -8. **Upload Mode** を選択します。現在は `Aggregated Upload` のみサポートしています。この方法は複数のルールトリガー結果を単一ファイル（例：CSV ファイル）にまとめて Snowflake にアップロードし、ファイル数を減らして書き込み効率を向上させます。 +7. 以下の設定を行います。 -9. **Aggregation Type** を選択します。現在は `csv` のみサポートしています。データはカンマ区切りの CSV 形式で Snowflake にステージングされます。 + - **Database Name**：`testdatabase`を入力。EMQXデータ格納用に作成したSnowflakeデータベースです。 + - **Schema**：`public`を入力。`testdatabase`内のデータテーブルがあるスキーマ名です。 + - **Stage**：`emqx`を入力。Snowflakeでデータをテーブルにロードする前に保持するステージ名です。 + - **Pipe**：`emqx`を入力。ステージからテーブルへのロード処理を自動化するパイプ名です。 + - **Pipe User**：`snowpipeuser`を入力。パイプ管理権限を持つSnowflakeユーザー名です。 + - **Private Key**：プライベートRSA鍵のパス（例：`file://`）またはRSAプライベート鍵ファイルの内容を入力します。安全な認証に必要で、Snowflakeパイプへのアクセスに使用します。ファイルパス指定の場合はクラスター全ノードで同一かつEMQXアプリケーションユーザーがアクセス可能である必要があります。 - - **Column Order**：ドロップダウンリストから列の順序を選択します。生成される CSV ファイルは、選択した列の順序でソートされ、未選択の列はアルファベット順にソートされます。 +8. **Upload Mode**を選択します。現在は`Aggregated Upload`のみサポートされています。この方式は複数のルールトリガー結果を1つのファイル（例：CSVファイル）にまとめてSnowflakeにアップロードし、ファイル数を減らして書き込み効率を向上させます。 - - **Max Records**：集約がトリガーされる最大レコード数を設定します。例えば `1000` に設定すると、1000 レコード収集後にアップロードされます。最大レコード数に達すると単一ファイルの集約が完了しアップロードされ、時間間隔がリセットされます。 +9. **Aggregation Type**を選択します。現在は`csv`のみサポートされており、データはカンマ区切りCSV形式でSnowflakeにステージングされます。 - - **Time Interval**：集約が行われる時間間隔（秒）を設定します。例えば `60` に設定すると、最大レコード数に達していなくても 60 秒ごとにデータがアップロードされ、最大レコード数がリセットされます。 + - **Column Order**：ドロップダウンからカラムの並び順を選択します。生成されるCSVファイルは、選択したカラム順にソートされ、未選択カラムはアルファベット順にソートされます。 + - **Max Records**：集約をトリガーする最大レコード数を設定します。例：`1000`に設定すると1000件のレコードを収集後にアップロードされます。最大レコード数に達すると1ファイルの集約が完了しアップロードされ、時間間隔がリセットされます。 + - **Time Interval**：集約を行う時間間隔（秒）を設定します。例：`60`に設定すると最大レコード数に達していなくても60秒ごとにデータがアップロードされ、最大レコード数がリセットされます。 -10. **フォールバックアクション（任意）**：メッセージ配信失敗時の信頼性向上のため、1つ以上のフォールバックアクションを定義できます。これらはプライマリ Sink がメッセージ処理に失敗した場合にトリガーされます。詳細は [Fallback Actions](./data-bridges.md#fallback-actions) を参照してください。 +10. **フォールバックアクション（任意）**：メッセージ配信失敗時の信頼性向上のため、1つ以上のフォールバックアクションを定義可能です。プライマリSinkがメッセージ処理に失敗した場合にトリガーされます。詳細は[フォールバックアクション](./data-bridges.md#fallback-actions)を参照してください。 -11. **Advanced Settings** を展開し、必要に応じて詳細設定を行います（任意）。詳細は [Advanced Settings](#advanced-settings) を参照してください。 +11. **詳細設定**を展開し、必要に応じて高度な設定オプションを構成します（任意）。詳細は[詳細設定](#advanced-settings)を参照してください。 -12. 残りの設定はデフォルト値のままにし、**Create** ボタンをクリックして Sink 作成を完了します。作成成功後、ルール作成画面に戻り、新しい Sink がルールアクションに追加されます。 +12. 残りの設定はデフォルト値のままにし、**Create**ボタンをクリックしてSink作成を完了します。作成成功後はルール作成画面に戻り、新規Sinkがルールアクションに追加されます。 -13. ルール作成画面で **Create** ボタンをクリックし、ルール作成全体を完了します。 +13. ルール作成画面で**Create**ボタンをクリックし、ルール作成全体を完了します。 -これでルールの作成が完了しました。**Rules** ページで新規作成したルールを確認でき、**Actions (Sink)** タブで新しい Snowflake Sink を確認できます。 +これでルールが正常に作成されました。**Rules**ページで新規ルールを確認でき、**Actions (Sink)**タブで新規Snowflake Sinkを確認できます。 -また、**Integration** -> **Flow Designer** をクリックするとトポロジーを視覚的に確認できます。トポロジーは、トピック `t/#` のメッセージがルール `my_rule` によって解析され、Snowflake に書き込まれる流れを示します。 +また、**Integration** -> **Flow Designer**をクリックするとトポロジーを視覚的に確認可能です。トポロジーはトピック`t/#`のメッセージがルール`my_rule`で解析され、Snowflakeに書き込まれる流れを示します。 ## ルールのテスト -このセクションでは、設定したルールのテスト方法を示します。 +設定したルールの動作確認方法を示します。 ### テストメッセージのパブリッシュ -MQTTX を使ってトピック `t/1` にメッセージをパブリッシュします： +MQTTクライアントMQTTXを使用してトピック`t/1`にメッセージをパブリッシュします。 ```bash mqttx pub -i emqx_c -t t/1 -m '{ "msg": "Hello Snowflake" }' ``` -この操作を数回繰り返して複数のテストメッセージを生成してください。 +複数回繰り返し、テストメッセージを生成してください。 -### Snowflake 内のデータ確認 +### Snowflake内のデータ確認 -テストメッセージ送信後、Snowflake にデータが正常に書き込まれたかを確認します。 +テストメッセージ送信後、Snowflakeにデータが正常に書き込まれたか確認します。 -1. Snowflake のウェブインターフェースを開き、認証情報で Snowflake コンソールにログインします。 +1. SnowflakeのWebインターフェースを開き、認証情報でSnowflakeコンソールにログインします。 -2. Snowflake コンソールで以下の SQL クエリを実行し、ルールによって書き込まれた `emqx` テーブルのデータを表示します： +2. Snowflakeコンソールで以下のSQLを実行し、ルールで書き込まれた`emqx`テーブルのデータを確認します。 ``` SELECT * FROM testdatabase.public.emqx; ``` - これにより、`emqx` テーブルにアップロードされたすべてのレコードが表示され、`clientid`、`topic`、`payload`、`publish_received_at` フィールドを確認できます。 + `emqx`テーブルにアップロードされたすべてのレコードが表示され、`clientid`、`topic`、`payload`、`publish_received_at`フィールドを含みます。 -3. 送信したテストメッセージ（例：`{ "msg": "Hello Snowflake" }`）や、トピック、タイムスタンプなどのメタデータが確認できるはずです。 +3. 送信したテストメッセージ（例：`{ "msg": "Hello Snowflake" }`）やトピック、タイムスタンプなどのメタデータが表示されるはずです。 ## 詳細設定 -このセクションでは、Snowflake Sink の詳細設定オプションについて説明します。ダッシュボードで Sink を設定する際、**Advanced Settings** を展開して以下のパラメータをニーズに応じて調整できます。 - -| フィールド名 | 説明 | デフォルト値 | -| -------------------------- | ------------------------------------------------------------------------------------------------ | -------------- | -| **Max Retries** | アップロード失敗時の最大リトライ回数を設定します。例えば `3` を入力すると3回までリトライします。 | `3` | -| **Buffer Pool Size** | バッファワーカープロセスの数を指定します。これらのワーカーは EMQX と Snowflake 間のデータフローを管理し、一時的にデータを保持・処理します。パフォーマンス最適化とスムーズなデータ送信に重要です。 | `16` | -| **Request TTL** | リクエストの有効期間（秒）を設定します。リクエストがバッファに入ってからの最大有効時間を指定し、この期間を超えたリクエストは期限切れとみなされます。レスポンスやアックがタイムリーに返らない場合も期限切れとなります。 | | -| **Health Check Interval** | Snowflake との接続の自動ヘルスチェックを行う間隔（秒）を指定します。 | `15` | -| **Max Buffer Queue Size** | Snowflake Sink の各バッファワーカーが保持可能な最大バイト数を指定します。バッファワーカーはデータを一時保管し、効率的にデータストリームを処理します。システム性能やデータ送信要件に応じて調整してください。 | `256` | -| **Query Mode** | リクエストモードを `synchronous` または `asynchronous` から選択し、メッセージ送信を最適化します。非同期モードでは Snowflake への書き込みが MQTT メッセージのパブリッシュをブロックしませんが、クライアントがメッセージ到達前に受信する可能性があります。 | `Asynchronous` | -| **Batch Size** | EMQX から Snowflake へ一度に送信するデータバッチの最大サイズを指定します。サイズ調整によりデータ転送の効率と性能を微調整できます。
`1` に設定すると、データレコードを個別に送信し、バッチ化しません。 | `1` | -| **Inflight Window** | "インフライトキューリクエスト" は開始済みでまだレスポンスやアックを受け取っていないリクエストを指します。この設定は Snowflake との通信中に同時に存在可能なインフライトリクエストの最大数を制御します。
**Request Mode** が `asynchronous` の場合、同一 MQTT クライアントからのメッセージを厳密に順序処理したい場合はこの値を `1` に設定してください。 | `100` | -| **Connect Timeout** | Snowflake への接続試行時のタイムアウト時間（秒）を指定します。例えば `30` 秒に設定すると、その時間内に接続できなければリトライ（**Max Retries** に基づく）またはエラーを発生させます。ネットワークレイテンシや接続信頼性管理に役立ちます。 | `15` | -| **HTTP Pipelining** | レスポンス待ちをせずに送信可能な HTTP リクエストの最大数を指定します。 | `100` | -| **Connection Pool Size** | EMQX が Snowflake に同時に維持可能な接続数を定義します。大きいほど同時リクエスト数が増え高負荷に対応可能ですが、システムリソース消費も増加します。 | `8` | +本節では、Snowflake Sinkの詳細設定オプションについて説明します。ダッシュボードのSink設定画面で**Advanced Settings**を展開し、用途に応じて以下のパラメーターを調整可能です。 + +| 項目名 | 説明 | デフォルト値 | +| ------------------------- | ------------------------------------------------------------ | ------------ | +| **Max Retries** | アップロード失敗時の最大リトライ回数を設定します。例：`3`で3回までリトライ可能。 | `3` | +| **Buffer Pool Size** | EMQXとSnowflake間のデータフローを管理するバッファーワーカープロセス数を指定します。これらのワーカーはデータを一時的に保持・処理し、ターゲットサービスへの送信を最適化しスムーズなデータ伝送を実現します。 | `16` | +| **Request TTL** | バッファに入ったリクエストが有効とみなされる最大時間（秒）を指定します。リクエストがこのTTLを超えてバッファ内に滞留するか、送信後にSnowflakeからの応答やアックがタイムリーに得られない場合、リクエストは期限切れとみなされます。 | | +| **Health Check Interval** | SinkがSnowflakeとの接続状態を自動的にヘルスチェックする間隔（秒）を指定します。 | `15` | +| **Max Buffer Queue Size** | Snowflake Sinkの各バッファーワーカーが一時的に保持可能な最大バイト数を指定します。バッファーワーカーはデータを一時的に保持し、Snowflakeへの送信を効率化します。システム性能やデータ伝送要件に応じて調整してください。 | `256` | +| **Query Mode** | `synchronous`または`asynchronous`のリクエストモードを選択し、メッセージ伝送を最適化します。非同期モードではSnowflakeへの書き込みがMQTTメッセージパブリッシュをブロックしませんが、クライアントがSnowflake到達前にメッセージを受信する可能性があります。 | `Asynchronous` | +| **Batch Size** | EMQXからSnowflakeへ一度に転送するデータバッチの最大サイズを指定します。サイズ調整によりデータ転送効率と性能を最適化可能です。
`1`に設定するとデータレコードは個別に送信され、バッチ化されません。 | `1` | +| **Inflight Window** | 「インフライトキューリクエスト」とは、送信済みで応答やアックをまだ受け取っていないリクエストを指します。この設定はSnowflakeとの通信中に同時に存在可能なインフライトリクエストの最大数を制御します。
**Request Mode**が`asynchronous`の場合、このパラメーターは特に重要です。同一MQTTクライアントからのメッセージを厳密に順序処理する必要がある場合は`1`に設定してください。 | `100` | +| **Connect Timeout** | Snowflakeへの接続確立を待つ最大時間（秒）を指定します。例：`30`秒。接続がこの時間内に確立できない場合、EMQXはリトライ（**Max Retries**設定に基づく）を試みるかエラーを返します。ネットワークレイテンシや接続信頼性管理に有効です。 | `15` | +| **HTTP Pipelining** | 応答待ちをせずに送信可能なHTTPリクエストの最大数を指定します。 | `100` | +| **Connection Pool Size** | EMQXがSnowflakeに同時に維持可能な接続数を定義します。大きいほど同時リクエスト数が増え高負荷に対応可能ですが、システムリソース消費も増加します。 | `8` | diff --git a/ja_JP/last_translation_commit b/ja_JP/last_translation_commit index f7b95ede3..6226c4e97 100644 --- a/ja_JP/last_translation_commit +++ b/ja_JP/last_translation_commit @@ -1 +1 @@ -c55404f5618e14f7e22283490c620bc71fe5cb6c +48e58284885863134e711be8fac382c9018db3a8