重要

このページの日本語コンテンツは古くなっている可能性があります。最新の英語版コンテンツをご覧になるには、こちらをクリックしてください。

Google Cloud BigQuery Sink Connector for Confluent Cloud¶

注釈

Confluent Platform 用にコネクターをローカルにインストールする場合は、「Google BigQuery Sink Connector for Confluent Platform」を参照してください。

Kafka Connect Google BigQuery Sink Connector for Confluent Cloud を使用すると、Avro、JSON スキーマ、Protobuf、または JSON（スキーマレス）フォーマットになっている Apache Kafka® トピックのデータを BigQuery にエクスポートすることができます。BigQuery テーブルのスキーマは、トピックの Apache Kafka® スキーマの情報に基づいて作成されます。

機能¶

このコネクターでは、挿入操作がサポートされており、重複検出が試行されます。詳細については、『ストリーミング挿入に関するトラブルシューティング』を参照してください。
このコネクターは、BigQuery の insertAll streaming api を使用しています。これはレコードを一度に 1 件ずつ挿入します。挿入されたレコードはすぐにテーブルで利用することができ、クエリの実行が可能になります。
このコネクターは、リストした一連のトピックから、BigQuery の対応する複数のテーブルにストリーミングすることをサポートしています。

注釈

多数のタスクで複数のコネクターを使用する場合は、必ず『ストリーミング挿入』を参照してください。
このコネクターは、デフォルトでは（バッチモードでの実行とは対照的に）レコードを一度に 1 件ずつストリームしますが、レコードを並列でストリームできる内部スレッドプールを備えているので、スケーラブルなコネクターでもあります。内部スレッドプールのデフォルトは 10 スレッドです。
このコネクターは、partitioning.type プロパティを使用した時間ベースのテーブルパーティション分割戦略を複数のサポートしています。
このコネクターは、Avro、JSON スキーマ、Protobuf、または JSON（スキーマレス）の入力データフォーマットをサポートします。スキーマレジストリベースのフォーマット（Avro、JSON_SR（JSON スキーマ）、Protobuf など）を使用するには、Schema Registry を有効にしておく必要があります。詳細については、「スキーマレジストリ Enabled Environments」を参照してください。
Avro については、テーブルの自動作成とアップデートをサポートする以下の構成プロパティを利用できます。これらのプロパティは UI で選択できます。Confluent CLI を使用する場合は、コネクター構成に追加できます。
- autoCreateTables: BigQuery テーブルが存在しない場合に、自動的に作成します。
- sanitizeTopics: トピックの名前を BigQuery でテーブルの名前として使用する前に自動的にサニタイズします。有効にしない場合は、トピック名がテーブル名として使用されます。
- autoUpdateSchemas: BigQuery テーブルを自動的にアップデートします。
- sanitizeFieldNames: フィールドの名前を BigQuery で列の名前として使用する前に自動的にサニタイズします。Kafka フィールドの名前が BigQuery では列名になることに注意してください。

Connect 用の Confluent Cloud API の使用に関する詳細とサンプルについては、「Confluent Cloud API for Connect」セクションを参照してください。

制限¶

以下の情報を確認してください。

コネクターの制限事項については、Google BigQuery Sink Connector の制限事項を参照してください。
1 つ以上の Single Message Transforms（SMT）を使用する場合は、「SMT の制限」を参照してください。
Confluent Cloud Schema Registry を使用する場合は、「スキーマレジストリ Enabled Environments」を参照してください。

クイックスタート¶

このクイックスタートを使用して、Confluent Cloud Google BigQuery Sink Connector の利用を開始することができます。このクイックスタートでは、コネクターを選択し、BigQuery データウェアハウスにイベントをストリームするようにコネクターを構成するための基本的な方法について説明します。

前提条件

