Professional-Data-Engineer日本語問題集PDFでProfessional-Data-Engineer日本語リアル試験問題解答 [Q213-Q233]

Professional-Data-Engineer日本語問題集PDFでProfessional-Data-Engineer日本語リアル試験問題解答

時間限定！今すぐ試そうProfessional-Data-Engineer日本語試験 [2025] 問題集でGoogleのPDF問題

質問 # 213
あなたは、さまざまなストレージサービスの各データ所有者によってデータが整理および管理されている医療組織の一員です。この分散型エコシステムの結果、データの検出と管理が困難になっています。次の点で組織を支援する、コストが最適化されたソリューションを迅速に特定して実装する必要があります。
* データの管理と検出
* データリネージの追跡
* データ品質の検証
ソリューションをどのように構築すればよいでしょうか?

A. Dataplex を使用して、データの管理、データ系統の追跡、データ品質検証の実行を行います。
B. BigOuery を使用してデータ系統を追跡し、Dataprep を使用してデータを管理し、データ品質検証を実行します。
C. BigLake を使用して、現在のソリューションをデータレイクアーキテクチャに変換します。
D. 新しいソースのオンボーディングとデータリネージの追跡に役立つ新しいデータ検出ツールを Google Kubernetes Engine 上に構築します。

正解：A

解説：
Dataplex is a Google Cloud service that provides a unified data fabric for data lakes and data warehouses. It enables data governance, management, and discovery across multiple data domains, zones, and assets. Dataplex also supports data lineage tracking, which shows the origin and transformation of data over time. Dataplex also integrates with Dataprep, a data preparation and quality tool that allows users to clean, enrich, and transform data using a visual interface. Dataprep can also monitor data quality and detect anomalies using machine learning. Therefore, Dataplex is the most suitable solution for the given scenario, as it meets all the requirements of data management and discovery, data lineage tracking, and data quality validation. Reference:
Dataplex overview
Automate data governance, extend your data fabric with Dataplex-BigLake integration Dataprep documentation

質問 # 214
「customers」という名前の BigQuery データセットがあります。すべてのテーブルは、「gdpr」という名前のデータカタログタグテンプレートを使用してタグ付けされます。テンプレートには、ブール値を持つ「機密データあり」という必須フィールドが 1 つ含まれています。すべての従業員は、データセット内で「機密データあり」フィールドが true または false であるテーブルを簡単な検索で見つけられる必要があります。ただし、「機密データあり」フィールドが true であるテーブル内のデータは、人事 (HR) グループのみが表示できる必要があります。すべての従業員グループに、データセットの bigquery.metadataViewer ロールと bigquery.connectionUser ロールを付与します。構成のオーバーヘッドを最小限に抑える必要があります。次に何をすべきでしょうか。

A. 公開可能な「gdpr」タグテンプレートを作成します。このタグの datacatalog. tagTemplateViewer ロールをすべての employees.group に割り当て、機密データを含むテーブルの HR グループに bijquery.dataViewer ロールを割り当てます。
B. プライベート可視性を持つ「gdpr」タグテンプレートを作成します。機密データを含むテーブルの HR グループに bigquery -dataViewer ロールを割り当てます。
C. 公開可能な「gdpr」タグテンプレートを作成します。機密データを含むテーブルの HR グループに bigquery.dataViewer ロールを割り当てます。
D. プライベート可視性を持つ「~gdpr」タグテンプレートを作成します。このタグの datacatalog.tagTemplateViewer ロールをすべての従業員グループに割り当て、機密データを含むテーブルの HR グループに bigquery.dataViewer ロールを割り当てます。

正解：A

解説：
To ensure that all employees can search and find tables with GDPR tags while restricting data access to sensitive tables only to the HR group, follow these steps:
Data Catalog Tag Template:
Use Data Catalog to create a tag template named "gdpr" with a boolean field "has sensitive data". Set the visibility to public so all employees can see the tags.
Roles and Permissions:
Assign the datacatalog.tagTemplateViewer role to the all employees group. This role allows users to view the tags and search for tables based on the "has sensitive data" field.
Assign the bigquery.dataViewer role to the HR group specifically on tables that contain sensitive data. This ensures only HR can access the actual data in these tables.
Steps to Implement:
Create the GDPR Tag Template:
Define the tag template in Data Catalog with the necessary fields and set visibility to public.
Assign Roles:
Grant the datacatalog.tagTemplateViewer role to the all employees group for visibility into the tags.
Grant the bigquery.dataViewer role to the HR group on tables marked as having sensitive data.
Reference:
Data Catalog Documentation
Managing Access Control in BigQuery
IAM Roles in Data Catalog

