データソースの作成と管理
プレビュー
Lakewatchは プライベート プレビュー段階です。アクセスをリクエストするには、Databricksアカウントチームにお問い合わせください。
このページでは、データソースのコンポーネントについて説明し、UIでデータソースを作成および管理する方法について説明します。データソースは、未加工のセキュリティデータを取り込み、セキュリティ分析の準備ができたスキーマ化された管理対象Unity Catalogテーブルに書き込むように構成されたパイプラインです。データソースは、 取り込み方法 と1つ以上の パーサー を組み合わせたものです。
取り込み方法
取り込みメソッドは、そのデータが存在する場所に基づいて、Lakewatchデータソースが生のセキュリティデータをどのように取り込むかを定義します。各メソッドには独自の作成フローがありますが、それらはすべて、パーサーが正規化する生のレイヤーに配置されます。
Lakewatchは、次の3つの取り込み方法を提供しています。
- クラウドストレージ: Unity Catalogボリュームまたは外部ロケーションを通じて、サポートされているオブジェクトストア（Amazon S3、Azure Data Lake Storage、またはGoogle Cloud Storage）からファイルを取り込みます。Lakewatchは、Auto Loaderを使ってソースを読み取り、新しいファイルが到着するたびに取り込みます。
- 既存のテーブル: ワークスペースに既に存在するUnity Catalog Deltaテーブルまたはビューを取り込みます。Lakewatchはソースを直接読み取り、データをコピーする代わりに接続されたパーサーを実行します。
- APIコネクタ: Unity Catalog接続によって管理されるマネージドコネクタを通じて、SaaSアプリケーションからセキュリティデータを取り込みます。すべてのAPIコネクタは、事前構築済みのパーサーとペアになっています。
パーサー
パーサーは、取り込まれたデータをスキーマ化して解析済みテーブルに格納します。各パーサーは、ログソースの出力列を記述し、Lakewatchで管理されたlw_id、lw_meta、およびlw_observables列を持つ解析済みテーブルを書き込みます。
データソースの作成フロー中に1つ以上のパーサーを選択してください。ソースに一致する組み込みパーサーを選択するか、組み込みパーサーをカスタマイズするか、パーサーをゼロから新規作成できます。
データソースがランすると、受信する各イベントは宣言された順序で添付パーサーと照合され、最初に一致するパーサーに格納されます。イベントは、必要なフィールドが存在し、型付きフィールドが宣言された型に変換され、すべてのバリデーターが合格したときに一致します。マッチングルールと完全なパーサー形式については、「パーサーのリファレンス」をご覧ください。
データソースの作成中に解析済み出力をプレビューすると、lw_meta.datasource_name は null として表示されます。データソースは作成するまで名前が付けられないため、Lakewatch はデータソースが作成されてランが行われた後にのみ datasource_name を入力します。
新しいデータソースを作成
データソース に移動し、 データソースを追加 をクリックします。「どのようなデータをオンボードしますか？」というピッカーが表示されます。SaaSソース用の組み込みコネクタカードを選択するか、 カスタムデータソース を選択して ソースタイプ を選択します。取り込み方法は次のとおりです。
- クラウドストレージ: Amazon S3、Azure Data Lake Storage、または Google Cloud Storage 内のファイル。
- 既存のテーブル：ワークスペースにすでに存在するUnity Catalog Deltaテーブルまたはビュー。
- APIコネクター：マネージドコネクターを介したSaaSアプリケーション。
既存のデータソースの管理
データソースを管理するには、 データソース からそれを開きます。詳細ページには3つのtabがあります。
- 概要 ：データソースの説明、最近のラン、接続、取り込み統計、添付されたパーサー、および編集可能な設定（処理スケジュール、実行者ID、コンピュート、および注釈）。設定を編集するには、それを選択し、値を調整して、 完了 をクリックします。パーサーを追加または変更するには、 パーサー セクションから行います。
- システムエラー ：このデータソースに対して発生したシステムエラー。それぞれ、タイトル、状態、重大度、割り当て先、イベント数、作成時間がリストされます。タイトル、説明、コメントで検索し、状態によってフィルタリングします。エラーのタイトルを選択して、詳細ページを開きます。
- 権限 : データソースに付与されている Unity Catalog の権限。 付与 と 取り消し を使用してアクセスを管理します。
オーバーフローメニュー（ ⋮ ）から、データソースを YAML として編集および削除できます。削除は、実行中のデータソースを停止する唯一の方法です。データソースは永続的に削除されますが、すでに書き込まれたテーブルは削除されません。
データソース設定を編集
[概要] tabでは、以下の設定を編集できます。
-
処理スケジュール： データソースの取り込みジョブが実行される頻度。新しいデータソースは、default 10 分ごとに実行されます。
- [単位] ごとに実行: 指定した間隔で実行します。
- [Time]に正確に： 正確なスケジュールに従ってランします。ビジュアルピッカーで作成するか、 [Show cron syntax] を選択して Quartz cron expression を入力します。無効な式は [Valid Quartz cron expression]を入力する と表示され、保存が防止されます。
- 連続: 新規データの到着時にループ内で約30分のランを取り込み、すぐに新しいランを再Triggerします。
- APIコネクター： 適用されません。APIコネクターのデータソースは、変更できない管理されたスケジュールでランします。
-
コンピュート： データソースの取り込みがコンピュート上のどのようにグループ化されるか。 ジョブのグループ化 の下：
- 自動 （default）：コンピュートコストを最適化するために、同じデータを処理する他のジョブとインジェストが組み合わされることがあります。
- 専用： 取り込みは専用リソースで実行されます。
- ジョブグループ： 取り込みは、入力した名前付きグループ内の他のジョブと一緒に実行されます。グループを変更するとチェックポイントがリセットされるため、処理は現在の時刻から再開されます。
-
注釈: データソースにタグとして適用されるキーと値のペア。
実行者IDを設定する
すべてのデータソースには 実行者ID があります。これは、Lakewatchがソースの読み取り、設定された認証情報の使用、およびRawテーブルと解析済みテーブルの書き込みに使用するユーザーまたはService Principalです。このIDは作成時に設定され、作成後に詳細ページから編集できます。
- default: データソース作成時にIDを選択しない場合、実行者IDはdefaultで自身になります。
- Service Principalを選択する： Service Principalとして実行するには、そのService Principalに対する Service Principalユーザー ロールを持っている必要があります。Service Principalの詳細ページには直接割り当てられたロールのみが表示されますが、グループメンバーシップを通じて付与されたロールはアクティブです。「Service Principalの管理」を参照してください。
- 再割り当て： データソースを編集する際に、実行者IDを変更できます。Lakewatchは、変更を保存する際に新しいIDとしてソースと認証情報のアクセス権を再検証します。
LakewatchはデータソースをこのIDとして検証および実行するため、実行者IDはデータソースに必要なすべての許可を保持する必要があります。
- ソースの読み取り： 必要なアクセス権は、取り込み方法によって異なります。たとえば、実行 ID には外部ロケーションに対する
READ FILESと、クラウドストレージ上のボリュームに対するREAD VOLUMEが必要です。必要な特定のアクセス権については、「取り込み方法」のページを参照してください。 - 構成済み資格情報を使用： ランアイデンティティには、Unity Catalogサービス資格情報に対する
ACCESS権限、または設定されている場合はAWS Secret Scopeへの読み取りアクセス権が必要です。 - 出力テーブルを書き込む: 実行者IDには、Lakewatchがrawテーブルとparsedテーブルを作成する各スキーマに対して
USE CATALOG、USE SCHEMA、CREATE TABLEが必要です。
Lakewatchは、実行者IDに対して宛先スキーマやテーブルへのアクセス権を自動的に付与しません。このIDをデータソースにアタッチする前に、このアクセス権を付与してください。
データソースのパーサーの変更
パーサーを変更する方法は、取り込み方法によって異なります。
- APIコネクターのデータソース は、作成後にパーサーを変更することはできません。異なるパーサーを使用するには、データソースを再作成してください。パーサーを変更すると、マネージドインジェストパイプラインが再構築され、データソースのテーブルが再作成されるため、これらのデータソースではパーサーの編集は無効になっています。
- クラウドストレージと既存テーブルのデータソース では、インラインでパーサーを変更できます。データソースを開き、変更を加えて、［ 保存 ］をクリックします。
クラウドストレージおよび既存テーブルのデータソースの場合：
- パーサーの追加： 別の組み込みパーサーまたは作成済みパーサーを添付します。受信イベントは宣言順に添付パーサーと照合されるため、新しく追加されたパーサーは、以前のパーサーと一致しないイベントに対して有効になります。新しいパーサーは最近の時点から開始され、そこから生データが再処理されます。既に添付されているパーサーはそのまま維持され、再処理は行われません。「パーサーの添付」を参照してください。
- パーサーの削除: 不要になったパーサーを切り離します。新しいイベントはそのパーサーの解析済みテーブルに書き込まれなくなり、以前に書き込まれた解析済みテーブルは削除されません。データが不要になった場合は、Unity Catalogで個別に削除してください。パーサーを削除すると、受信イベントのルーティング方法が変更されるため、残りのパーサーが最近の生データを再処理し、解析済みテーブルに重複する行が生成される可能性があります。
- パーサーの並べ替え： パーサーは宣言順に一致するため、並べ替えると追加や削除と同じようにルーティングが変更されます。データソースは最近の生データを再処理します。これにより、影響を受ける解析済みテーブルに重複する行が生成される可能性があります。
- パーサーのバージョンを変更する： データソースは特定のパーサーバージョンをピン留めするため、パーサーへの後続の編集の影響を受けません。新しいバージョンを選択するには、データソースの編集時にそのバージョンを選択します。バージョンの変更によって既存のデータが再処理されることはありません。新しいバージョンは、変更を保存した後に取り込まれたイベントに適用されます。
- 解析済み宛先の変更: パーサーが書き込むテーブルを変更できます。既存のテーブルと衝突しない宛先名を選択してください。古いテーブルにすでに書き込まれているデータは移動されません。
データソースエラーのトラブルシューティング
データソースの概要ページには、各データソースの最近の ラン履歴 、 エラー の数、 イベント統計 （過去7日間と過去24日間に処理されたレコード）、および 7日間のトレンド がまとめられています。基になるランの詳細を表示するには、データソースを開き、 ジョブの表示 をクリックして Databricks ジョブランにアクセスします。そこで、ラン履歴、ランごとのステータス、および Log を検査できます。
データソースのランが失敗すると、Lakewatchは障害をシステムイベントとして記録し、システムエラーに関連付けます。これにより、影響を受けたデータソースが識別され、エラーメッセージが含まれます。システムエラーと [ジョブの表示] を組み合わせて使用すると、どのフェーズが失敗したか（例：パイプラインエラー）を確認できます。データソース関連のTriggerの全リストについては、「システムイベントをTriggerするものは何か？」を参照してください。
データソースのラン者IDがソースへの読み取りアクセス権を失うと、ランは失敗し、データソースの エラー 数は増加します。
回復するには：
- ソースへの実行者IDのアクセス権を復元します。同じランとしてのIDを保持する場合、構成の変更は不要です。次にスケジュールされたランで、復元されたアクセス権が使用されます。
- 代わりにデータソースを別の実行者IDに再割り当てするか、別の設定を変更する場合は、データソースをインラインで編集し、 保存 をクリックします。
- ジョブの表示 またはシステムエラーでリカバリを確認してください。成功したランが再開されると、エラーはクリアされます。