リソースの作成を認可されているアクティブな GCP アカウント。
BigQuery プロジェクトが必要です。プロジェクトは、Google Cloud Console を使用して作成できます。
プロジェクトには、BigQuery データセットが必要です。
データセットを含む BigQuery プロジェクトにアクセスできるサービスアカウント。このサービスアカウントは、Google Cloud Console で作成できます。

サービスアカウントには、データセットを含む BigQuery プロジェクトにアクセスする権限が必要です。サービスアカウントの作成時に、キーを作成してダウンロードします。キーは、JSON ファイルとしてダウンロードする必要があります。これは以下の例のようなファイルです。

{
 "type": "service_account",
 "project_id": "confluent-842583",
 "private_key_id": "...omitted...",
 "private_key": "-----BEGIN PRIVATE ...omitted... =\n-----END PRIVATE KEY-----\n",
 "client_email": "confluent2@confluent-842583.iam.gserviceaccount.com",
 "client_id": "...omitted...",
 "auth_uri": "https://accounts.google.com/oauth2/auth",
 "token_uri": "https://oauth2.googleapis.com/token",
 "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/certs",
 "client_x509_cert_url": "https://www.googleapis.com/robot/metadata/confluent2%40confluent-842583.iam.gserviceaccount.com"
}

GCP の仕様に従って、サービスアカウントに BigQueryEditor 基本 IAM ロールまたは bigquery.dataEditor 事前定義 IAM ロールが付与されている必要があります。最小限のアクセス許可は以下のとおりです。

bigquery.datasets.get
bigquery.tables.create
bigquery.tables.get
bigquery.tables.getData
bigquery.tables.list
bigquery.tables.update
bigquery.tables.updateData

Kafka クラスターの認証情報。次のいずれかの方法で認証情報を指定できます。
- 既存のサービスアカウントのリソース ID を入力する。
- コネクター用の Confluent Cloud サービスアカウントを作成します。「サービスアカウント」のドキュメントで、必要な ACL エントリを確認してください。一部のコネクターには固有の ACL 要件があります。
- Confluent Cloud の API キーとシークレットを作成する。キーとシークレットを作成するには、confluent api-key create を使用するか、コネクターのセットアップ時に Cloud Console で直接 API キーとシークレットを自動生成します。
Confluent CLI がインストールされ、クラスター用に構成されていること。「Confluent CLI のインストール」を参照してください。
スキーマレジストリベースのフォーマット（Avro、JSON_SR（JSON スキーマ）、Protobuf など）を使用するには、Schema Registry を有効にしておく必要があります。詳細については、「スキーマレジストリ Enabled Environments」を参照してください。
Auto create tables （または autoCreateTables）を false （デフォルト）のままにする場合は、コネクターを使用する前に BigQuery テーブルを作成しておく必要があります。
Auto update schemas プロパティ（または autoUpdateSchemas）の設定によっては、BigQuery でスキーマを作成しておく必要があります。
- Auto update schemas を true に設定する場合: スキーマを作成する必要はありません。
- Auto update schemas を false に設定する場合（デフォルト） : BigQuery でスキーマを作成する必要があります（以下を参照）。このコネクターはテーブルの自動アップデートを行いません。

Confluent Cloud Console の使用¶

ステップ 1: Confluent Cloud クラスターを起動します。¶

インストール手順については、「Quick Start for Confluent Cloud」を参照してください。

ステップ 2: コネクターを追加します。¶

左のナビゲーションメニューの Data integration をクリックし、Connectors をクリックします。クラスター内に既にコネクターがある場合は、+ Add connector をクリックします。

ステップ 3: コネクターを選択します。¶

Click the Google BigQuery Sink connector card.

ステップ 4: コネクターの詳細情報を入力します。¶

注釈

すべての前提条件を満たしていることを確認してください。
アスタリスク（ * ）は必須項目であることを示しています。

Add Google BigQuery Sink Connector 画面で、以下を実行します。

既に Kafka トピックを用意している場合は、Topics リストから接続するトピックを選択します。

新しいトピックを作成するには、+Add new topic をクリックします。