質問 # 215
Google Cloud 上に分析環境を作成し、データサイエンティストチームがオンプレミスの Apache Hadoop ソリューションに影響を与えずにデータを探索できるようにしました。オンプレミスの Hadoop 分散ファイルシステム (HDFS) クラスタ内のデータは、Hive パーティション分割の複数の列を含む最適化された行列 (ORC) 形式のファイルにあります。データサイエンティストチームは、オンプレミスの HDFS クラスタで Hive クエリエンジンの SQL を使用した場合と同様の方法でデータを探索できる必要があります。最も費用対効果の高いストレージおよび処理ソリューションを選択する必要があります。どうすればよいでしょうか。

A. ORC ファイルを Cloud Storage にコピーし、データサイエンティストチーム用の外部 BigQuery テーブルを作成します。
B. ORC ファイルを Cloud Storage にコピーし、データサイエンティストチーム用に Dataproc クラスタをデプロイします。
C. ORC ファイルをデータサイエンティストチームの BigOuery テーブルにインポートします。
D. データサイエンティストチームの Bigtable テーブルに ORC ファイルをインポートします。

正解：A

質問 # 216
あなたは、地域の BigOuery データセットにデータを保存するためのフォールトトレラントアーキテクチャを設計しています。過去 7 日以内に発生したテーブルの破損イベントからアプリケーションが回復できることを確認する必要があります。RPO が最も低く、コスト効率が最も高いソリューションを備えたマネージドサービスを導入したいと考えています。あなたは何をするべきか？

A. BigQuery から破損したデータを除外した新しいテーブルにデータをエクスポートします。
B. BigQuery テーブルのスナップショットを毎日作成します。
C. データをマルチリージョンの BigQuery バケットに移行します。
D. BigQuery でタイムトラベルを使用して履歴データにアクセスします。

正解：D

解説：
Time travel is a feature of BigQuery that allows you to query and recover data from any point within the past seven days. You can use the FOR SYSTEM_TIME AS OF clause in your SQL query to specify the timestamp of the data you want to access. This way, you can restore your tables to a previous state before the corruption event occurred. Time travel is automatically enabled for all datasets and does not incur any additional cost or storage.
Reference:
Data retention with time travel and fail-safe | BigQuery | Google Cloud BigQuery Time Travel: How to access Historical Data? | Easy Steps

