#jawsdays 2015での発表スライドです。 http://jawsdays2015.jaws-ug.jp/speaker/suzuki/

Query Everything. Fast. Open Source.Presto is the blazing-fast, scalable SQL query engine for modern data analytics. What is Presto?Presto lets you query massive datasets across multiple data sources with sub-second performance. Whether it’s ad hoc analytics or powering real-time apps, Presto is fast, reliable, and efficient at any scale. Access Data AnywherePresto lets you query data where it liv
メルカリ、SmartNews、フリークアウト3社合同のエンジニアイベントに潜入することに成功しまして、そのログをBASE社長の鶴岡に共有する約束をしたのですがQiita Teamがまだ試用版で社員全員に見せられないため、ここに張っておきます。 適当なメモですいません。なおLogmiの河原さんがいらっしゃったので、後日、ちゃんとした書き起こしが別途公開されると思いますので、頑張って見なくて良いと思います。 経営者層は後半の方が推奨部分です。 あくまでも僕のフィルターが入った記述なので、問題がありそうなところがあっても過激な反応はしないでください。 もしイベント関係者の方で誤りや問題がある記述がありましたらお教えください。修正いたします。 ————————– フリークアウト 箭内さん プロダクトマネージャー SIerで、PG/SE -> 広告専門で5年半 DSP ,DMPのプロダクトマネジメン
Hadoop環境もDockerを使えば管理が効率化する? AltiscaleがYARNへの適用を進めている。 Hadoopサービスを手掛ける米Altiscaleは、2014年6月3~5日に開催された「Hadoop Summit」に合わせ、DockerをYARN(Yet-Another Resource Negotiator)に対応させるために同社が進めているプロジェクトをブログで紹介した。 YARNはHadoop 2.0で登場した「次世代Map/Reduce」とも言われるフレームワークで、データ処理とクラスタリソース管理の機能を分離する実装になっている。Map/Reduce以外のアプリケーションの動作に門戸を開くものとして注目を集めている。 「Dockerは、現在のハイパーバイザーモデルでは達成できないレベルの効率性で次世代の仮想化を実現できる可能性がある。Hadoop YARNをDock
Hadoopソースコードリーディング 第16回に参加してきました。今回は1.0がリリースされる目前のApache Sparkがテーマでした。 NTTデータ濱野さんの冒頭の挨拶 Spark1.0リリースを記念する予定が、されていないw 今回はお酒を飲んでグダグダする時間はないw Apache Sparkのご紹介(前半) NTTデータ土橋さん まずは土橋さんからSparkの背景やSpark Summit 2013の振り返り、Sparkの基本についての説明がありました。詳細はスライドを見てもらった方がいいですが、さくっと雰囲気を掴みたい方は以下のメモをご参照下さい。 土橋さん 6年前からHadoopに関わっている。 基本はインフラエンジニア Ansible使っている。 アジェンダ Sparkの背景 Spark Summit 2013振り返り Sparkのキホン RDD スケジューラ 前提 机上調
From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluentd Meetupのデモでは9億件を7秒程度で検索していたが、BigQueryの真の実力はこれより1〜2ケタ上だからだ。ちょっと手元で少し大きめのテーブルで試してみたら、120億行の正規表現マッチ付き集計が5秒で完了した。論より証拠で、デモビデオ(1分16秒)を作ってみた: From The Speed of Google BigQuery これは速すぎる。何かのインチキである(最初にデモを見た時そう思った)。正規表現をいろいろ変えてみてもスピードは変わらない。つまり、インデックスを事前構築できないクエリに対してこのスピードなのである。 価格も安い。さすがに120億行のクエリは1回で200円もかかって気軽に実行できなさそうであるが、1.2億
最近スキルの幅が広がったかなと思います。 理由としては ビジネスで要件がでる。 -> とある技術を使わなければいけない。 -> その技術を理解する&使う。 こういうフローが経営に近くなるほど起こりやすいのでスキルの幅がかなり広がっています。 最近で身に付けた技術は fluentd Hadoop (EMR) Hive Bandit Algorithm なんかを身に付けました。 どんなフローで身に付けていったかを簡単に書いていきます。 スライドシェアを見る 公式ドキュメントよりもまずはこっちを先に見るのがよいかと思います。 理由としては使い方以外に「なぜそれを使うのか」ということが同時にわかるケースが多いからです。 バンディットアルゴリズムの時には バンディットアルゴリズム入門と実践 バンディットアルゴリズム概論 この2つがかなり参考になりました。 入門書を読む イントロダクションはス
Index ログ集計システムの要件 DB設計 データ保存方針 table設計 サーバ構成 Fluentd fluentd,fluent-plugin-mysql-bulk install td-agent.conf mysqlにデータが格納される事を確認する 集計用のバッチ その他 Table肥大化防止 可視化 ログ集計システムの要件 爆弾ログ処理班の@yutakikuchi_です。 ログ集計システムというものを作る時に皆さんはどのように対応していますか? 以下の候補から要件のレベルで使い分けをしている人が多いと予想しています。ざっくりの評価ですが、導入難易度、正確性、可視化、リアルタイム、長期集計、スケール、運用費用という点で評価を書いています。 ツール 導入難易度 正確性 可視化 リアルタイム 長期集計 スケール 運用費用 リンク GA(スタンダード) ○ × ○ ○ ○ ○ ○ Go
今注目のSpark SQL、知っておきたいその性能とは 20151209 OSC Enterprise
株式会社データホテルの伊勢です。 2012年8月18日(土)に開催されました 第2回 NHN テクノロジーカンファレンス の発表資料と動画を公開致します。 ご登壇頂きました皆様、ご参加頂きました皆様、どうもありがとうございました。 また、今回「H」な技術と言う事で、オライリー・ジャパン様より「HBase」の書籍をプレゼント頂きました。アレンジしていただいた翻訳者の玉川さん、オライリー・ジャパン様ありがとうございます。 「H」本当たった皆様、おめでとうございました。 それでは、以下 第2回テクノロジーカンファレンスの開催ログとなります。 ※ 登壇者の皆様と。左から 田籠氏、井上氏、中村氏、濱野氏、沈 氏、伊勢です。 「HTML5 Animation in Mobile Web Games」(沈 相旻 氏 NHN Korea、 Mobile Ajax チーム) 「日々進化するHadoopの『今
2年ほど前、私の仕事場に医療会社の社長が血相を変えて駆け込んできました。かつて私がシステムを設計したことがある会社の社長でした。すぐさま現状のヒアリングと現地調査が行われ、問題を発見しようと直ちにデータ分析が行われることになりました。業務上の横領や不正経理の疑いがあったためです。私がやった分析はシステムから作為的なデータ入力のパターンを見つけることでした。やり方には少々コツがありますが1週間もかからずに結果は得られました。横領の証拠こそありませんでしたが、請求額と支払先に一定のパターンが見つけられたので、従業員の中で組織的に不正が行われていて、一部の社員らによる経費の水増し請求が常習化していたことがわかりました。まったくひどい話ですが過去数年間には会計監査が何度も行われているというのに何もわかっていなかったのです。こうなる前に早期の対処ができたかもしれない機会が何度もあったのに。その後、こ
個人的には割と大変だったので、その辺をまとめておきます。 ニュースリリースはこちら。 http://www.nautilus-technologies.com/topics/20130409.html 要するに本部系バックエンド基幹システムの「一式」のクラウド移行です。完全なミッションクリティカルシステムで、止まった段階で業務に確実に影響が出ます。 システムの機能概要 1.売上の確定処理と債権管理 POSデータの直結です。売上確定処理を行います。同時に債権管理も行い、F/Bからの入金データをそのままつなぎ込み、入金処理・債権の消し込み処理を実行します。マッチングは自動処理できるものは処理を行い、ヒューリスティックなものはユーザー判断に従います。 2.仕入・費用の計上と確定処理、および支払いデータの作成 費用・在庫の計上確定処理です。当時に支払データの確定処理を行います。EDI(BMS)との
1979年生れ。2005年よりISP、SIer(NTTデータ先端技術株式会社)2社での勤務を経験後、2010年8月株式会社ライブドア入社(2012年1月NHN Japan株式会社に経営統合後、2013年4月にLINE株式会社へ社名変更)。現在に至るまでライブドアの各サービスにおける稼動状況の把握と可視化などを中心に、サービスをまたいだ観点でのツール整備などを行う。 今回、株式会社ノーチラス・テクノロジーズの神林氏よりご紹介を頂きましたが、どの様な繋がりでしょうか? もともと、現在のLINE株式会社に入社する前からGoogle App Engineを趣味でいじっていた時期があり、その関係のコミュニティなどで、「クラウド」「分散処理」の話があり、Hadoop系の方と勉強会(飲み会含め)で知り合いました。更に現在の業務になってHadoopを集計などで利用することになり、神林さんもノーチラス・テク
少し前にログの話を書いた http://d.hatena.ne.jp/naoya/20130219/1361262854 ときに、Treasure Data については後日にもう少し詳細に書くと言ったので書くとしよう。 近頃 Treasure Data (以下、時折 TD) という名前をちらほら聞いたことがある人は多いのではないかと思います。「ビッグデータのクラウドサービスである」とか「日本人が創業したシリコンバレーのベンチャー」、あるいは Yahoo! 創業者の Jerry Yang が投資したとか、Fluentd と何か関係があるといった文脈などなど。 けど、具体的に Treasure Data がどういうサービスで、どういう機能を持っていて、どんな場面で利用されるものなのかはまだあまり良く知られていないかもしれない・・・ようにも見える。今日はその辺から少し紹介していこうかなと思う。
Fluentd CollectorからHDFSに書き込むのに fluent-plugin-webhdfs を利用していますが、 DataNodeが1台変死した際に色々おかしくなったので書き留めておきます。 原因特定と解決方法の確立はできていません!あしからず。 直接の原因はSLAVEサーバ(DataNode)が中途半端に落ちたこと 1台のSLAVEサーバに異常が発生したことが直接の原因であり、状態としては SLAVEサーバがKernel Panic!! ホストへのPingは通る 各種デーモンへのTCP接続は確立できる 各種デーモンは一切お返事をしてくれない 試したのがDataNodeでないのが心苦しいですが、復旧前に確認できたのはSSH接続で、 ssh -p22 host は無応答で、telnet host 22 はリクエスト待ち状態になる半死状態でした。 この状態が、Fluentdまたは
国立情報学研究所は、情報系・コンピュータサイエンスの研究者を中心とした文部科学省系の研究所です。そのほかに、大学や国の研究機関のネットワークも扱っており、環境系のネットワークも管理しています。 私自身は、データベースというより、データベースを実行する分散システムといわれているもののインフラが専門ですので、本日はデータベースというより、データベースの外側からこれからどういう技術が起きて、それがデータベースにどう影響するのかという話をさせていただきます。 本日のセミナーのサブタイトルに「ビッグデータ」とありますが、ビッグデータの話になると、必ずデータ量が増えているという話になります。例えば、2020年になるとデータ量は2011年の50倍になります。しかし、皆様の関心事は、世の中のデータが増えるか増えないかということより、皆様の企業やお客様のデータがどれだけ増えていくのか、そのデータがどのように
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く