Google Cloud Platform (Google App Engine, Compute Engine, BigQuery や Container Engine など)の情報の日本公式ブログ
![Google BigQuery - コスト計算と最適化](https://cdn-ak-scissors.b.st-hatena.com/image/square/832e1ee57367511106911167fde597eb46a6b3b5/height=288;version=1;width=512/http%3A%2F%2F3.bp.blogspot.com%2F-m90zG1Qb7vc%2FVel5wAn_isI%2FAAAAAAAARGE%2FiSOuuYWUXUA%2Fs1600-r%2FCloudPlatform_128px_Retina.png)
はじめに これは ドリコムAdventCalendar の7日目です 6日目は、keiichironaganoさんによる iTunes 使用許諾更新のとき一旦キャンセルしてほしい話 です 【その2】ドリコム Advent Calendar 2015 もあります 自己紹介 @ka_nipan 去年の ドリコムを支えるデータ分析基盤 に引き続き、今年もドリコムのデータ分析基盤を担当しています。 分析基盤をTreasure Dataに移行 オンプレ環境の Hadoop からTreasure Data に移行しました。 また、ジョブ管理ツールやBIツールといったサーバーもAmazon EC2 に移行しており、 徐々にオンプレ環境を離れつつあります。 背景 オンプレ環境で Hadoop を運用して3年も経つと考えなければならないのが HW の寿命です。 さてどうしようかとなった時に、ほぼ迷いなく外部
※ かなり前の記事ですが、未だに引用されるので一応追記しておきます。タイトルと画像がキャッチーなのはちょっと反省していますが、これを見てBigQuery使うのを躊躇している人は多分あまり内容を読んでいないので気にする必要はないです。自分は当時の会社でも今の会社でも個人でも普通にBigQuery使っていて解析用データなどはBigQueryに入れる設計をよくしています。また、アドベントカレンダーだったのでネタっぽく書きましたが事前に想定できる金額です。 ※ 代役:プロ生ちゃん(暮井 慧) 巷のBigQueryの噂と言えば「とにかく安い」「数億行フルスキャンしても早い」などなど。とりわけ料金に関しては保存しておくだけであれば無視できるほど安く、SQLに不慣れなプロデューサーがクエリを実行しても月数ドルで済むなど、賞賛すべき事例は枚挙に暇がありません。 しかし、使い方によってはかなり大きな金額を使
fluent-plugin-bigqueryを使ってBigQueryにStreaming Insertでログを書き込む時に、 痕跡なくログが欠損するケースがあるのでは? という話です。 fluent-plugin-bigqueryでのログの書き込み処理/エラー処理はこのようになっています。 res.success? がtrueであればエラーはなく書き込みが成功しているという想定。 falseの時にはレスポンスのjsonのerrorエラーの中身を見て、ログを吐くなどのエラー処理をするようです。 res = client().execute( api_method: @bq.tabledata.insert_all, parameters: { 'projectId' => @project, 'datasetId' => @dataset, 'tableId' => table_id, },
3行でまとめ 1つの列に JSON 文字列を突っ込む JSON functions を使って、必要な値を取り出す 要するに RDB の JSON 型みたいな感じで運用しようということ。 どういう時に使うの? 「1時間後からログ分析するから」とぶっこまれた時。当然、スキーマは決まっていない。あとは、使い捨てのアドホックな分析とか簡易ETLツールとして使うと便利だと思う。 なお、この方法はコストもかかるし、速くもない、実際は BigQuery なので速いけど、相対的には速くないので、甘えずにスキーマはちゃんと決めるようにしよう。 手順 スキーマを準備
All slide content and descriptions are owned by their creators.
皆様こんにちは。 アドテク本部カラムーデータベースゼミチームです。 今回の記事ではゼミチームが行った検証結果について発表させていただきます。 また、この記事につきましては 11/12 に行われた db tech showcase Tokyo 2014 にて発表させて頂きました内容になります。 プレゼン資料はこちらにあがっています。 ※追記 Impala / Presto の File Format についてご指摘を頂きましたのでデータロード及びまとめの部分に追記しました。 アドテクスキルアップゼミ カラムナーデータベース検証まとめ目的 広告システムでは大量のデータをデータベースに入れて解析を行います。 小規模から中規模なデータはRDBMSで行えますが、数TBを超えると RDBMS以外の選択肢を探さないといけません。 ビッグデータ用のデータベースは比較資料が少なく、 また、あったとしても検証
最近なんだか個人的に電子工作ブームで、ついAmazonでRaspberry Piをポチってしまった。とりあえずウェザーステーション(気温・湿度・気圧を測るやつ)を作ってみた。 びろーんと伸びてるのは温度・湿度センサーDHT22で、基板上で青く光っているのが気圧センサーLPS331。丸くて黒いやつはなんとなくつけてみた圧電スピーカーで今回は使ってない。 そして、これらのセンサーデータを10秒おきにFluentd経由でGoogle BigQueryに送る簡単なPythonコードを書いた。Google SpreadsheetからBigQueryのクエリを実行して描いた俺の部屋のお天気環境グラフがこんな感じ。 単に1台分のグラフを書くだけならBigQueryにデータを入れる必要はなくてSpreadsheetに直接送れば済むのだけど、RasPi+Fluentd+BQの連携をいちど試してみたかったのだ
gcp ja night #28 に参加してきたので、色々まとめるよー。スライド資料を見ればわかるようなことは書かない方向で。 懇親会の場で、Googler の佐藤さんに、前から気になってたことをいくつか質問できたので、その内容もこのエントリの最後にメモっとく。 イベントページ gcp ja night #28 - connpass 各種まとめ 2014.09.16 gcp ja night #28 #gcpja - Togetter gcp ja night #28 - 資料一覧 - connpass Managed VMのDocker対応とKubernetes最新動向 @briandorsey by Brian Dorsey, Developer Advocate, Google Inc. 僕の観測範囲では、スライド資料の公開はなし GAE などのような PaaS を使いつつ、IaaS
Google BigQueryを使ってみようと思って、最近少し勉強している。Googleがホワイトペーパーを出していたので、読んでみた。(※2012年の文献) BigQuery についてのホワイトペーパーを公開しました - Google Developer Relations Japan Blog 以下、内容の簡単なメモ。 もともとGoogle社内で利用されていた Google社内で利用されてきた'Dremel'というサービスがある。巨大なデータに対してSQLライクなクエリを実行すると、数秒で結果が返ってくる。Googleでは、エンジニアだけでなくアナリストなど非エンジニアの人も利用している。 Dremelがベースとなり、外部に公開されたのがBig Query。フルマネージドなクラウドサービス。サードパーティの開発者は、REST APIやCLI, Web UIなどを利用してこのサービスにア
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
先日、有志で集まって「BigQuery Analytics」という書籍の読書会をやった。その名の通り Google BigQuery について書かれた洋書。 BigQuery を最近仕事で使い始めたのだが、BigQuery が開発された背景とかアーキテクチャーとかあまり調べもせずに使い始めたので今更ながらその辺のインプットを増やして以降と思った次第。 それで、読書会の第1回目は書籍の中でも Overview に相当するところを中心に読み合わせていった。それだけでもなかなかに面白かったので少しブログにでも書いてみようかなと思う。 BigQuery の話そのものも面白いが、個人的には Google のインフラが書籍『Google を支える技術』で解説されたものが "Big Data Stack 1.0" だとして、BigQuery は Big Data Stack 2.0 の上に構築されており
Hadoop Conference Japan 2014 参加メモ(キーノート) #hcj2014 の続きです。 続いて、個別セッションの前半。先は長い。。。 個別セッション BigQuery and the world after MapReduce Speaker: 佐藤一憲 (Google) GCPサポート GCP solutions design Docker/GCP meet up Google I/O で、GoogleはMapReduceを使っていないという話があった We use Dremel ≒ Google BigQuery(MPP) 68B records in ~20 secs 120億行フルスキャンで10秒ぐらい コスト Storage 0.026/GB per manth Query: $5/TB Column Oriented Storage HDFSの元となっ
Tensor Processing Unit (TPU) Overview (July 6, 2018)
Twitter のタイムラインを保存しておくとなにかと便利なので、色々と保存形式を変えながら 4 年くらい記録し続けている。ツイートの保存が便利すぎるので、ツイセーブというサービス化までした。かつてはテキストで、MongoDB や MySQL とか Groonga とかいろいろやってきた。どれも問題ないんだけど、増え続けるログデータを保存する場所として考えると BigQuery が現代にマッチしてるようなのでそちらに移行した。 BigQuery に TL を保存するとできること TL の全てのデータをフルスキャンできる。これはかなり便利で、今回このブログ記事を書くにあたっても ‘BigQuery’ を TL から検索すれば、信頼できるフォローイングの人々の声を見ることができた。これにより「某 CA 社では 5000 台の MongoDB クラスタで BigQuery に対抗している」という
「BigQueryは120億行を5秒でフルスキャン可能」は本当か? 先日、kaheiさんがGoogle BigQuery(Googleクラウドの大規模クエリサービス)について、こんなエントリを書いていた。 とにかくパフォーマンスがすごい。(Fluentd Meetupでの)プレゼン中のデモで、ディスクに収められた5億件のデータをSQLでフルスキャンするのに3秒しかかからない。9億件のデータを正規表現を含んだSQLでスキャンしても、7秒で終わる(これ、記憶がちょっとあいまい。もう少しかかったかも)。これには驚いた。佐藤さんがGoogleに入社して一番驚いた技術が、一般公開される前のBigQueryだったと言っていたが、その気持ちはわかる。 From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluent
★受講中に書いていたメモを、推敲無しでそのまま上げています。 ★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。 600億件を数十秒で検索するクラウド検索クエリサービスBigQuery / 佐藤一憲氏@google 導入 BigQueryのプレゼン 自己紹介 @kazunori_279/#gaeja/#gcloudja クラウドソリューションチーム ソリューションズアーキテクト appengine ja night管理人(23回くらい) AppEngine技術者のための情報交換イベント Agenda ビッグデータをGoogleスピードで 「Googleスピード」は社内用語、すごく早い デモ&事例紹介 WhitePaper なぜ早い? MapReduceとGoogleBigQueryの適材適所 ビッグデータをGoogleスピードで Googleではコードを書く時に最初にスケーラビリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く