質問 # 217
フローロジスティックケーススタディ
会社概要
Flowlogisticは、主要なロジスティクスおよびサプライチェーンプロバイダーです。これらは、世界中の企業がリソースを管理し、最終目的地に輸送するのに役立ちます。同社は急速に成長し、鉄道、トラック、航空機、海上輸送などの製品を拡大しています。
会社背景
同社は地域のトラック運送会社としてスタートし、その後他のロジスティクス市場に拡大しました。彼らはインフラストラクチャを更新していないため、注文と出荷の管理と追跡がボトルネックになっています。 Flowlogisticは、運用を改善するために、小包レベルでリアルタイムに出荷を追跡する独自のテクノロジーを開発しました。ただし、Apache Kafkaに基づくテクノロジースタックが処理ボリュームをサポートできないため、デプロイできません。さらに、Flowlogisticは、注文と出荷をさらに分析して、リソースを最適に展開する方法を決定したいと考えています。
ソリューションコンセプト
Flowlogisticは、クラウドを使用して2つの概念を実装したいと考えています。
*荷物の場所を示すリアルタイムの在庫追跡システムで独自のテクノロジーを使用する
*構造化データと非構造化データの両方を含むすべての注文と出荷ログに対して分析を実行し、リソースを展開する最善の方法、情報を拡張する市場を決定します。また、予測分析を使用して、出荷が遅れる時期を早期に把握したいと考えています。
既存の技術環境
フローロジスティックアーキテクチャは、単一のデータセンターに存在します。
*データベース
* 2つのクラスターに8つの物理サーバー
* SQL Server-ユーザーデータ、インベントリ、静的データ
* 3台の物理サーバー
* Cassandra-メタデータ、追跡メッセージ
10台のKafkaサーバー-メッセージ集約とバッチ挿入の追跡
*アプリケーションサーバー-顧客フロントエンド、注文/税関用ミドルウェア
* 20台の物理サーバーにまたがる60台の仮想マシン
* Tomcat-Javaサービス
* Nginx-静的コンテンツ
*バッチサーバー
ストレージアプライアンス
*仮想マシン（VM）ホスト用のiSCSI
*ファイバーチャネルストレージエリアネットワーク（FC SAN）-SQLサーバーストレージ
*ネットワーク接続ストレージ（NAS）イメージストレージ、ログ、バックアップ
* 10個のApacheHadoop / Sparkサーバー
*コアデータレイク
*データ分析ワークロード
* 20のその他のサーバー
* Jenkins、監視、要塞ホスト、
ビジネス要件
*生産のスケーリングされたパンティーを使用して、信頼性と再現性のある環境を構築します。
*分析のために一元化されたデータレイクにデータを集約する
*履歴データを使用して、将来の出荷の予測分析を実行します
*独自の技術を使用して、世界中のすべての出荷を正確に追跡します
*新しいリソースの迅速なプロビジョニングを通じて、ビジネスの俊敏性とイノベーションの速度を向上させます
*クラウドでのパフォーマンスのためにアーキテクチャを分析および最適化する
*他のすべての要件が満たされている場合は、クラウドに完全に移行します
技術要件
*ストリーミングデータとバッチデータの両方を処理します
*既存のHadoopワークロードを移行する
*アーキテクチャがスケーラブルで弾力性があり、企業の変化する要求に対応できるようにします。
*可能な限りマネージドサービスを使用する
*データの飛行と静止を暗号化する
*本番データセンターとクラウド環境の間にVPNを接続するSEOステートメント私たちは急速に成長したため、インフラストラクチャをアップグレードできないことが、さらなる成長と効率を実際に妨げています。私たちは世界中の貨物を移動するのは効率的ですが、データを移動するのは非効率的です。
顧客がどこにいて、何を出荷しているのかをより簡単に理解できるように、情報を整理する必要があります。
CTOステートメント
ITは私たちにとって優先事項ではありませんでした。そのため、データが増大するにつれて、テクノロジーに十分な投資をしていません。私にはITを管理する優れたスタッフがいますが、彼らはインフラストラクチャの管理に忙しく、データの整理、分析の構築、CFOの実装方法の理解などの本当に重要なことを彼らに行わせることができません。追跡技術。
CFOステートメント
私たちの競争上の優位性の一部は、出荷と配達が遅れた場合にペナルティを課すことです。出荷が常にどこにあるかを知ることは、当社の純利益と収益性に直接的な相関関係があります。さらに、サーバー環境の構築に資本を投入したくありません。
Flowlogisticは、主要な分析システムとしてGoogle BigQueryを使用したいと考えていますが、BigQueryに移行できないApacheHadoopおよびSparkワークロードがまだあります。 Flowlogisticは、両方のワークロードに共通のデータを保存する方法を知りません。彼らは何をすべきですか？

A. 共通データをBigQueryに保存し、承認されたビューを公開します。
B. Google CloudDataprocクラスターのHDFSストレージに共通データを保存します。
C. Avroとしてエンコードされた一般的なデータをGoogle CloudStorageに保存します。
D. 共通データをパーティションテーブルとしてBigQueryに保存します。

正解：A

質問 # 218
オープンソースベースのツールと Google Kubernetes Engine (GKE) を使用して、ワークフローパイプラインのスケジューリングを実装しています。タスクを簡素化および自動化するために、Google マネージドサービスを使用したいと考えています。また、共有 VPC ネットワークの考慮事項にも対応したいと考えています。どうすればよいでしょうか。

A. ワークフローパイプラインに Dataflow を使用します。シェルスクリプトを使用してワークフローをスケジュールします。
B. 共有 VPC 構成で Cloud Composer を使用します。Cloud Composer リソースをホストプロジェクトに配置します。
C. ワークフローパイプラインには Dataflow を使用します。スケジュール設定には Cloud Run トリガーを使用します。
D. 共有 VPC 構成で Cloud Composer を使用します。Cloud Composer リソースをサービスプロジェクトに配置します。

正解：D

解説：
Shared VPC requires that you designate a host project to which networks and subnetworks belong and a service project, which is attached to the host project. When Cloud Composer participates in a Shared VPC, the Cloud Composer environment is in the service project.Reference:https://cloud.google.com/composer/docs
/how-to/managing/configuring-shared-vpc

質問 # 219
チームメンバーにBigQueryを使ったデータ分析を依頼しているデータアナリストがいます。アナリストは、Cloud Storageバケットから毎日200個のCSVファイル（平均サイズ15MB）をBigQueryに読み込むデータパイプラインを作成したいと考えています。BigQueryで分析するためにアクセスする前に、データは取り込んで変換する必要があります。このデータアナリストに、フルマネージドでコード不要のソリューションを推奨する必要があります。どうすればよいでしょうか？

