データ ストリームへの接続

Qlik Open Lakehouse プロジェクトでは、次のストリーミング サービスがサポートされています。イベントデータは継続的に取り込まれ、ダウンストリームのデータ統合、分析、AI 向けにほぼリアルタイムの可用性を確保し、最新の運用アクティビティを反映する低遅延のパイプラインが実現されます。

Apache Kafka や Amazon Kinesis などのストリーミング サービスは、運用イベントが発生したときにそれをキャプチャするための、耐久性があり高スループットのパイプラインを提供します。バッチ取り込みに依存するファイル ベースのソースとは異なり、ストリーミング ソースはイベントの生成に合わせてデータを継続的に配信するため、ファイルの生成やスケジュールの実行を待つことなく、ほぼリアルタイムでの処理が可能となります。プロデューサーは、スキーマを保持し、パーティショニングをサポートする構造化または半構造化メッセージを公開します。同じレコードに対するすべての更新と削除には、同じパーティション キーを使用する必要があります。Kafka と Kinesis は、トピックまたはストリーム全体ではなく、単一のパーティションまたはシャード内でのみ順序を保証します。一貫したパーティション キーを使用することで、特定のレコードに対する変更が正しい順序で処理されることが保証されます。Qlik は、イベント データを継続的に取り込むためのストリーミング ソースとして、Amazon S3 もサポートしています。

ストリーミング取り込みとバッチ取り込み

ストリーミング データ ソースとバッチ データ ソースの違いは、次のとおりです。

• 両方のソースで、イベントは毎分効率的に取り込まれ、低レイテンシー処理とほぼリアルタイムでの分析をサポートします。

• ストリーミング以外のソースでは、まず既存データのフル ロードが行われ、その後変更が取り込まれます。ソースからフル ロード データをリロードすることもできます。

• ストリーミング ソースでは、初期ロードと後続のイベントとの間に明確な区別はありません。Qlik は保持を管理でき、パーティションもサポートします。

Qlik Open Lakehouse プロジェクトでは、ストリーミング ソースはストリーミング ランディング タスクおよびストリーミング変換タスクでのみ使用できます。

• ストリーミング データはストリーミング ランディング タスクを使用して取り込まれます。このタスクは、個別のファイルを処理するのではなく、イベントが到着するたびにそれを読み込み、データを Amazon S3 ランディングさせ、Avroファイルとして永続化します。このアプローチにより、スキーマの進化が維持され、構造体などの複雑なデータ型に対応できるとともに、継続的な取り込みモデルを維持しながら、最適化されたクエリ パフォーマンスによる効率的なストレージを実現します。

• ストリーミングソースからデータを取り込むと、Iceberg 形式で保存される各データセットに対してストリーミング変換タスクが自動的に追加されます。必要に応じて、ストリーミング変換タスクを使用することで、構造の標準化やイベント ペイロードの拡張、ダウンストリームの利用モデルに合わせたデータの整合を実行できます。

• ミラー データ タスクを使用すると、ストリーミング ソースからのデータセットをクラウド データウェアハウスにミラーリングでき、データを重複させることなく、ダウンストリームのシステムがストリーミング イベントを利用できるようになります。詳細については、「クラウド データ ウェアハウスへのデータのミラーリング」を参照してください。

制限事項

次の制限事項は、すべてのデータソースに適用されます。

• ファイルが異なる種類である場合 (複数のソースやバージョンに由来する場合などに発生し得ます)、単一のサンプルファイルを使用して作成された変換タスク (例: オンボーディング時に作成されたタスク) では、それらの差異が自動的に考慮されることはありません。

• たとえば、データをハッシュする必要があるなどの理由でランディング タスクでデータ型を変更する場合は、変換データ型が新しいデータ型と一致していることを確認してください。

サポートされているソース