注釈

Cloud Console に表示されない構成プロパティでは、デフォルト値が使用されます。すべてのプロパティの値と定義については、「構成プロパティ」を参照してください。

Input Kafka record value で Kafka 入力レコード値のフォーマット（Kafka トピックから送られるデータ）を AVRO、JSON_SR（JSON スキーマ）、または PROTOBUF から選択します。スキーマベースのメッセージフォーマット（Avro、JSON_SR（JSON スキーマ）、Protobuf など）を使用するには、有効なスキーマが Schema Registry に存在する必要があります。詳細については、「スキーマレジストリ Enabled Environments」を参照してください。

Show advanced configurations

Partitioning type: 使用するパーティション分割のタイプ。
- INGESTION_TIME: この型を使用するには、既存のテーブルが取り込み時間によってパーティション分割されている必要があります。コネクターにより、現在の実際の時刻のパーティションに書き込まれます。Auto create tables が有効である場合、コネクターでは、取り込み時間によってパーティション分割されたテーブルが作成されます。
- NONE: コネクターでは、既存のテーブルがセットアップされている方法のみ利用されます。Auto create tables が有効である場合、コネクターでは、パーティション分割されていないテーブルが作成されます。
- RECORD_TIME: この型を使用するには、既存のテーブルが取り込み時間によってパーティション分割されている必要があります。コネクターにより、Kafka レコードのタイムスタンプに関連付けられているパーティションに書き込まれます。Auto create tables が有効である場合、コネクターでは、取り込み時間によってパーティション分割されたテーブルが作成されます。
- TIMESTAMP_COLUMN: コネクターでは、既存のテーブルがセットアップされている方法のみ利用されます。Auto create tables が有効である場合、コネクターでは、Kafka レコード値のフィールドを使用してパーティション分割されたテーブルが作成されます。
Auto create tables: BigQuery テーブルを自動的に作成するかどうかを指定します。Avro、JSON_SR、Protobuf のメッセージフォーマットのみがサポートされています。
Auto update schemas: BigQuery スキーマを自動的にアップデートするかどうかを指定します。レコードスキーマの新規フィールドでは null を許容する必要があります。Avro、JSON_SR、Protobuf のメッセージフォーマットのみがサポートされています。
Sanitize topics: トピック名を BigQuery でテーブル名として使用する前に、自動的にサニタイズするかどうかを指定します。有効になっていない場合は、トピック名がテーブル名として使用されます。
Sanitize field names: フィールド名を BigQuery でフィールド名として使用する前に、自動的にサニタイズするかどうかを指定します。
Time partitioning type: partitioning.type が INGESTION_TIME、RECORD_TIME、または TIMESTAMP_COLUMN の場合に新規テーブルの作成で使用する時間パーティション分割のタイプ。
Time partitioning field name: BigQuery でパーティション分割に使用され、各テーブルのタイムスタンプパーティション分割を有効にするタイムスタンプを値に含むフィールドの名前。
Allow schema unionization: 有効になっている場合、スキーマのアップデートを実行すると、レコードスキーマと BigQuery テーブルの現在のスキーマが結合されます。
Transforms and Predicates については、Single Message Transforms（SMT）のドキュメントを参照してください。

すべてのプロパティの値と定義については、「構成プロパティ」を参照してください。

Continue をクリックします。

ステップ 5: BigQuery で結果を確認します。¶

Google Cloud Console で、BigQuery プロジェクトに移動します。
データベースに対してクエリを実行し、新しいレコードが追加されていることを確認します。

Connect 用の Confluent Cloud API の使用に関する詳細とサンプルについては、「Confluent Cloud API for Connect」セクションを参照してください。

ちなみに

コネクターを起動すると、デッドレターキューのトピックが自動的に生成されます。詳細については、「Confluent Cloud デッドレターキュー」を参照してください。

注釈

多数のタスクで複数のコネクターを使用する場合は、必ず『ストリーミング挿入』を参照してください。