A. BigQuery データ転送サービスを使用して、Cloud Storage から BigQuery にファイルを読み込み、BigQuery SQL を使用してデータを変換する BigQuery ジョブを作成し、毎日実行するようにスケジュールします。
B. カスタム Apache Beam パイプラインを構築し、Dataflow で実行して Cloud Storage から BigQuery にファイルを読み込み、Cloud Composer を使用して毎日実行するようにスケジュールします。
C. BigQuery パイプラインを使用してパイプラインを作成し、毎日 BigQuery にデータをロードするようにスケジュールします。
D. Cloud Run 関数を作成し、Cloud Scheduler を使用して毎日実行して BigQuery にデータを読み込むようにスケジュールします。

正解：A

解説：
The requirements are for a daily scheduled load, ingest, and transformation, and specifically a fully managed, no-code solution.
* Ingest (Load): The BigQuery Data Transfer Service (DTS) is the fully managed, serverless, and no- code solution for batch loading files (including CSV from Cloud Storage) into BigQuery on a schedule. This is the "ingest" part.
* Transform: After loading the raw data into a staging table using DTS, the transformation can be done using BigQuery SQL. This transformation query can then be automated using a Scheduled Query in BigQuery, which is also a fully managed and no-code feature that runs on a schedule.
* Fully Managed & No-Code: Both DTS for Cloud Storage and Scheduled Queries are native BigQuery features that are fully managed and configured through the console without requiring code, directly meeting the constraints.
* Correcting other options:
* A (Cloud Run + Script): Cloud Run requires writing a custom Python script, which violates the no-code requirement.
* C (Dataflow + Apache Beam + Cloud Composer): This is a powerful, highly scalable ETL solution, but it requires writing custom code (Apache Beam) and requires setting up and managing a workflow orchestrator (Cloud Composer/Airflow), which violates both the fully managed (Dataflow is serverless, but the code/pipeline itself is custom and needs maintenance) and no-code requirements.
* D (BigQuery pipelines): "BigQuery pipelines" is not a distinct, official product name in the Google Cloud documentation that fulfills a no-code scheduled ETL. The closest product is the combination of DTS and Scheduled Queries, as described in option B.
Reference: Google Cloud Documentation on BigQuery Data Transfer Service and Scheduled Queries:
"The BigQuery Data Transfer Service automates data movement into BigQuery on a scheduled, managed basis... The BigQuery Data Transfer Service supports loading data from Cloud Storage in one of the following formats: Comma-separated values (CSV)..." (Source: What is BigQuery Data Transfer Service? and Introduction to Cloud Storage transfers)
"A scheduled query is a query that BigQuery automatically runs at regular intervals. When you configure a scheduled query, you specify the GoogleSQL SELECT statement to run, the destination table for the query results, and the frequency of the query." (Source: Scheduling queries) This combination delivers a fully managed, no-code ELT (Extract-Load-Transform) pipeline.

質問 # 220
Google Cloud で新しいパイプラインを作成し、Cloud Pub/Sub から Cloud Dataflow を経由して BigQuery に IoT データをストリーミングしています。データをプレビューすると、約 2% のデータが破損しているようです。この破損したデータを除外するには、Cloud Dataflow パイプラインを変更する必要があります。どうすればよいでしょうか。

A. 要素が破損している場合にブール値を返す SideInput を追加します。
B. 破損した要素を破棄するには、Cloud Dataflow に ParDo 変換を追加します。
C. Cloud Dataflow に GroupByKey 変換を追加して、有効なデータをすべてグループ化し、残りを破棄します。
D. Cloud Dataflow にパーティション変換を追加して、有効なデータと破損したデータを分離します。

正解：B

質問 # 221
GoogleのDataflowSDKを使用してソフトウェアアプリケーションを開発しており、条件付きのforループやその他の複雑なプログラミング構造を使用して分岐パイプラインを作成したいと考えています。データ処理操作に使用されるコンポーネントはどれですか？

A. 変換
B. PCollection
C. パイプライン
D. シンクAPI

正解：A

解説：
In Google Cloud, the Dataflow SDK provides a transform component. It is responsible for the data processing operation. You can use conditional, for loops, and other complex programming structure to create a branching pipeline.
Reference: https://cloud.google.com/dataflow/model/programming-model

