説明
列の可能性のある特徴値の集合がすべてわかっていて、その数が限られている場合は、categorical_column_with_vocabulary_list を使用できます。リスト内の各キーには、0から始まる自動増分IDが割り当てられます。
事前に可能性のある値のセットがわからない場合はどうすればよいでしょうか？問題ありません。代わりに categorical_column_with_hash_bucket を使用できます。特徴列の occupation に含まれる可能性のある値は、トレーニング中に遭遇するたびに整数IDにハッシュ化されます。
参考: https://www.tensorflow.org/tutorials/wide

機密テーブルへのデータ アクセスを HR グループのみに制限しながら、すべての従業員が GDPR タグ付きのテーブルを検索できるようにするには、次の手順に従います。
データカタログタグテンプレート:
Data Catalog を使用して、「gdpr」という名前のタグテンプレートを作成し、「機密データあり」というブール値フィールドを設定します。すべての従業員がタグを確認できるように、公開設定を「公開」にします。
役割と権限:
datacatalog.tagTemplateViewer ロールを全従業員グループに割り当てます。このロールにより、ユーザーはタグを表示し、「機密データあり」フィールドに基づいてテーブルを検索できるようになります。
機密データを含むテーブルに対して、HRグループにbigquery.dataViewerロールを割り当てます。これにより、これらのテーブル内の実際のデータにアクセスできるのはHRのみになります。
実装手順:
GDPR タグ テンプレートを作成します。
必要なフィールドを使用して Data Catalog でタグ テンプレートを定義し、可視性をパブリックに設定します。
役割の割り当て:
タグを表示できるように、すべての従業員グループに datacatalog.tagTemplateViewer ロールを付与します。
機密データがあるとマークされたテーブルの HR グループに bigquery.dataViewer ロールを付与します。
参照：
データカタログドキュメント
BigQuery でのアクセス制御の管理
データカタログの IAM ロール

Cloud Bigtable に依存するパフォーマンス テストを実行する場合は、テストを計画して実行する際に必ず次の手順に従ってください。
本番インスタンスを使用してください。開発インスタンスでは、本番インスタンスが負荷をかけた状態でどのように動作するかを正確に把握することはできません。
少なくとも300GBのデータを使用してください。Cloud Bigtableは1TB以上のデータで最適なパフォーマンスを発揮します。ただし、3ノードクラスタでのパフォーマンステストでは、300GBのデータがあれば十分な結果が得られます。より大規模なクラスタでは、ノードごとに100GBのデータを使用してください。
テストの前に、数分間、高負荷の事前テストを実行してください。このステップにより、Cloud Bigtable は観測したアクセスパターンに基づいて、ノード間でデータのバランスを調整できます。テストは少なくとも10分間実行してください。このステップにより、Cloud Bigtable はデータをさらに最適化し、ディスクからの読み取りだけでなく、メモリからキャッシュされた読み取りも確実にテストできるようになります。
参考: https://cloud.google.com/bigtable/docs/performance

このオプションは、データ メッシュ アーキテクチャ向けに Dataplex を構成する最適な方法です。各データ エンジニアリング チームがデータ製品に対する完全な所有権と制御権を持つことができると同時に、組織全体でキュレーションされたデータを簡単に検出して共有できるようになるためです12。データ製品ごとに Dataplex 仮想レイクを作成することで、ドメインごとにデータ資産とリソースを分離し、異なるチーム間の競合や依存関係を回避できます3。ランディング データ、生データ、キュレーション済みデータ用に複数のゾーンを作成することで、データ キュレーション プロセスの各段階で異なるセキュリティおよびガバナンス ポリシーを適用し、承認されたユーザーのみがデータ資産にアクセスできるようにすることができます45。データ エンジニアリング チームに、データ製品に割り当てられた仮想レイクへのフル アクセスを提供することで、データ エンジニアリング チームがデータ製品を管理および監視し、タグ付け、品質、リネージなどの Dataplex 機能を活用できるようになります。
オプションAは、データメッシュの単一障害点とボトルネックとなり、異なるデータ製品に対するきめ細かなアクセス制御とガバナンスを実現できないため、適切ではありません2。オプションBも、データ資産とリソースを各データ製品の分離がされておらず、ゾーンレベルで権限が割り当てられているため、データエンジニアリングチームの異なる役割と責任が反映されない可能性があるため、適切ではありません34。オプションCはオプションAとBよりも優れていますが、ランディングデータ、生データ、キュレーションデータ用の複数のゾーンを作成しないため、データ製品のセキュリティと品質が損なわれる可能性があります5。参考：
1: BigQuery と Dataplex を使用して Google Cloud 上にデータメッシュを構築する | Google Cloud ブログ
2: データメッシュ - 始めるための7つの効果的なプラクティス - Confluent
3: ベスト プラクティス | Dataplex | Google Cloud
4: レイクのセキュリティ保護 | Dataplex | Google Cloud
5: ゾーン | Dataplex | Google Cloud
[6]: Dataplexによるデータメッシュの管理 - ROIトレーニング

説明
Cloud Dataproc クラスタを作成した後は、クラスタ上でジョブが実行されている場合でも、いつでもクラスタ内のワーカーノードの数を増減することでクラスタをスケールできます。Cloud Dataproc クラスタは通常、次のようにスケールされます。
1) 仕事を早く進めるために労働者の数を増やす
2) コスト削減のため労働者数を減らす
3) 利用可能な Hadoop 分散ファイルシステム (HDFS) ストレージを拡張するためにノード数を増やす 参照: https://cloud.google.com/dataproc/docs/concepts/scaling-clusters