参考

フルマネージド型の Confluent Cloud コネクターが Confluent Cloud ksqlDB でどのように動作するかを示す例については、「Cloud ETL のデモ」を参照してください。この例では、Confluent CLI を使用して Confluent Cloud のリソースを管理する方法についても説明しています。

Confluent CLI を使用する場合¶

以下の手順に従うと、Confluent CLI を使用してコネクターをセットアップし、実行できます。

注釈

すべての前提条件を満たしていることを確認してください。
コマンド例では Confluent CLI バージョン 2 を使用しています。詳細については、「Confluent CLI v2 への移行 <https://docs.confluent.io/confluent-cli/current/migrate.html#cli-migrate>`__」を参照してください。

ステップ 1: 使用可能なコネクターをリスト表示します。¶

以下のコマンドを入力して、使用可能なコネクターをリスト表示します。

confluent connect plugin list

ステップ 2: コネクターの必須の構成プロパティを表示します。¶

以下のコマンドを実行して、コネクターの必須プロパティを表示します。

confluent connect plugin describe <connector-catalog-name>

例:

confluent connect plugin describe BigQuerySink

出力例:

Following are the required configs:
connector.class
name
kafka.auth.mode
kafka.api.key
kafka.api.secret
keyfile
project
datasets
input.data.format
tasks.max
topics

ステップ 3: コネクターの構成ファイルを作成します。¶

コネクター構成プロパティを含む JSON ファイルを作成します。以下の例は、コネクターの必須プロパティを示しています。

{
    "name" : "confluent-bigquery-sink",
    "connector.class" : "BigQuerySink",
    "kafka.auth.mode": "KAFKA_API_KEY",
    "kafka.api.key" : "<my-kafka-api-key>",
    "kafka.api.secret" : "<my-kafka-api-secret>",
    "keyfile" : "omitted",
    "project" : "<my-BigQuery-project>",
    "datasets" : "<my-BigQuery-dataset>",
    "input.data.format" : "AVRO",
    "autoCreateTables" : "true"
    "sanitizeTopics" : "true"
    "autoUpdateSchemas" : "true"
    "sanitizeFieldNames" : "true"
    "tasks.max" : "1"
    "topics" : "pageviews",
}

以下のプロパティ定義に注意してください。

"name": 新しいコネクターの名前を設定します。
"connector.class": コネクターのプラグイン名を指定します。

"kafka.auth.mode": 使用するコネクターの認証モードを指定します。オプションは SERVICE_ACCOUNT または KAFKA_API_KEY （デフォルト）です。API キーとシークレットを使用するには、構成プロパティ kafka.api.key と kafka.api.secret を構成例（前述）のように指定します。サービスアカウントを使用するには、プロパティ kafka.service.account.id=<service-account-resource-ID> に リソース ID を指定します。使用できるサービスアカウントのリソース ID のリストを表示するには、次のコマンドを使用します。
```
confluent iam service-account list
```
例:
```
confluent iam service-account list

   Id     | Resource ID |       Name        |    Description
+---------+-------------+-------------------+-------------------
   123456 | sa-l1r23m   | sa-1              | Service account 1
   789101 | sa-l4d56p   | sa-2              | Service account 2
```
"topics": 特定のトピック名を指定するか、複数のトピック名をコンマ区切りにしたリストを指定します。
"keyfile": これには、ダウンロードした JSON ファイルの内容が入っています。ダウンロードした認証情報ファイルの内容を、フォーマットを変更して使用する方法について詳しくは、「キーファイル認証情報のフォーマットの変更」を参照してください。
"input.data.format": Kafka 入力レコード値のフォーマット（Kafka トピックから送られるデータ）を設定します。指定可能なエントリは、AVRO、JSON_SR、PROTOBUF、または JSON です。スキーマベースのメッセージフォーマット（たとえば、Avro、JSON_SR（JSON スキーマ）、および Protobuf）を使用するには、Confluent Cloud Schema Registry を構成しておく必要があります。