質問 # 222
あなたは銀行で働いています。すでに付与されているローン申請と、これらの申請がデフォルトになっているかどうかに関する情報を含むラベル付きデータセットがあります。クレジット申請者のデフォルト率を予測するためのモデルをトレーニングするように依頼されました。
あなたは何をするべきか？

A. ローンの申請者とソーシャルプロファイルを照合して、機能エンジニアリングを有効にします。
B. 線形回帰をトレーニングして、クレジットデフォルトリスクスコアを予測します。
C. データからバイアスを取り除き、ローンが拒否されたアプリケーションを収集します。
D. 追加のデータを収集して、データセットのサイズを増やします。

正解：B

質問 # 223
あなたはデータガバナンスチームに所属しており、リソースをデプロイするためのセキュリティ要件を実装しています。リソースが europe-west 3 リージョンのみに制限されていることを確認する必要があります。Google が推奨するプラクティスに従う必要があります。どうすればよいですか?

A. Terraform を使用してリソースをデプロイし、変数検証ルールを実装して、すべてのリソースのリージョンが europe-west3 リージョンに設定されていることを確認します。
B. 制約/gcp. resourceLocations 組織ポリシー制約を in: europe-west3-locations に設定します。
C. 制約/gcp. resourceLocations 組織ポリシー制約を in:eu-locations に設定します。
D. 作成されたすべてのリソースを監視し、europe-west3 リージョン外で作成されたリソースを自動的に破棄する Cloud Functions を作成します。

正解：B

解説：
To ensure that resources are limited to only the europe-west3 region, you should set the organization policy constraint constraints/gcp.resourceLocations to in:europe-west3-locations. This policy restricts the deployment of resources to the specified locations, which in this case is the europe-west3 region. By setting this policy, you enforce location compliance across your Google Cloud resources, aligning with the best practices for data governance and regulatory compliance.
References:
ProfessionalData Engineer Certification Exam Guide | Learn - Google Cloud1.
Preparing for GoogleCloud Certification: Cloud Data Engineer2.
Professional Data Engineer Certification | Learn | Google Cloud3.
3: Professional Data Engineer Certification | Learn | Google Cloud 2: Preparing for Google Cloud Certification: Cloud Data Engineer 1: Professional Data Engineer Certification Exam Guide | Learn - Google Cloud

質問 # 224
開発チームと外部チームは、プロジェクトビューアのIdentity and Access Management（1AM）ロールmaフォルダにVisualizationという名前を付けます。開発チームがCloudStorageとBigQueryの両方からデータを読み取れるようにする必要がありますが、外部チームはBigQueryからのみデータを読み取ることができる必要があります。あなたは何をするべきか？

A. acme-raw-dataプロジェクトの外部チームに対するCloudStorageIAM権限を削除します
B. 外部チームCIDR範囲からのすべての入力トラフィックを拒否するacme-raw-dataprotectに仮想プライベートクラウド（VPC）ファイアウォールルールを作成します
C. 保護とCloudStorageの両方を制限付きAPIとして含むVPCServiceControls境界を作成します。開発チームのユーザーを境界のアクセスレベルに追加します
D. 保護とBigQueryの両方を制限付きAPIとして含むVPCサービスコントロール境界を作成します外部チームユーザーを境界のアクセスレベルに追加します

正解：D

質問 # 225
Flowlogistic の CEO は、顧客ベースに関する洞察を迅速に得て、営業チームが現場でよりよい情報を入手できるようにしたいと考えています。このチームは技術にあまり詳しくないため、BigQuery レポートの作成を簡素化するために視覚化ツールを購入しました。しかし、テーブル内のデータ量に圧倒され、必要なデータを見つけるためのクエリに多額の費用がかかっています。あなたは、最もコスト効率の良い方法で彼らの問題を解決したいと考えています。どうすればよいでしょうか。

A. 仮想化ツールに提示するテーブルにビューを作成します。
B. 適切な列に ID およびアクセス管理 (IAM) ロールを作成し、それらのロールのみがクエリに表示されるようにします。
C. 仮想化のためにデータを Google スプレッドシートにエクスポートします。
D. 必要な列のみを含む追加のテーブルを作成します。

正解：A

