最初にBigQueryとSnowflakeの概要と、登場の背景を説明します。 その後、ユーザにとっての使い勝手と、管理者にとっての使い勝手を、ベンダーフリーな立場でそれぞれします。 最後に、BigQueryとSnowflakeどっちが速いのか?といった疑問に対して、アーキテクチャをもとに考察します。
Send feedback Stay organized with collections Save and categorize content based on your preferences. Introduction to data masking BigQuery supports data masking at the column level. You can use data masking to selectively obscure column data for users groups, while still allowing them access to the column. Data masking functionality is built on top of column-level access control, so you should fam
Transcript GA4+BigQuery ハンドブック Ver 1.0.0α しんゆう @data_analyst_ 本資料について • GA4+BigQueryはまだオフィシャルサイトにも情報が少 なく手探り状態 • そこでいろいろな情報を1つにまとめておくことは有用だ と考えた • まだまだ取り組み始めたばかりなので間違いや効率の悪い 方法を見つけたら教えていただけると幸いです 本資料について About 本資料について • 2021/10/13 α版公開 更新履歴 About 名前:しんゆう @data_analyst_ ブログ:データ分析とインテリジェンス https://analytics-and-intelligence.net 最近の活動:データを使いやすくする人 (データアーキテクトまたはデータ整備人) スライドが表示されているページの下段にある説明欄からも リンクが
※この投稿は米国時間 2020 年 1 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。 私たち開発者の多くは、日中仕事をしているときはテクノロジーのヒーローといえます。たとえば SQL について知っているなら、あなたはデータをインサイトに変換できる能力を持ったヒーローです。困っている人が助けを求めてきたら、ビジネス提案書に載せるべき魔法の数字を教えて窮地から救ってあげることができます。データレイクを調べて見つけたパターンで同僚を驚かせることも。 Google Cloud のエンタープライズ データ ウェアハウスである BigQuery を使用すれば、すぐにスーパーヒーローになれます。他の誰よりも速くクエリを実行でき、テーブル全体のスキャンだって恐くありません。データセットを高度に利用可能な状態にできるので、メンテナンスの時間枠におびえる必要もなくなります。
自分は BigQuery で Extract-Load されたデータを機械学習モデル用に前処理し、テラバイト級の特徴量エンジニアリングを行っています。この記事では、BigQuery のデータ量を一切消費せず、誇張なく 1 円も溶かさない裏技をまとめます。(2019/12/18 現在) ※ パロ元:BigQueryで150万円溶かした人の顔 元ネタの方と同じ職場で働くことになりましたので、被せて書いております。この記事では、BigQuery 記事最安値を目指します。 速くて安い BigQuery は、データウェアハウスとしても、特徴量エンジニアリングツールとしても優れており、機械学習モデルを用いたサービスを構築する際には、ベースラインとして一候補に挙がるでしょう。 BigQuery の料金 オンデマンドクエリを利用する際、極めて重要なのは読み取りデータ量に対して \$5/TB の料金が発生す
※この投稿は米国時間 2019 年 9 月 25 日に Cloud Blog に 投稿されたものの抄訳です。 あらゆる業務のデータが各所に分散する今日の状況において、データ ウェアハウスの運営、管理は厄介で手間のかかる作業となりがちです。こうしたデータの急激な増加に対応してシステムをスケーリングし、日々の運用を維持することは、これまでになく大きな課題となっています。課題はそれだけではありません。データ ウェアハウスをアップグレードするときにダウンタイムをできるだけ短くする、ML や AI に向けた取り組みを支えてビジネスニーズに応えるなどの必要にも迫られています。Google Cloud のサーバーレス、エンタープライズ向けデータ ウェアハウスである BigQuery は、インフラ管理に手間を取られず分析作業に集中できるという点が評価され、数々の企業に導入されています。 BigQuery
BigQuery MLによる予測の全体像 機械学習を学ぶにあたり、その全体像が提示されていないことが妨げになっている気がしています。筆者も勉強中の身ではありますが、自分自身の学びの整理のためにも本記事を執筆しています。 本ブログ記事は、過度に詳細に踏み込まない代わりに、その全体像を提示することで、私と同様の学習者である多くのユーザーがBigQueryのMLエンジンを利用できるようになる(少なくともやってみようと思える)ことを目的としています。 全体像は以下の7ステップで説明できます。そのうち、純粋に機械学習周りの技術を使っているのは、3、4、5、6のステップであり、1、2は準備、7は検算です。 データの取得と整形 整形の完了したデータのアップロード モデルの作成 モデルの評価 特徴量の調整やモデルのオプションの調整 予測値の取り出し 検算 ① データの取得と整形 機械学習にはある程度まとま
ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話 / Moving ZOZOTOWN DWH from Redshift to BigQuery
BizReachプロダクト開発部、SREグループの久保木です。5月頃に中途で入ってきて、今はinfrastructure中心に開発に従事しています。 最近はlog生成周りをいじっていった結果、生成元であるapplicationもいじれるようになってきた気がします。あとはfrontendいじれば制覇かな!(<どこに行く気なの?) ところで、元々僕は何かを作る時に延々とmemoがてら作業進捗を書いていく癖があります。 それで作業が一区切りしたところで、 「あれ、これ記事のネタになるんじゃない?」 と思ったので書いてみることにしました。ボリュームがあるので連載にてお送りします。 どうぞよろしくお願いします。 前編: 概要 中編: 技術調査・設計 後編: 七転八倒ログ 何があったのか まず、前提。 BizReachのapplicationはlogをS3に飛ばして、そこからなんやかんやあって(後述)
SRE所属の @siroken3 です。最近はもっぱらパートナー会社様とのデータ連携環境構築を主に、時々プロダクションのMySQL環境と分析基盤との連携インフラの構築が多いです。 本記事は、メルカリに出品された過去すべての商品をBigQueryへ同期するにあたって取り組んだ時のお話です。 背景 当社では分析目的などでBigQueryを以前から使用しており、プロダクションのMySQLからBigQueryへデータを同期して分析に活用してきました。特に商品を表すテーブルは重要です。 しかし、後述する課題によりBigQueryにアップロードすることができなかったため、分析用のMySQLDBのスレーブとBigQueryを併用せざるを得ませんでした。とはいえ不便なので以前からBigQueryのみで商品テーブルも分析対象としたい要望がありました。 課題 メルカリでは販売済み商品を物理削除していないため、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く