※この投稿は米国時間 2022 年 6 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。 編集者注: BigQuery へのオンプレミス データ ウェアハウジングの移行の一環として、Twitter と Google Cloud の両チームで Google Cloud リソース階層アーキテクチャを構築し、Hadoop 分散ファイル システム(HDFS)と BigQuery の 1 対 1 のマッピングを実現しました。スケーラビリティとセキュリティを重視して設計されたこのアーキテクチャは、HDFS / Google Cloud Storage(GCS)データ レイアウト構造とアクセス制御をミラーリングすることで BigQuery のスムーズな導入を実現するよう設定されており、スケーラブルなコンピューティングの導入が可能です。このブログ記事作成にご協力いただいた
こんにちは、データ基盤グループの吉本と吉田(id:syou6162)です。モノタロウでは基本的にはBigQueryを定額料金で利用していますが、利用者の多い時間帯はFlex Slotsも併用しています。本エントリでは、Flex Slotsの適切なスロット数を定量的に決めるために行なった試行錯誤について紹介します。 モノタロウでのBigQueryの利用状況 課題感 課題感1: 適切なFlex Slotsのスロット数をどう決めるか 課題感2: 過去の期間との実行時間は単純には比較できない 解決策 解決策1: 同一のクエリを定期的に動かし、実行時間をCloud Monitoringで計測 解決策2: 計測用オンデマンドのGCPプロジェクトでもクエリを実行し、理想状態との相対実行時間を知る まとめ モノタロウでのBigQueryの利用状況 モノタロウでは様々な意思決定の場面でデータ活用が行なわれて
データエンジニア系の勉強会で最近dbtがぱらぱらと話題に出てくるようになった & 4連休ということで、夏休みの自由研究がてらdbtを触ってみました。書いてる人のバックグラウンドは以下の通り。 DWHやデータマートの構築のためのETLツールを模索中(特にTの部分) プライベートではDataformを使っている 前職でも仕事の一部で使っていた 開発効率を計測するデータ基盤の管理にDataformを使ってみた - yasuhisa's blog 定期バッチ処理はArgo Workflows on GKEでやっている 触ってみないと肌感とか自分で運用できるかのイメージが湧かないのでね。 Dataformとの比較 細かいノウハウ 手元や本番環境での動作 Argo Workflowとの連携 環境によってDWHの提供するバージョンを差し替える DWHやデータマートの外の情報をデータリネージに加える 既存
日頃から Google Cloud Platform (GCP)がデータ分析基盤の決定版になると言い続けて・・・たぶん5年ほど経ちましたが、このたびやっと、具体的に使える基盤になってきた感じがするので、まとめておきます。 その前に。 まえおき ~ 分析仕事とデータのセキュリティデータ分析の仕事とデータセキュリティとの関係を、ここ20年くらいの流れを思い出しながらまったり書いていたら長くなったので、お急ぎの方は次の章へ。 さて、データ分析の仕事で普段からやっていることをざっくりまとめると、次の通り。 データの入手、整理、加工仮説の検討と検証、試行錯誤レポーティング、プロトタイピングさて、これらの作業をどこでやっているかというと、主に1はクラウド、2はローカルマシン、3のレポーティングはローカルですが、プロトタイピングはクラウドが多くなりました。というより、クラウドでプロトタイピングが容易にで
GoogleがBigQueryを安価に提供できる理由は、Borgによる大規模分散コンテナ環境があるから いまから6年前の2014年、当時ようやくDockerコンテナが世の中に知られるようになってきた頃、Googleはすでに社内のすべてのソフトウェアをコンテナ化しており、毎週20億個ものコンテナをクラウド上で起動していると発表し、多くのエンジニアを驚かせました。 この大規模なコンテナの制御、すなわちオーケストレーションを行っていたのが同社内で「Borg」と呼ばれるソフトウェアです。 そしてKubernetesはこのBorgを基に、Googleがオープンソース化したコンテナオーケストレーションソフトウェアだとされています。 Borgの大規模分散コンテナ基盤でBigQueryが成立する このBorgによる大規模分散コンテナ基盤があるからこそ、BigQueryが安価に提供できるのだと、Google
Cloud Data Loss Prevention (Cloud DLP) is now a part of Sensitive Data Protection. The API name remains the same: Cloud Data Loss Prevention API (DLP API). For information about the services that make up Sensitive Data Protection, see Sensitive Data Protection overview. 機密データの保護により、テーブルなどのコンテナ構造に保存されたテキストを含む、テキスト コンテンツ内の機密データを匿名化できます。匿名化は、身元がわかる情報をデータから取り除くプロセスです。この API は、個人識別情報(PII)などの機密データを検出し、匿
BigQueryのリソース配分最適化のため、プロジェクトへのコミットメントの割り当てパターンや、スロット消費の多いクエリの見つけ方などについて調査した結果をまとめてみました
Discord's migration from Redshift to BigQuery: lessons learned Editor’s note: We’re hearing today from Discord, maker of a popular voice, video, and text chat app for gaming. They have to bring a great experience to millions of customers concurrently, and keep up with demand. Here’s how they moved from Redshift to Google Cloud’s BigQuery to support their growth. At Discord, our chat app supports m
※この投稿は米国時間 2020 年 1 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。 私たち開発者の多くは、日中仕事をしているときはテクノロジーのヒーローといえます。たとえば SQL について知っているなら、あなたはデータをインサイトに変換できる能力を持ったヒーローです。困っている人が助けを求めてきたら、ビジネス提案書に載せるべき魔法の数字を教えて窮地から救ってあげることができます。データレイクを調べて見つけたパターンで同僚を驚かせることも。 Google Cloud のエンタープライズ データ ウェアハウスである BigQuery を使用すれば、すぐにスーパーヒーローになれます。他の誰よりも速くクエリを実行でき、テーブル全体のスキャンだって恐くありません。データセットを高度に利用可能な状態にできるので、メンテナンスの時間枠におびえる必要もなくなります。
Marco TranquillinCustomer Engineering Manager for Data Analytics Google BigQuery is a fully managed serverless solution for your enterprise data warehouse workloads. Nothing could be easier than that: Just upload your data via batch or streaming and start running your queries. The underlying system will seamlessly take care of providing the infrastructural resources needed to complete your differe
Purujit SahaStaff Software Engineer, BigQuery Storage BigQuery is a serverless, highly scalable, and cost-effective cloud data warehouse. It’s designed to be flexible and easy to use. There are lots of interesting features and design decisions made when creating BigQuery, and we’ll dive into how zone assignments work in this post. Like other Google Cloud services, BigQuery takes advantage of our g
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 20日目の記事です。 はじめにこんにちは、20日目の記事は、僕も大好きな BigQuery について書いてみたいと思います。BigQuery はサーバーレスでスケーラビリティに優れたデータ ウェアハウスです。インフラストラクチャの管理が不要なため、すぐに使い始めることができます!2日目の記事で keiji-san が BigQuery について書いてくれてますので、BigQueryとはなんぞやという方はご参考ください。 このブログでは既に BigQuery を使い始めたユーザーのみなさんがより BigQuery を使いこなしていくための Tips を 4つ厳選してご紹介します! カスタム割り当てを利用して、コストをコントロールする。承認済みビューを利用して、ビ
自分は BigQuery で Extract-Load されたデータを機械学習モデル用に前処理し、テラバイト級の特徴量エンジニアリングを行っています。この記事では、BigQuery のデータ量を一切消費せず、誇張なく 1 円も溶かさない裏技をまとめます。(2019/12/18 現在) ※ パロ元:BigQueryで150万円溶かした人の顔 元ネタの方と同じ職場で働くことになりましたので、被せて書いております。この記事では、BigQuery 記事最安値を目指します。 速くて安い BigQuery は、データウェアハウスとしても、特徴量エンジニアリングツールとしても優れており、機械学習モデルを用いたサービスを構築する際には、ベースラインとして一候補に挙がるでしょう。 BigQuery の料金 オンデマンドクエリを利用する際、極めて重要なのは読み取りデータ量に対して \$5/TB の料金が発生す
BigQueryへデータロードする時に圧縮をしていると、ロード時間が伸びることがあります。 この記事では圧縮の有無によってどの程度の時間差が出るのかを紹介します。 検証方法 S3に配置したファイルをEC2上のembulkによってBigQueryに転送します。 この時に使用したEC2インスタンスは c5.xlarge で、awsとGCPの間の通信は専用線ではなくインターネット回線を利用しています。 転送対象のファイルの作成 転送対象のファイルをS3に配置します。 以下のYAMLをembulkで実行することによって、gz圧縮されたcsvファイルがS3に配置されます。 ファイルのサイズは1.8GBです。 exec: min_output_tasks: 1 max_threads: 1 in: type: random rows: 10000000 schema: col1: integer co
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く