解説：
Topic 2, MJTelco Case Study
Company Overview
MJTelco is a startup that plans to build networks in rapidly growing, underserved markets around the world.
The company has patents for innovative optical communications hardware. Based on these patents, they can create many reliable, high-speed backbone links with inexpensive hardware.
Company Background
Founded by experienced telecom executives, MJTelco uses technologies originally developed to overcome communications challenges in space. Fundamental to their operation, they need to create a distributed data infrastructure that drives real-time analysis and incorporates machine learning to continuously optimize their topologies. Because their hardware is inexpensive, they plan to overdeploy the network allowing them to account for the impact of dynamic regional politics on location availability and cost.
Their management and operations teams are situated all around the globe creating many-to-many relationship between data consumers and provides in their system. After careful consideration, they decided public cloud is the perfect environment to support their needs.
Solution Concept
MJTelco is running a successful proof-of-concept (PoC) project in its labs. They have two primary needs:
* Scale and harden their PoC to support significantly more data flows generated when they ramp to more than 50,000 installations.
* Refine their machine-learning cycles to verify and improve the dynamic models they use to control topology definition.
MJTelco will also use three separate operating environments - development/test, staging, and production - to meet the needs of running experiments, deploying new features, and serving production customers.
Business Requirements
* Scale up their production environment with minimal cost, instantiating resources when and where needed in an unpredictable, distributed telecom user community.
* Ensure security of their proprietary data to protect their leading-edge machine learning and analysis.
* Provide reliable and timely access to data for analysis from distributed research workers
* Maintain isolated environments that support rapid iteration of their machine-learning models without affecting their customers.
Technical Requirements
Ensure secure and efficient transport and storage of telemetry data
Rapidly scale instances to support between 10,000 and 100,000 data providers with multiple flows each.
Allow analysis and presentation against data tables tracking up to 2 years of data storing approximately 100m records/day Support rapid iteration of monitoring infrastructure focused on awareness of data pipeline problems both in telemetry flows and in production learning cycles.
CEO Statement
Our business model relies on our patents, analytics and dynamic machine learning. Our inexpensive hardware is organized to be highly reliable, which gives us cost advantages. We need to quickly stabilize our large distributed data pipelines to meet our reliability and capacity commitments.
CTO Statement
Our public cloud services must operate as advertised. We need resources that scale and keep our data secure.
We also need environments in which our data scientists can carefully study and quickly adapt our models.
Because we rely on automation to process our data, we also need our development and test environments to work as we iterate.
CFO Statement
The project is too large for us to maintain the hardware and software required for the data and analysis. Also, we cannot afford to staff an operations team to monitor so many data feeds, so we will rely on automation and infrastructure. Google Cloud's machine learning will allow our quantitative researchers to work on our high- value problems instead of problems with our data pipelines.

質問 # 226
BigQuery によって処理される列の数を減らすために使用できる SQL キーワードはどれですか?

A. 間
B. 制限
C. 選択
D. どこ

正解：C

解説：
SELECT を使用すると、テーブル全体ではなく特定の列をクエリできます。
LIMIT、BETWEEN、WHERE 句では、BigQuery によって処理される列の数は減りません。

質問 # 227
1000 個のセンサーのネットワークがあります。センサーは時系列データ (1 秒あたり 1 つのセンサーあたり 1 つのメトリックとタイムスタンプ) を生成します。すでに 1 TB のデータがあり、毎日 1 GB ずつデータが増えると予想されます。このデータには 2 つの方法でアクセスする必要があります。最初のアクセスパターンでは、特定のタイムスタンプで保存された特定のセンサーからメトリックを取得する必要があります。平均 1 桁のミリ秒のレイテンシが必要です。2 番目のアクセスパターンでは、結合を含む複雑な分析クエリを 1 日に 1 回データに対して実行する必要があります。このデータをどのように保存すればよいでしょうか。

A. データを BigQuery に保存します。センサー ID とタイムスタンプを連結し、主キーとして使用します。
B. データを BigQuery に保存します。指標を主キーとして使用します。
C. データを Bigtable に保存します。センサー ID とメトリックを連結し、行キーとして使用します。毎日 BigQuery へのエクスポートを実行します。
D. データを Bigtable に保存します。センサー ID とタイムスタンプを連結して行キーとして使用します。毎日 BigQuery へのエクスポートを実行します。

正解：D