使用できる他のプロパティを次に示します。これらのプロパティを使用しない場合は、false がデフォルトとして使用されます。

"autoCreateTables": BigQuery テーブルが存在しない場合に自動的に作成するかどうかを指定します。
"sanitizeTopics": トピック名をテーブル名として使用する前に、自動的にサニタイズするかどうかを指定します。有効にしない場合は、トピック名がテーブル名として使用されます。sanitizeTopics を true に設定する場合でも、ソースのトピック名は BigQuery 命名規則に準拠する必要があります。
"autoUpdateSchemas": BigQuery テーブルを自動的にアップデートするかどうかを指定します。スキーマレジストリとともに使用します。
"sanitizeFieldNames": フィールドの名前を BigQuery で列の名前として使用する前に、自動的にサニタイズするかどうかを指定します。BigQuery の仕様では、フィールド名には英文字、数字、およびアンダースコアしか使用できません。サニタイザーは、無効な記号をアンダースコアに置き換えます。フィールド名の先頭が数字の場合は、サニタイザーがフィールド名の前にアンダースコアを追加します。

注意

a.b フィールドと a_b フィールドは、サニタイズされた後に同じ値になるので、キーの重複エラーが発生することがあります。使用しない場合は、フィールド名が列名として使用されます。
"partitioning.type": 使用するパーティション分割の型を選択します。
- "INGESTION_TIME": この型を使用するには、既存のテーブルが取り込み時間によってパーティション分割されている必要があります。コネクターにより、現在の実際の時刻のパーティションに書き込まれます。"autoCreateTables" が true である場合、コネクターでは、取り込み時間によってパーティション分割されたテーブルが作成されます。
- "NONE": コネクターでは、既存のテーブルがセットアップされている方法のみ利用されます。"autoCreateTables" が true である場合、コネクターでは、パーティション分割されていないテーブルが作成されます。
- "RECORD_TIME": この型を使用するには、既存のテーブルがレコードの時刻によってパーティション分割されている必要があります。コネクターにより、Kafka レコードのタイムスタンプに関連付けられているパーティションに書き込まれます。autoCreateTables が true である場合、コネクターでは、レコードの時刻によってパーティション分割されたテーブルが作成されます。
- "TIMESTAMP_COLUMN": コネクターでは、既存のテーブルがセットアップされている方法のみ利用されます。"autoCreateTables" が true である場合、コネクターでは、Kafka レコード値のフィールドを使用してパーティション分割されたテーブルが作成されます。
"time.partitioning.type": INGESTION_TIME、RECORD_TIME、または TIMESTAMP_COLUMN を使用する場合は、時間パーティション分割の期間を選択します。NONE を入力する場合、コネクターは既存の BigQuery テーブルパーティション分割に従います。"autoCreateTables" が true である場合、コネクターでは、特定のパーティション分割戦略を利用せずにテーブルが作成されます。
"timestamp.partition.field.name": このプロパティを使用するには、"partitioning.type" が TIMESTAMP_COLUMN で、"autoCreateTables" が true である必要があります。BigQuery でパーティション分割するためのタイムスタンプが含まれる値のフィールド名を入力します。これによって、各テーブルでタイムスタンプパーティション分割が有効になります。

Single Message Transforms: CLI を使用した SMT の追加の詳細については、Single Message Transforms（SMT）のドキュメントを参照してください。このコネクターでサポートされていない SMT のリストについては、「サポートされない変換」を参照してください。

すべてのプロパティの値と定義については、「構成プロパティ」を参照してください。

キーファイル認証情報のフォーマットの変更¶

ダウンロードした認証情報ファイルの内容は、コネクター構成で使用する前に、文字列フォーマットに変換する必要があります。

JSON ファイルの内容を文字列フォーマットに変換します。これは、オンラインのコンバーターツールを使用して実行できます。たとえば、JSON to String Online Converter などがあります。

