Hadoop Streamingでアイドルツイート分析
Fluentd+ElasticSearch+Kibanaでアイドルデータ分析基盤を作ってみたの回で、FluentdとTwitter Streaming APIを使ってS3にツイートデータを保存したので、このデータをHadoopを使って解析してみます。 今回はMeCabを使って形態素解析してワードカウントを取るような教科書的なMapReduceを試してみました。Hadoop Streamingを使ってPythonでMapper、Reducerを書いていきます。 環境 OS: Mac OS X(El Capitan) Python: 2.7.11 Hadoop: 2.7.1 Hadoopのインストール&設定 以下のURLを参考にインストール&設定すればOK。 分散処理に入門してみた（Hadoop + Spark） Macでhadoopをちょっとだけ動かしてみる – Qiita Mac OS X
レポーティング、モニタリング、監視で使うストレージは何が良いんだろう - wyukawa's diary
題記のようなことを考えていて、レポーティング、モニタリング、監視で使うストレージは全部統一されているほうが当然運用が楽だと思うのですが、現状だと統一できなくて用途ごとに分けてHadoop, Prometheus, Elasticsearchに格納するというのが僕の今のところの見解です。 僕は日頃の仕事はログ分析基盤を構築、運用をしつつデータ加工バッチを書いたりしています。 各サービスのPV, UUといったメトリクスを日々レポーティングするのであればアクセスログ、アプリケーションログ、各サービスのマスターデータ（例：ユーザ情報、商品マスタ）などをHadoopにぶっ込んでHiveでdailyで集計すればことたります。 Hadoopの良いところはSchema on readでとりあえずデータをぶっ込んでおいて後で解析できるところです。しかも容量やCPUパワーが足りなくなったら台数ふやぜば簡単にス
Hadoop＋Embulk＋Kibanaのデータ集計基盤によるデータ可視化と集計データを活用したキーワードサジェストの仕組み
連載目次 リクルートの全社検索基盤「Qass」の事例を基に、大規模BtoCサービスに求められる検索基盤はどう構築されるものなのか、どんな技術が採用されているのか、運用はどうなっているのかなどについて解説する本連載。 初回の「リクルート全社検索基盤のアーキテクチャ、採用技術、開発体制はどうなっているのか」では全体的なアーキテクチャ、採用技術、開発体制について紹介しました。 検索システムを構築する際に、最も重要なのは、前回の「ElasticsearchとKuromojiを使った形態素解析とN-Gramによる検索の適合率と再現率の向上」でも紹介した、検索品質の向上です。Qassでは、いろいろなログを組み合わせて分析したり、ランキングデータに活用したりと、ログデータはシステムの中核となっています。 第3回の今回はQassの検索基盤を支えるデータ集計基盤と、それによるデータ可視化、集計したデータを生
リクルート全社検索基盤のアーキテクチャ、採用技術、開発体制はどうなっているのか
リクルート全社検索基盤のアーキテクチャ、採用技術、開発体制はどうなっているのか：Elasticsearch＋Hadoopベースの大規模検索基盤大解剖（1）（1/2 ページ） リクルートの事例を基に、大規模BtoCサービスに求められる検索基盤はどう構築されるものなのか、どんな技術が採用されているのか、運用はどうなっているのかなどについて解説する連載。初回は全体的なアーキテクチャ、採用技術、開発体制について。 連載目次 大規模BtoCサービスで求められる検索基盤は、どうあるべきなのか カスタマー（消費者）が求めるものが日々変わっていく現在において、BtoCの検索基盤はどうあるべきなのでしょうか。 例えば、リクルートで使われている検索基盤の「Qass（Query analyze search system）」は単に全文検索機能を提供するのではなく、以下を軸としています。 サービスごとに最適化され
LINE DEVELOPER DAY 2016 開催のお知らせ « LINE Engineers' Blog
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog saegusa2017-04-16Yoshihiro was a network engineer at LINE, responsible for all levels of LINE's infrastructure. Since being named Infra Platform Department manager, he is finding ways to apply LINE's technology and business goals to the platform. こんにちは。LINEでネットワークやデータセンターを担当している三枝です。2017年1月にJANOG39で登壇する機会を頂きましたので、今回
elasticsearch-hadoopをもうちょい調べて遅い理由が少しわかった - Yamakatu as a Service
■これまでの話 第4回Elasticsearch勉強会でElasticsearch-hadoopについて発表させて頂きましたが、その際、評価としてHiveの実行速度をHDFSをストレージとして利用した場合と比較してお見せしました。 ここらへんです。 elasticsearch-hadoopをつかってごにょごにょしてみる from Katsushi Yamashita で、ちょっといくらなんでも遅すぎるな、と思って調べていたらわかったことがあったのでメモ。 ■わかったこと 結論から言うと、elasticsearch-hadoopはRead時はPrimary Shardの数しかMapタスクを生成しない。 これはelasticsearch-hadoopのここら辺のソースを読んでもわかります。 ・EsInputFormat.java getSplitsメソッド 1 2 3 4 5 6 7 8 9
elasticsearch-hadoopをつかってごにょごにょしてみる
8. What’s elasticsearch-‐hadoop • HadoopからElas-csearchをストレージとして利用する • 何ができるの？ 1. MapReduce ➡ Elas-csearch にread/write 2. Hive ➡ Elas-csearch にread/write 3. Pig ➡ Elas-csearch にread/write • 何が幸せ？たとえば、 • SQLが書ける程度の非エンジニアでもHiveでElas-csearchの データでごにょごにょできる • Elas-csearchの検索結果をMapReduceでごにょごにょしやす い • 既存資産(ex. MapReduceで実装したライブラリ)の流用 • とかとか 10. MapReduceでread(旧API ver.) • Elas-csearchの接続先やクエ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