解説：
To store your data in a way that meets both access patterns, you should:
* A. Store your data in Bigtable Concatenate the sensor ID and timestamp and use it as the row key Perform an export to BigQuery every day. This option allows you to leverage the high performance and scalability of Bigtable for low-latency point queries on sensor data, as well as the powerful analytics capabilities of BigQuery for complex queries on large datasets. By using the sensor ID and timestamp as the row key, you can ensure that your data is sorted and distributed evenly across Bigtable nodes, and that you can easily retrieve the metric for a specific sensor and time. By performing an export to BigQuery every day, you can transfer your data to a columnar storage format that is optimized for analytical queries, and take advantage of BigQuery's features such as partitioning, clustering, and caching.
* B. Store your data in BigQuery Concatenate the sensor ID and timestamp. and use it as the primary key. This option is not optimal because BigQuery is not designed for low-latency point queries, and using a concatenated primary key may result in poor performance and high costs.
BigQuery does not support primary keys natively, and you would have to use a unique constraint or a hash function to enforce uniqueness. Moreover, BigQuery charges by the amount of data scanned, so using a long and complex primary key may increase the query cost and complexity.
* C. Store your data in Bigtable Concatenate the sensor ID and metric, and use it as the row key Perform an export to BigQuery every day. This option is not optimal because using the sensor ID and metric as the row key may result in data skew and hotspots in Bigtable, as some sensors may generate more metrics than others, or some metrics may be more common than others. This may affect the performance and availability of Bigtable, as well as the efficiency of the export to BigQuery.
* D. Store your data in BigQuery. Use the metric as a primary key. This option is not optimal because using the metric as a primary key may result in data duplication and inconsistency in BigQuery, as multiple sensors may generate the same metric at different times, or the same sensor may generate different metrics at the same time. This may affect the accuracy and reliability of your analytical queries, as well as the query cost and complexity.

質問 # 228
BigQueryで小売取引データを保持するデータモデルを作成しています。2つの最も大きなテーブル、sales_transation_headerとsales_transation_lineは、密結合された不変の関係にあります。これらのテーブルは、ロード後に変更されることはほとんどなく、クエリ実行時に頻繁に結合されます。データ分析クエリのパフォーマンスを向上させるには、sales_transation_headerテーブルとsales_transation_lineテーブルをモデル化する必要があります。
何をすべきでしょうか?

A. sales_transaction_header と sales_transaction_line の情報を行として保持する sale_transaction テーブルを作成し、各行の sales_transaction_header データを複製します。
B. 個別の sales_transation_header テーブルと sales_transation_line テーブルを作成し、クエリを実行するときに、WHERE 句で最初に販売遷移ラインを指定します。
C. sales_tran3action_header および sales_transaction_line データを JSON データ型として保存する sales_transaction テーブルを作成します。
D. sales_transaction_header 情報を行として保持し、sales_transaction_line 行をネストされた繰り返しフィールドとして保持する sales_transaction テーブルを作成します。

正解：D

解説：
BigQuery supports nested and repeated fields, which are complex data types that can represent hierarchical and one-to-many relationships within a single table. By using nested and repeated fields, you can denormalize your data model and reduce the number of joins required for your queries. This can improve the performance and efficiency of your data analytics queries, as joins can be expensive and require shuffling data across nodes. Nested and repeated fields also preserve the data integrity and avoid data duplication. In this scenario, the sales_transaction_header and sales_transaction_line tables have a tightly coupled immutable relationship, meaning that each header row corresponds to one or more line rows, and the data is rarely modified after load.
Therefore, it makes sense to create a single sales_transaction table that holds the sales_transaction_header information as rows and the sales_transaction_line rows as nested and repeated fields. This way, you can query the sales transaction data without joining two tables, and use dot notation or array functions to access the nested and repeated fields. For example, the sales_transaction table could have the following schema:
Table
Field name
Type
Mode
id
INTEGER
NULLABLE
order_time
TIMESTAMP
NULLABLE
customer_id
INTEGER
NULLABLE
line_items
RECORD
REPEATED
line_items.sku
STRING
NULLABLE
line_items.quantity
INTEGER
NULLABLE
line_items.price
FLOAT
NULLABLE
To query the total amount of each order, you could use the following SQL statement:
SQL
SELECTid,SUM(line_items.quantity*line_items.price)AStotal_amount
FROMsales_transaction
GROUPBYid;
AI-generated code. Review and use carefully. More info on FAQ.
References:
Use nested and repeated fields
BigQuery explained: Working with joins, nested & repeated data
Arrays in BigQuery - How to improve query performance and optimise storage

質問 # 229
時系列メトリックを集約して Bigtable に書き込む Dataflow ジョブを含むデータパイプラインがあります。Bigtable でデータの更新が遅いことに気付きました。このデータは、組織全体で何千人ものユーザーが使用するダッシュボードに送られます。追加の同時ユーザーをサポートし、データの書き込みに必要な時間を短縮する必要があります。どうすればよいですか?
2つの回答を選択してください

