ユーザーが見ることができる行を制限する
行フィルタは、ユーザーまたはグループがテーブルをクエリしたときに見ることができる行を制限します。テーブルを複製することなく。
目的
行フィルタは、特定のユーザーまたはグループがテーブルのどの行を見ることができるかを決定します。テーブルは1つのままです:同じ名前、同じ列、データの1つのコピーです。そのテーブルをクエリする2人は異なる結果を得ることがあります。それぞれが独自のフィルタを持っているからです。
「マリーはcountry = 'France'の行だけを見ることができる」というフィルタは、マリーがそのテーブルをクエリしたときに、フランスの行が返ってきて、それ以外は単に存在しません。彼女はエラーや警告、または行が隠されたことを知らせる通知を受け取りません:テーブルは彼女にとって小さなテーブルのように見えます。彼女が実行するカウント、集計、およびジョインは、彼女が見ることができる行のみに基づいて計算されます。他の人のビューは変わりません:そのテーブルにフィルタがない同僚は、依然としてすべてを見ることができます。
1つのフィルタは1つのテーブルをカバーし、それを割り当てられたユーザーとグループに適用されます。それらはLakehouse Managerの行フィルタセクションにあり、プロジェクト内のすべてのフィルタをリストします。
行フィルタは、Trinoクエリパスで強制されます。これはAnalytics Managerのクエリとダッシュボード、およびTrino消費者が使用します。同じテーブルを別の方法で読む人はフィルタされず、すべての行を見ることができます:PySparkまたはPyIcebergを使用するノートブック、または直接カタログとオブジェクトストレージへのアクセスです。
行フィルタは、SQLを通じてデータが消費される方法を制御するものであり、基盤となるストレージへのアクセスを制限する代替手段ではありません。そのテーブルへの直接的なストレージ資格情報を保持してはならないのは、アクセスを本当に制限する必要がある人です。テーブルをフィルタリングする前に、ノートブックやETLを実行するチームに伝えてください。誰もが、自分のパスに存在しない保護を想定しないようにしてください。
指示
行フィルタの作成
Lakehouse Manager の Row filters セクションに移動し、+ New filter をクリックします。モーダルには2つのステップがあります:フィルタ自体、そしてそのフィルタが適用される人々です。
ステップ1では、以下の3つの情報を入力します:
- フィルタ名:リストを意図に沿って読みやすくするための名前
- 対象テーブル:データセットからテーブルを選択
- フィルタ条件:この条件に一致しない行は、割り当てられたユーザーとグループには表示されません
条件を記述する方法は2つあります:ビルダーモード(デフォルト)とSQLモードです。
ビルダーモードで条件を構築
ビルダーモードはシンプルなモードで、特定の要件を満たすために必要な場合を除き、このモードを使用します。ドロップダウンから列を選択(そのタイプは名前の横に表示されます)、演算子を選択し、値を入力します。生成されたSQLは、値が入力されるとすぐに条件の下に表示され、実際に保存する条件を常に確認できます。
2行目の条件を追加するには、+ Add condition をクリックします。2つの条件からは、それらを結合する方法を選択できます:Match ALL conditions (AND) または Match ANY condition (OR)。この選択はフィルタ内のすべての条件に適用されるため、ビルダーモードでは1つのANDグループまたは1つのORグループを提供し、2つの混合は提供しません。両方の条件が必要な場合や、その他のネストが必要な場合は、SQLモードで行います。
使用可能な演算子は、列のタイプによって異なります:
空の値には独自の演算子があります。空の行を空の値と比較して見つけることはできず、プラットフォームは静かに何も一致しないフィルタを保存するのではなく、その旨を通知します。Is empty と is not empty はテーブルを正確に分割します:その行数は常に合計に等しくなります。
値は列に対して書き込む際にチェックされます。 日付列を 01/02/2024 と比較すると、その列が必要とする形式がすぐに通知されます。フィルタを保存してから、制限された人が実行するすべてのクエリを壊すのではなく、日付は 2024-01-01 を、タイムスタンプは 2024-01-01 10:30:00 を、時刻は 09:30:00 を望みます。タイムゾーンを持つ値は、静かにシフトされるのではなく拒否されます:列が実際に保持しているローカルの壁時計の値を送信します。
条件には以下の制限があります:
SQLモードで条件を記述
ビルダーで表現できない条件については、Switch to SQL mode をクリックし、SQL式として条件を直接記述します。例えば country = 'France' AND lower(dept) = 'sales' です。ビルダーで構築したものはすべて引き継がれるため、通常の流れはビルダーで開始し、その限界に達したときに切り替えることです。
これは単純な条件です:WHERE はありません、セミコロンはありません、ステートメントはありません。保存する前にチェックされ、他のテーブルを参照する、サブクエリを使用する、コメントやステートメント区切りを含む、または許可されたリスト外の関数を呼び出す場合は拒否されます。許可された関数は、行ごとの安価なものです:テキスト処理、coalesce、cast、日付の切り詰めなどです。集計、正規表現、JSON関数は利用できません。行フィルタはそのテーブルに対するすべてのクエリの各行で実行され、安価でなければなりません。
列名はSQLと同じように動作します:クォートされていない名前は大文字と小文字を区別せず、名前をクォートして実際に重要な大文字と小文字を持つ列にアクセスします。
SQLモードからビルダーモードに戻ると、SQLが破棄されます。 ビルダーはSQLが表現できるすべての条件を表現できないため、空の条件から開始するのではなく、あなたの条件の近似値から開始します。プラットフォームはそれが起こる前に警告します。
フィルタを割り当て、その影響を確認
Next をクリックしてステップ2に進みます。フィルタの概要が開きます:名前、データセット、テーブル、そして条件が、保存されるときと同じように表示されます。
その下の Impact は、そのテーブルに対してその条件が現在どのような影響を与えるかを報告します。例えば "このフィルタで227,712行の528,363行が表示され、300,651行が非表示になります" です。これはカウントのみで、行データではありません。そのため、内容を読むべきではないテーブルを見ても安全です。誰かに割り当てる前に読んでください:これは、何も保持しない、またはすべて保持する条件を最も安価にキャッチする方法です。
次に、principals(このフィルタが適用されるユーザーとグループ)を選択します。フィルタはそれぞれ複数指定できます。グループメンバーシップはフィルタが公開されるたびに解決され、フィルタを書くときではなく、来月制限グループに追加された人は、フィルタを変更する必要なく、その時点からフィルタリングされます。
Save and activate で完了するか、Save as inactive でフィルタを保存し、必要に応じて有効にします。
複数のフィルタが結合する方法
同じテーブルに対して同じ人に複数のフィルタが適用される場合、すべてのフィルタが同時に適用され、行が表示されるにはすべてのフィルタを満たす必要があります。 フィルタは誰かが見るものを広げません:2番目のフィルタを追加することは、常に行を取り除くだけです。
これは最も一般的な驚きの原因です。2つのフィルタがそれぞれ合理的なものに見える "EMEAのみ" と "北米のみ" は、空集合に交差し、その人は空のテーブルを見ます。同じ条件に2回ターゲットされることは無害です:直接指定されたものと、あなたが所属するグループを通じて指定されたもので、同じ条件が2回適用されると、同じ行が非表示になります。
日常的なフィルタの管理
Row filters リストはプロジェクト全体をカバーし、各フィルタについて、アクティブ/非アクティブのトグル、名前、principals、データセット、テーブル、条件を表示します。編集、複製、削除 アクションがあります。
- 非アクティブ化 トグルでフィルタを非アクティブ化すると、制限が適用されなくなり、フィルタはリストに残り、再びアクティブ化できるようになります。
- 編集 フィルタは、その条件またはprincipalsを変更します。
- フィルタは1つのテーブルをカバーします。 同じ条件を別のテーブルに適用するには、フィルタを複製し、コピーの対象テーブルを変更します。
行フィルタはプロジェクトの設定の一部であるため、設定エクスポートとともに移動し、保護するデータセットとともに別のプロジェクトにインポートできます。
権限
2つのことは別々に制限され、互いに含意しません:フィルタの管理はポリシーについて何かを示し、影響カウントはデータについて何かを示します。
知っておくべきこと
- 保存は即時ではありません。 フィルタはクエリエンジンに公開され、その独自のサイクルでフィルタを取得するため、新しい、変更された、非アクティブ化された、または削除されたフィルタは、クエリがそれを反映する前に数秒かかります。フィルタを保存し、制限された人としてすぐにクエリを実行すると、未フィルタリングの行がまだ表示される場合があります:フィルタが機能しなかったと結論付ける前に、再試行してください。
- 公開できないフィルタは誰も制限しません。 フィルタが解決できなくなったグループをターゲットにしている場合、プラットフォームはその制限を公開できず、ターゲットとなった人はすべての行を表示します。フィルタはまだリストに表示され、アクティブであるように読み取られます。制限が本当に重要な場合は、リストを読むのではなく、制限された人の1人としてクエリを実行して確認してください。
- フィルタを保存した後に削除された列はカバーされません。 保存時に、条件が名前を付けた列は物理的に存在するテーブルと照合されるため、カタログが知っているがテーブルが知らない列は拒否され、テーブルの再同期が修正方法です。後で削除された列は独自に再チェックされません:フィルタを開くとその影響が再計算され、問題が表面化します。
トラブルシューティング
さらに詳しく
当社のソリューションのトレーニングや技術的なサポートが必要な場合は、営業担当者にお問い合わせください。または、Professional Services ページをご覧になり、専門家によるプロジェクト分析と見積もりをリクエストしてください。
質問をする、フィードバックを送る、または Data Platform を構築するチームと直接交流するには、専用の Discord チャネル をご利用ください。
OVHcloud サービスについてサポートが必要な場合は、Help Centre でリクエストを作成してください。
ユーザーコミュニティ に参加してください。

