Simple Log Service (SLS) は、処理プラグイン、取り込みプロセッサ、データ変換、コンシューマープロセッサという 4 つのデータ処理方法を提供します。このトピックでは、これらの方法の特徴と適用シナリオを比較し、最適な方法を選択するのに役立つ情報を提供します。
背景情報
処理プラグイン構成：SLS のデータコレクターは、さまざまな処理構成を提供します。これらの構成は、処理プラグインと、構造化プロセス言語 (SPL) 文を使用するクライアントでのデータ処理をサポートします。
取り込みプロセッサ：取り込みプロセッサは Logstore に関連付けることができます。デフォルトでは、Logstore に書き込まれたデータは、サーバーサイドで取り込みプロセッサによって処理されます。
データ変換：データはまずソース Logstore に書き込まれ、次に変換ルールに基づいて処理されます。処理されたデータは宛先 Logstore に書き込まれます。
コンシューマープロセッサ：コンシューマープロセッサは、SPL を使用して Logstore から消費されるデータをリアルタイムで処理します。コンシューマープロセッサは、SDK、Flink、DataWorks などのサードパーティサービスとの統合をサポートします。
比較
処理プラグイン、取り込みプロセッサ、データ変換、コンシューマープロセッサは、ストレージ前 (収集時)、ストレージ中 (書き込み時)、ストレージ後 (書き込み後) を含む、データライフサイクル全体をカバーします。これらの方法には、すべてがデータを処理し、SPL をサポートするなど、類似点があります。しかし、適用シナリオと機能において違いがあります。
比較項目 | 処理プラグイン | 取り込みプロセッサ | データ変換 | コンシューマープロセッサ |
データ処理ステージ | ストレージ前 (データ収集時)。 | ストレージ中。 | ストレージ後。 | ストレージ後。 |
複数の Logstore への書き込み | 単一の収集構成ではサポートされていません。処理プラグインを使用して複数の収集構成を利用することは可能です。 | サポートされていません。 | サポートされています。 | サポートされていません。 |
SPL | サポートされています。 | サポートされています。 | サポートされています。 | サポートされています。 |
サポートされる SPL 命令 | 1行のデータを入力とし、0行または1行のデータを出力する、単一行データ処理命令をサポートします。 | 1行のデータを入力とし、0行または1行のデータを出力する、単一行データ処理命令をサポートします。 | 完全な SPL 命令をサポートします。 | 完全な SPL 命令をサポートします。 |
機密データのディスクへの書き込み防止 | サポートされています。 | サポートされています。 | サポートされていません。データはソース Logstore を通過します。 | サポートされていません。データはソース Logstore を通過します。 |
リソース使用量 | 一部のクライアントリソースを消費します。 | サーバーサイドのリソースは自動的にスケーリングされます。このプロセスはユーザーに対して透過的です。 | サーバーサイドのリソースは自動的にスケーリングされます。このプロセスはユーザーに対して透過的です。 | サーバーサイドのリソースは自動的にスケーリングされます。このプロセスはユーザーに対して透過的です。 |
パフォーマンスへの影響 | 収集パフォーマンスは、プラグインの数と構成の複雑さによってわずかに影響を受けます。データ書き込みパフォーマンスは影響を受けません。 | 書き込みパフォーマンスは、データの複雑さと SPL 文によってわずかに影響を受けます。単一リクエストのレイテンシーは、リクエストされたデータパケットのサイズと SPL 文の複雑さに応じて、数ミリ秒から数十ミリ秒増加する可能性があります。 | ソース Logstore の書き込みパフォーマンスは影響を受けません。 | ソース Logstore の書き込みパフォーマンスは影響を受けません。 |
シナリオカバー率 | 高 | 標準 | 多くあります。 | 多 |
コスト | SLS のデータ処理料金は課金されませんが、一部のクライアントリソースを消費します。 | データ処理料金が課金されます。データフィルタリングのシナリオでは、この料金は通常、データトラフィックとストレージコストの削減による節約額よりも低くなります。 | ソース Logstore の料金とデータ処理料金が課金されます。ソース Logstore のデータ保持期間を 1 日に設定し、インデックスを無効にすることで、コストを削減できます。 | ソース Logstore の料金とデータ処理料金が課金されます。ソース Logstore のデータ保持期間を 1 日に設定し、インデックスを無効にすることで、コストを削減できます。 |
フォールトトレランス | 処理が失敗した場合に元のフィールドを保持するようにプラグインを構成できます。 | 処理が失敗した場合に生データを保持するように構成できます。 | ソースデータはすでに保存されているため、変換ルールが失敗した場合でもデータを再処理できます。また、複数のデータ変換ジョブを作成して、データを個別に処理することも可能です。 | ソースデータはすでに保存されているため、Flink、DataWorks、または SDK を介して SPL 消費ルールを統合するコンシューマーグループは、エラー発生時に自動的にリトライします。 |
以下に、典型的なシナリオにおける取り込みプロセッサ、Logtail 処理構成、データ変換の機能を比較します：
シナリオ | Logtail 処理構成 | 取り込みプロセッサ | データ変換 | コンシューマープロセッサ |
複雑な計算ロジックを伴わない単一行データ処理などの単純なデータ処理。 | 推奨 | 推奨 | 推奨 | 推奨 |
複雑な計算ロジック、複数の条件、ウィンドウ集約、またはディメンションテーブルエンリッチメントを必要とするタスクなどの複雑なデータ処理。 | 一般的 | 一般的 | 推奨 | 推奨 |
Logtail で利用可能な計算リソースが限られている場合など、クライアントリソースが限られている状況。 | 一般的 | 推奨 | 推奨 | 推奨 |
クライアントで Logtail 構成や SDK の書き込みロジックを変更する権限がないなど、クライアントサイドのコントロールが制限されている状況。 | 非推奨 | 推奨 | 推奨 | 推奨 |
Logstore やデータ変換の構成を変更する権限がないなど、サーバーサイドのコントロールが制限されている状況。 | 推奨 | 非推奨 | 非推奨 | 非推奨 |
生データをできるだけ早く収集する必要がある場合など、データの書き込みレイテンシーとパフォーマンスに敏感な状況。 | 一般的 | 一般的 | 推奨 | 推奨 |
データマスキング、かつ機密データをディスクに書き込める状況。 | 推奨 | 推奨 | 推奨 | 推奨 |
データマスキング、かつ機密データをディスクに書き込めない状況。 | 推奨 | 推奨 | 非推奨 | 非推奨 |
静的フィールドや既存フィールドから抽出した値を新しいフィールドとして追加するなど、外部データソースに依存しないデータエンリッチメント。 | 一般的 | 推奨 | 推奨 | 推奨 |
ログフィールドに基づいて MySQL テーブルから追加のエンリッチメントデータをクエリするなど、外部データソースに依存するデータエンリッチメント。 | 非推奨 | 非推奨 | 推奨 | 推奨 |
異なる条件に基づいて異なる Logstore にデータを書き込むデータ分散。 | 一般的 | 非推奨 | 推奨 | 非推奨 |
コストを節約するために生データが不要なデータフィルタリング。 | 一般的 | 推奨 | 一般的 | 一般的 |