2015/11/12 Apache Drill Meetup Tokyo CyberAgent / AMoAd 渡部 優 ( Watanabe Masaru )

なぜDMMがweb3に参入したのか。Seamoon Protocolが目指す新たなエンタメ体験の未来とは

経緯 ちょうどログ解析基盤を移行しようとしていたところに、下記の記事が。 Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja BigQueryは、社内の利用者も多いGoogle Apps Script用のAPIも用意されているので、これは検証せねばと思っていました。 検証には、こちらの記事がたいへん参考になりましたm(__)m FluentdでGoogle BigQueryにログを挿入してクエリを実行する そして、課題も。。 fluent-plugin-bigquery単体では、BigQueryの格納先tableを動的に変更することができません。 BigQueryのPricingをみると、クエリ毎にtableのデータ量で課金されます。また、recordの削除はできないので、定期的にtableを変更してクエリ対象のtableが肥大化し

現状のfluentdでは、タグを動的に扱う方法がいまいち無い。具体的に言うと設定項目にタグに応じて変化するような指定をしたい場合、タグごとに分けて書くしかない。例えば out_file で出力先ファイル名をタグに応じてつけたい場合、タグの数だけ match 節を書く必要がある。 <match hoge> type file path /var/log/hoge.log </match> <match pos> type pos path /var/log/pos.log </match> # 以下いっぱいこれには極めて簡単にわかる範囲で、ふたつの大きな問題がある。 多数のタグを扱う場合、設定ファイル全体のボリュームが肥大化して管理コストが増大する(品質が低下する) 新しく扱うタグが増える場合、設定ファイルの更新と適用が必要となり、管理コストが増大する 既に手元でこの問題に悩まされていて、H

Fluentdはデータを流すのに非常に便利なツールでそこら中で使われている(個人調べ)。そのため、なんかいろんなところで設定を見るのであるが、タグに情報が付いていたりフィールドに情報がついていたりして、あれ、これどうなってるんだっけ感に襲われることがよくある。 このあたり自分でも混乱しがちなので、普段どのように考えているかだいたいまとまった気がしたところで書いておくことにした。 Fluentdのデータ構造 まずはFluentdのデータ構造を知っておいた方が良い。Fluentdの内部データはMessagePackで符号化されているが、Fluentdのデータ構造は単なるハッシュではなく、時刻(time)とタグ(tag)という属性を持っている。次のような感じだ。 レコード レコード(record)は入力されたデータそのものであり、tailプラグインであれば、tailした1行のデータに相当する。重

BigQuery gets big new features to make data analysis even easier Share Facebook Twitter LinkedIn Mail By Michael Manoochehri, Developer Programs Engineer, Cloud Platform Google BigQuery is designed to make it easy to analyze large amounts of data quickly. Overwhelmingly, developers have asked us for features to help simplify their work even further. Today we are launching a collection of updates t

アプリからイベントデータをガンガン送信するぜ！ BigQuery上にBigData載せてデータ解析するぜ！ テーブル作ったぜ！ イベントデータのプロパティに情報追加したいぜ！ BigQuery loadできないぜ！？ BigQuery error in load operation: Illegal Schema update. Cannot add fields (field: hogehoge)

Treasure Dataが提供しているFluentdの配布パッケージであるtd-agentの今後について書く．この記事は http://docs.fluentd.org/articles/td-agent-v1-vs-v2 http://docs.treasure-data.com/articles/td-agent2 とかMLでのアナウンスを日本語でまとめたような感じの記事です． 現在は1と2の二つのバージョンが並行してリリースされているので，まずそれぞれの違いについて書きます． td-agent 1 今までのメインバージョンであり，現在はold stable．同梱ライブラリの大きなバージョンアップはありません．最新版の1.1.21では以下のものが同梱されています Ruby 1.9.3 jemallocやmsgpackなど，コアライブラリ群 Fluentdとよく使われるプラグイン群 サ