Private Key セクションの \n のすべての出現箇所の前にエスケープ文字 \ を追加します。これで、各セクションの先頭が \\n になります（以下の強調表示された行を参照してください）。以下の例は、\\n の出現箇所がわかりすいようにフォーマットを整えています。認証情報キーの大部分は省略しています。

ちなみに

認証情報を文字列に変換し、さらに必要に応じてエスケープ文字を追加するスクリプトも用意されています。Stringify GCP Credentials を参照してください。

  {
      "name" : "confluent-bigquery-sink",
      "connector.class" : "GcsSink",
      "kafka.api.key" : "<my-kafka-api-keyk>",
      "kafka.api.secret" : "<my-kafka-api-secret>",
      "topics" : "pageviews",
      "keyfile" : "{\"type\":\"service_account\",\"project_id\":\"connect-
      1234567\",\"private_key_id\":\"omitted\",
      \"private_key\":\"-----BEGIN PRIVATE KEY-----
      \\nMIIEvAIBADANBgkqhkiG9w0BA
      \\n6MhBA9TIXB4dPiYYNOYwbfy0Lki8zGn7T6wovGS5\opzsIh
      \\nOAQ8oRolFp\rdwc2cC5wyZ2+E+bhwn
      \\nPdCTW+oZoodY\\nOGB18cCKn5mJRzpiYsb5eGv2fN\/J
      \\n...rest of key omitted...
      \\n-----END PRIVATE KEY-----\\n\",
      \"client_email\":\"pub-sub@connect-123456789.iam.gserviceaccount.com\",
      \"client_id\":\"123456789\",\"auth_uri\":\"https:\/\/accounts.google.com\/o\/oauth2\/
      auth\",\"token_uri\":\"https:\/\/oauth2.googleapis.com\/
      token\",\"auth_provider_x509_cert_url\":\"https:\/\/
      www.googleapis.com\/oauth2\/v1\/
      certs\",\"client_x509_cert_url\":\"https:\/\/www.googleapis.com\/
      robot\/v1\/metadata\/x509\/pub-sub%40connect-
      123456789.iam.gserviceaccount.com\"}",
      "project": "<my-BigQuery-project>",
      "datasets":"<my-BigQuery-dataset>",
      "data.format":"AVRO",
      "tasks.max" : "1"
  }

変換したすべての文字列の内容を、上記の例のように構成ファイルの "keyfile" 認証情報セクションに追加します。

ステップ 4: 構成ファイルを読み込み、コネクターを作成します。¶

以下のコマンドを入力して、構成を読み込み、コネクターを起動します。

confluent connect create --config <file-name>.json

例:

confluent connect create --config bigquery-sink-config.json

出力例:

Created connector confluent-bigquery-sink lcc-ix4dl

ステップ 5: コネクターのステータスを確認します。¶

以下のコマンドを入力して、コネクターのステータスを確認します。

confluent connect list

出力例:

ID          |       Name              | Status  | Type
+-----------+-------------------------+---------+------+
lcc-ix4dl   | confluent-bigquery-sink | RUNNING | sink

ステップ 6: BigQuery で結果を確認します。¶

Google Cloud Console で、BigQuery プロジェクトに移動します。
データベースに対してクエリを実行し、新しいレコードが追加されていることを確認します。

Connect 用の Confluent Cloud API の使用に関する詳細とサンプルについては、「Confluent Cloud API for Connect」セクションを参照してください。

ちなみに

コネクターを起動すると、デッドレターキューのトピックが自動的に生成されます。詳細については、「Confluent Cloud デッドレターキュー」を参照してください。

注釈

多数のタスクで複数のコネクターを使用する場合は、必ず『ストリーミング挿入』を参照してください。

構成プロパティ¶

このコネクターでは、以下のコネクター構成プロパティを使用します。

データの取得元とするトピック（Which topics do you want to get data from?）¶

topics