A. Bigtable クラスター内のノードの数を増やします。
B. Bigtable に書き込む前に、Flatten 変換を使用するように Dataflow パイプラインを変更します。
C. PipelineOptions で maxNumWorkers を設定して、Dataflow ワーカーの最大数を増やします。
D. Bigtable に書き込む前に、CoGrcupByKey 変換を使用するように Dataflow パイプラインを変更します。
E. ローカル実行を使用するように Dataflow パイプラインを構成します。

正解：A、C

解説：
https://cloud.google.com/bigtable/docs/パフォーマンス#パフォーマンス-書き込み-スループット
https://cloud.google.com/dataflow/docs/reference/pipeline-options

質問 # 230
CloudDataprocクラスターを管理しています。クラスターで進行中の作業を失うことなく、コストを最小限に抑えながらジョブをより高速に実行する必要があります。あなたは何をするべきか？

A. プリエンプティブワーカーノードを使用してクラスターサイズを増やし、グレースフルデコミッショニングを使用するようにノードを構成します。
B. プリエンプティブワーカーノードでクラスターサイズを増やし、CloudStackdriverを使用してスクリプトをトリガーして作業を維持します。
C. プリエンプティブでないワーカーを増やしてクラスターサイズを増やします。
D. プリエンプティブワーカーノードを使用してクラスターサイズを増やし、強制的に廃止するように構成します。

正解：A

質問 # 231
BigQuery オンデマンド環境を管理しています。ビジネスインテリジェンスツールは、日レベルと月レベルで大規模な (50 TB) 販売履歴ファクトテーブルを集計するクエリを毎日何百も送信しています。これらのクエリの応答時間は遅く、コストの予想を超えています。応答時間を短縮し、クエリコストを削減し、メンテナンスを最小限に抑える必要があります。どうすればよいでしょうか。

A. 売上テーブルの上にマテリアライズドビューを構築し、日レベルと月レベルでデータを集計します。
B. 売上テーブルの上に承認済みビューを構築し、日レベルと月レベルでデータを集計します。
C. Bl Engine を有効にし、販売テーブルを優先テーブルとして追加します。
D. スケジュールされたクエリを作成して、売上日と売上月を 1 時間ごとに集計テーブルを作成します。

正解：A

解説：
To improve response times and reduce costs for frequent queries aggregating a large sales history fact table, materialized views are a highly effective solution. Here's why option A is the best choice:
Materialized Views:
Materialized views store the results of a query physically and update them periodically, offering faster query responses for frequently accessed data.
They are designed to improve performance for repetitive and expensive aggregation queries by precomputing the results.
Efficiency and Cost Reduction:
By building materialized views at the day and month level, you significantly reduce the computation required for each query, leading to faster response times and lower query costs.
Materialized views also reduce the need for on-demand query execution, which can be costly when dealing with large datasets.
Minimized Maintenance:
Materialized views in BigQuery are managed automatically, with updates handled by the system, reducing the maintenance burden on your team.
Steps to Implement:
Identify Aggregation Queries:
Analyze the existing queries to identify common aggregation patterns at the day and month levels.
Create Materialized Views:
Create materialized views in BigQuery for the identified aggregation patterns. For example CREATE MATERIALIZED VIEW project.dataset.sales_daily_summary AS SELECT DATE(transaction_time) AS day, SUM(amount) AS total_sales FROM project.dataset.sales GROUP BY day; CREATE MATERIALIZED VIEW project.dataset.sales_monthly_summary AS SELECT EXTRACT(YEAR FROM transaction_time) AS year, EXTRACT(MONTH FROM transaction_time) AS month, SUM(amount) AS total_sales FROM project.dataset.sales GROUP BY year, month; Query Using Materialized Views:
Update existing queries to use the materialized views instead of directly querying the base table.
Reference Links:
BigQuery Materialized Views
Optimizing Query Performance

質問 # 232
あなたは世界的な海運会社で働いています。40 TB のデータでモデルをトレーニングし、特定の日に各地理的地域でどの船舶が配送遅延を引き起こす可能性があるかを予測したいと考えています。モデルは、複数のソースから収集された複数の属性に基づきます。GeoJSON 形式の位置情報を含むテレメトリデータは各船舶から取得され、1 時間ごとに読み込まれます。地域内で遅延を引き起こす可能性のある船舶の数と船舶の種類を示すダッシュボードが必要です。予測と地理空間処理のネイティブ機能を備えたストレージソリューションを使用する必要があります。どのストレージソリューションを使用すればよいでしょうか。