Dataformを使ってみる（BigQuery） - Qiita
Google Cloudが買収し話題になったDataformを使ってみる。 https://cloud.google.com/blog/ja/products/data-analytics/welcoming-dataform-to-bigquery BigQueryにデータ持ってきてる前提で、BigQuery内部のテーブル、データ項目、クエリの依存関係等を管理できるようだ。 ファイルの記述は基本的にSQLXという形式で記述する（JSONとSQLを混ぜたような感じ） 前提 すでにGCPプロジェクトはある。 始めてみる 事前準備 Dataform用にBigQuery Adminロールのサービスアカウントを作り、JSONキーを発行する。 方法は割愛。 Dataformのアカウントを作る dataformにアクセスして、START NOWをクリック。グーグルアカウントで始められる。 Datafo
BigQueryで特定のデータセットだけ共有する方法 - Qiita
BigQueryで特定のデータセットのみ共有したかったが、IAMユーザーの追加と、データセットの権限の両方を適切に設定しなければならず、分かりずらかったのでメモ。 実現したかったこと BigQueryの特定のデータセットをクエリが発行できる状態で外部の人と共有したい 同じプロジェクトにある他のデータセットは見えないようにしたい IAMユーザーの追加 Google Cloud のコンソール画面の「IAMと管理」→「IAM」から、データを共有したいユーザーを「BigQuery ジョブユーザー」として追加します。 データセットの共有 BigQuery の ウェブ UI で、共有したいデータセットを開いて、下記の赤枠で囲ったアイコンをクリックします。 追加したいユーザーを「BigQuery 閲覧者」として追加します。 参考情報 BigQuery / アクセス制御 Cloud Identity an
BigQueryのコストに対する恐怖心を払拭する - Qiita
はじめに 大量データをクラウドに格納してデータ分析に利用してみようと思い、 速い・安いと言われるGoogleCloudPlatform(GCP)のBigQueryを触ってみた… かったのですが、以下の記事にもあるように予想外に課金されてしまった事例を小耳に挟んでいたため二の足を踏んでいました。 BigQueryで150万円溶かした人の顔 BigQueryのコストに対する恐怖心を払拭すべく公式ドキュメントを料金面にフォーカスして読み解き、 不用意に大量課金されないよう気をつける点をまとめたのが本記事となります。 今後も改定される可能性もありますので、利用の際にはご自身でも確認していただければと思います。 また、情報が誤っていた場合はご指摘いただければ幸いです。 課金される操作 BigQueryで課金される内容は ・ストレージ代金 ・データ操作代金 です。単純ですね。 ただし、データ操作は回数
BigQueryで150万円溶かした人の顔 - Qiita
※ かなり前の記事ですが、未だに引用されるので一応追記しておきます。タイトルと画像がキャッチーなのはちょっと反省していますが、これを見てBigQuery使うのを躊躇している人は多分あまり内容を読んでいないので気にする必要はないです。自分は当時の会社でも今の会社でも個人でも普通にBigQuery使っていて解析用データなどはBigQueryに入れる設計をよくしています。また、アドベントカレンダーだったのでネタっぽく書きましたが事前に想定できる金額です。 ※ 代役：プロ生ちゃん（暮井 慧） 巷のBigQueryの噂と言えば「とにかく安い」「数億行フルスキャンしても早い」などなど。とりわけ料金に関しては保存しておくだけであれば無視できるほど安く、SQLに不慣れなプロデューサーがクエリを実行しても月数ドルで済むなど、賞賛すべき事例は枚挙に暇がありません。 しかし、使い方によってはかなり大きな金額を使
16000行の壁を超えてさくっとダウンロードしたい (BigQueryの話) - Qiita
Meguro.es #17 @ Drecom 2018年10月4日 自己紹介 ちきさん GitHub/Twitter/Qiita: @ovrmrw 市ヶ谷のオプトという会社で働いています (話すこと) BigQueryのクエリ結果がデカいときに簡単にローカルにダウンロードする方法 BigQuery は Web UI で使いたいじゃないですか Web UI を使うメリット・デメリット メリット クエリを書いてすぐに実行できるのでさくさく試せる。 クエリを保存する機能が便利。 エンジニアじゃなくても使える。例えばビジネスの人とか。 デメリット 16000行を超える結果を簡単にダウンロードできない。 16000行で切られてしまう選択肢 JSON としてダウンロード CSV 形式でダウンロード スプレッドシートに保存 たとえクエリ結果が100万行でも勝手に切られてしまう。かなしい。 かなしい例 で
BigqueryとColaboratoryで売上を統計分析する基盤を試作した話 - Qiita
Excelの限界 弊社の某プロダクトでは個々の契約の利用料金は自動的に算出しているのですが、 それ以上の粒度、例えば四半期や通期の売上総額や、各メニュー毎の売上等の集計には（多くの企業でそうであるように）Excelが用いられています。 Excelは誰でも直感的な操作が可能な素晴らしいものですが、その反面いろいろな制約があります。 扱えるデータが小さい データの再利用性が低い 10万行くらいで操作性的にかなりしんどく、100万行を超えると物理的に扱うことができません。また、データの参照と加工が一体化しており直感的な反面、長期的な再利用が難しく、長期間にわたる集計を行うのは重労働になりがちです。いきおい長期的なデータを様々な角度から自由に分析する、というのはなかなか難しくなります。 今回は、私が担当している某プロダクトの売上等のデータを長期的に集積し、統計処理や可視化を行うための基盤を試作して
BigQuery では COUNT(DISTINCT(X)) ではなく EXACT_COUNT_DISTINCT(X) を使おう - Qiita
以前、COUNT(DISTINCT(X)) の代わりに GROUP BY して COUNT(X) しようという記事を書きました。 BigQuery で COUNT(DISTINCT(X)) を使わない方が良い理由 が、今は時代が変わりました。BigQuery にいつの間にか、EXACT_COUNT_DISTINCT() 関数が追加されたのです！ Returns the exact number of non-NULL, distinct values for the specified field. For better scalability and performance, use COUNT(DISTINCT field). さらに non-NULL な値だけを数えてくれるという嬉しい仕様です。 というわけで、前の記事と同じく実際に publicdata:samples.github
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
BigQuery・Glue・S3・QuickSightの連携 - Qiita
【BigQuery】LAG関数，LEAD関数の使い方 - Qiita