特定のトピック名を指定するか、複数のトピック名をコンマ区切りにしたリストを指定します。

型: list
重要度: 高

入力メッセージ（Input messages）¶

input.key.format

Sets the input Kafka record key format. Valid entries are AVRO, BYTES, JSON, JSON_SR, PROTOBUF, or STRING. Note that you need to have Confluent Cloud Schema Registry configured if using a schema-based message format like AVRO, JSON_SR, and PROTOBUF

型: string
Default: BYTES
Valid Values: AVRO, BYTES, JSON, JSON_SR, PROTOBUF, STRING
重要度: 高

input.data.format

Kafka 入力レコード値のフォーマットを設定します。指定可能なエントリは、AVRO、JSON_SR、PROTOBUF、JSON です。スキーマベースのメッセージフォーマット（AVRO、JSON_SR、PROTOBUF など）を使用する場合は、Confluent Cloud Schema Registry を構成しておく必要がある点に注意してください。

型: string
重要度: 高

データへの接続方法（How should we connect to your data?）¶

name

コネクターの名前を設定します。

型: string
指定可能な値: 最大 64 文字の文字列
重要度: 高

Kafka クラスターの認証情報（Kafka Cluster credentials）¶

kafka.auth.mode

Kafka の認証モード。KAFKA_API_KEY または SERVICE_ACCOUNT を指定できます。デフォルトは KAFKA_API_KEY モードです。

型: string
デフォルト: KAFKA_API_KEY
指定可能な値: KAFKA_API_KEY、SERVICE_ACCOUNT
重要度: 高

kafka.api.key

型: password
重要度: 高

kafka.service.account.id

Kafka クラスターとの通信用の API キーを生成するために使用されるサービスアカウント。

型: string
重要度: 高

kafka.api.secret

型: password
重要度: 高

GCP 認証情報（GCP credentials）¶

keyfile

BigQuery への書き込みアクセス許可を持つ GCP サービスアカウントの JSON ファイル。

型: password
重要度: 高

BigQuery の詳細（BigQuery details）¶

project

BigQuery が配置されている GCP プロジェクトの ID。

型: string
重要度: 高

datasets

Kafka のトピックの書き込み先データセットの名前。

型: string
重要度: 高

SQL/DDL サポート（SQL/DDL Support）¶

auto.create.tables

BigQuery テーブルを自動的に作成するかどうかを指定します。注: AVRO、JSON_SR、PROTOBUF のメッセージフォーマットのみをサポートします。

型: boolean
デフォルト: false
重要度: 高

auto.update.schemas

BigQuery スキーマを自動的にアップデートするかどうかを指定します。レコードスキーマの新規フィールドでは null を許容する必要があります。注: AVRO、JSON_SR、PROTOBUF のメッセージフォーマットのみをサポートします。

型: boolean
デフォルト: false
重要度: 高

sanitize.topics

BigQuery のテーブル名として使用する前にトピック名を自動的にサニタイズするかどうかを指定します。有効になっていない場合は、トピック名がテーブル名として使用されます。

型: boolean
デフォルト: true
重要度: 高

sanitize.field.names

BigQuery のフィールド名として使用する前にフィールド名を自動的にサニタイズするかどうかを指定します。BigQuery の仕様では、フィールド名には英文字、数字、およびアンダースコアしか使用できません。サニタイザーは、無効な記号をアンダースコアに置き換えます。フィールド名の先頭が数字の場合は、サニタイザーがフィールド名の前にアンダースコアを追加します。注意: a.b フィールドと a_b フィールドは、サニタイズされた後に同じ値になるので、キーの重複エラーが発生することがあります。

型: boolean
デフォルト: false
重要度: 高

partitioning.type

使用するパーティション分割のタイプ。

NONE: コネクターは既存のテーブルのセットアップ状態を使用します。自動テーブル作成が有効になっている場合、パーティション分割されていないテーブルが作成されます。