「この本に何が書いてあるか教えてほしい。あとブログ書いて」 IT系ベンチャー企業でインターンを始めた筆者が初日に渡された本は、ビッグデータ分析ツールについて書かれた洋書でした。社長はなにを考えていらっしゃるのでしょうか。なにかの間違いで採用された文系大学生に無理難題を押し付けて、辞めさせようというのでしょうか。きっとそうに違いありません。しかし、ここで辞めるわけにはいきません。なぜなら溜池山王のおいしいごはん屋さんを食べつくさなければならないからです。こうして筆者は、ネットワーク界隈に跳梁跋扈する小難しい専門用語やつかみどころのない概念に立ち向かうことを決意したのです。 (注)この記事の目的は、ビッグデータ分析を支える技術とGoogle BigQueryを用いる利点について、予備知識なしで読めるという意味でかんたんな説明を行うことです。 BigQueryとは Google BigQuery

最近、bigqueryの評価を行っている。本番向けのデータではよくあることだが、本来データが入る場所にnullが入っていたり、要素が無かったり、逆に要素が多かったりする。 bigqueryはTreasureDataの様にスキーマレスではなくきちんとスキーマを定義しなければならない。 bigqueryでは、スキーマの定義にjsonを使い、データのロードにもjsonを使うため、要素にミスマッチが発生する場合が考えられる。 スキーマとjsonで要素のミスマッチがあった場合は、データにnullが入っていた場合のbigqueryの挙動に関してまとめた。 最初に結果だけ書き、後半に実際にデータロードで試したサンプルを乗せる。 データロード時のBigQueryスキーマと、jsonの対応 送信jsonにスキーマがある。 送信jsonにスキーマが無い

また、Developer Console上からファイルをアップロードする場合に関してはドキュメントに明記がなかったので推測ではありますが、quota制限はジョブと同じような感じではないかと思います。 ジョブを使うメリットとしては1度のデータ読み込みで大きなデータファイルを送れることやGCS上のファイルを送れること、streamを使うメリットは一度に送れるデータ量はそれほどではないものの、ジョブ実行時の遅延もないので割とリアルタイムにデータ送信、データ分析を行えること等が挙げられます。 これらの方法で読み込んだデータをBigQueryに新しく作ったテーブルや既存のテーブルに追加したり、テーブルのデータの書き換えたりすることが出来ます。 今回は、上述したデータ取り込み方法のうち、Streamを使ったBigQueryへのデータ取り込み方法の詳細と実装例について解説します。 以下、基本は http

4/16 に Google Cloud Platform Blog にて Cloud Dataflow の Public Beta の開始と共に、BigQuery の各種アップデートが発表されました。 リリースノートも久々に更新されています。 しかし、ここに書いてある事以外にも色々と変更点が発見されていますが、情報が散在しているため、変更点をまとめてみました。まだ、漏れがあるかもしれないので、ご指摘をお待ちしております。 （4/18追記）4/17 に公式 Blog でもまとめ記事が出ました。確認中です。 アップデート内容一覧 Streaming Insert の制限の緩和 Streaming Insert の値段の変更 Batch Insert (Load) の制限の緩和 Google Cloud Datastore データのロードに対応 API リクエスト数制限の緩和 クエリの追加（ドキ

3千万件送信して、2605件のログが欠落した。 今回の調査ではここまでになった。 BigQueryはログを取り入れてからは素晴らしいけど、まずログを取り入れる部分で不安がある。td-agentを使わなければ良いのかもしれないが、そうするとログ収集システムを自前で構築せねばならず非効率である。 googleはfluetdをGCEなどの標準ログコレクターにしたのだから、bigqueryプラグインについても手を加えてくれても良いかも知れない。 TreasureDataへ、並列送信 後半は、TreasureDataへも並列で送信を行った。一番最後に一千万件のログを送信した際には、TreasureData,BigQuery両方共ログ欠損はなかった。 TreasureDataの設定は特に何もしなくても、ログ欠損が起こらないのが素晴らしい。 ログ欠損とデータ分析 今回の調査ではfluent-plugin