INGESTION_TIME: 既存のテーブルが取り込み時間でパーティション分割され、コネクターは現在の実際の時刻のパーティションに対して書き込みます。自動テーブル作成が有効になっている場合、取り込み時間でパーティション分割されたテーブルが作成されます。

RECORD_TIME: 既存のテーブルが取り込み時間でパーティション分割され、コネクターは各 Kafka レコードのタイムスタンプに対応するパーティションに対して書き込みます。自動テーブル作成が有効になっている場合、取り込み時間でパーティション分割されたテーブルが作成されます。RECORD_TIME の time.partitioning.type 値としてサポートされているのは DAY のみです。

TIMESTAMP_COLUMN: コネクターは既存のテーブルのセットアップ状態を使用します。自動テーブル作成が有効になっている場合、Kafka レコード値のフィールドでパーティション分割されたテーブルが作成されます。

型: string
デフォルト: INGESTION_TIME
重要度: 高

time.partitioning.type

partitioning.type が INGESTION_TIME、RECORD_TIME、または TIMESTAMP_COLUMN の場合に新規テーブルの作成で使用する時間パーティション分割のタイプ。既存のテーブルは、このパーティション分割のタイプを使用するように変更されません。

型: string
デフォルト: DAY
重要度: 低

timestamp.partition.field.name

BigQuery でパーティション分割に使用され、各テーブルのタイムスタンプパーティション分割を有効にするタイムスタンプを値に含むフィールドの名前。partitioning.type が TIMESTAMP_COLUMN でない場合や auto.create.tables が false の場合、この構成は無視されます。

型: string
重要度: 低

allow.schema.unionization

有効になっている場合、スキーマのアップデートを実行すると、レコードスキーマと BigQuery テーブルの現在のスキーマが結合されます。この構成は、テーブルのスキーマに既に存在する列に対応するフィールドの一部が欠けているスキーマが、一部の Kafka レコードに含まれている場合などに有効です。ただし、関連性のないレコードがコネクターによって消費されるトピックに偶然に生成されることもあり、リスクを伴います。その場合、コネクターは無効なデータに関してエラーを発生させるのではなく、それらの関連性のないレコードのスキーマの全フィールドを BigQuery テーブルのスキーマに追加してしまいます。

型: boolean
デフォルト: false
重要度: 低

intermediate.table.suffix

A suffix that will be appended to the names of destination tables to create the names for the corresponding intermediate tables. Multiple intermediate tables may be created for a single destination table, but their names will always start with the name of the destination table, followed by this suffix, and possibly followed by an additional suffix.

型: string
Default: tmp
重要度: 低

merge.interval.ms

How often (in milliseconds) to perform a merge flush, if upsert/delete is enabled. Can be set to -1 to disable periodic flushing.

Type: long
Default: 60000 (1 minute)
重要度: 低

merge.records.threshold

How many records to write to an intermediate table before performing a merge flush, if upsert/delete is enabled. Can be set to -1 to disable record count-based flushing.

Type: long
Default: -1
重要度: 低

all.bq.fields.nullable

If true, no fields in any produced BigQuery schema are REQUIRED. All non-nullable Avro fields are translated as NULLABLE (or REPEATED, if arrays).

型: boolean
デフォルト: false
重要度: 低

convert.double.special.values

Designates whether +Infinity is converted to Double.MAX_VALUE and whether -Infinity and NaN are converted to Double.MIN_VALUE to ensure successfull delivery to BigQuery.

型: boolean
デフォルト: false
重要度: 低

このコネクターのタスク数（Number of tasks for this connector）¶

tasks.max

型: int
指定可能な値: [1、…]
重要度: 高

次のステップ¶

参考

フルマネージド型の Confluent Cloud コネクターが Confluent Cloud ksqlDB でどのように動作するかを示す例については、「Cloud ETL のデモ」を参照してください。この例では、Confluent CLI を使用して Confluent Cloud のリソースを管理する方法についても説明しています。