バッチ処理、ジョブ管理について書いてみる - wyukawa's diary
僕はHive, Pythonでバッチ処理を書いてAzkabanでジョブ管理するシステムを構築、運用した経験が2年ほどあるので今日はバッチ処理、ジョブ管理について書いてみようと思います。 僕の経験上Hadoop特有の部分、例えばテスト環境が作りづらいとかバッチサーバーはジョブをsubmitするだけなので負荷はそんなにかからないとか、はあるけれど割と汎用的なのではないかと思います。そもそもバッチ処理、ジョブ管理について書かれたものはほとんど見た事がないので参考になれば嬉しいし、こういう良い方法もあるよ！とかあれば是非ブログ等に書いてほしいと思っております。 最初に言っておくとバッチ処理、ジョブ管理において重要なのは障害時のリカバリのしやすさです。正常時はまあいいでしょ。 なので例えば引数に日付を持てないようなバッチ書いたら辛いですし、LL言語で書く方がコンパイル、パッケージングとか楽です。CP
スマートニュースの世界進出を支えるログ解析基盤 #jawsdays #tech
スマートニュースは昨年の 10/1 に米国版をローンチするにあたり、ログ解析基盤のリニューアルを行いました。日本に加えて米国やその他の国が入ってくることにより、単なるユーザ数の増加に加え、OS x 国 x タイムゾーン x 多種多様なメトリクスのような集計軸が増えることで、ログの前処理、集計、可視化に様々な工夫が必要になってきます。本セッションでは、会社の成長に応じたログ集計基盤の転換を振り返りながら、世界進出にあたってどのようなことを考え、どのようにログ集計基盤をリニューアルしていったか、および、そのログ解析基盤を支える Amazon EMR, Hive, Presto, Azkaban, Shib, Chartio などのツールについてお話します。
Amazon Redshiftの利点
Amazon Redshiftについて色々と聞く機会があった。その時聞いたことメモ。 Amazon EMRとAmazon Redshiftの違い まずは、よく比較されることになるEMRとRedshiftの違いから。 Amazon EMR HadoopクラスタとHiveを簡単に使うためのサービス。自由な台数のクラスタを自由なタイミングで起動したり破棄したりできる。 Hadoopクラスタ運用(初期設定、チューニング、等)の手間が完全に不要なのはものすごいメリット。 クエリの速さは、ログの量によりますが、数分～数十分くらいかかる。(ログの行数が数百万～数千万ある時) 利用者から見た基本的な用途・できることはEMRとほとんど同じ。ただ、仕組みが全く違う。 RedshiftはRDBのような(Postgresベースらしい)テーブル設計を持つ。例えば、VARCHAR(255)みたいなカラムを持つ。EMR
5 Tips for efficient Hive queries with Hive Query Language
Hive on Hadoop makes data processing so straightforward and scalable that we can easily forget to optimize our Hive queries. Well-designed tables and queries can greatly improve your query speed and reduce processing costs. This article includes five tips, which are valuable for ad-hoc queries, to save time, as much as for regular ETL (Extract, Transform, Load) workloads, to save money. The three
Review: Instant Apache Hive Essentials How-to - たごもりすメモ
突然英語でメールがやってきてレビューしてくれないかと頼まれ、面白そうだから引き受けて読んでみた。日本語でしかレビュー記事書かないけど大丈夫？ と確認したら大丈夫だといって電子書籍データをもらいました。すごいことやってる会社があるなあ。イギリスの(電子書籍専門の？)出版社みたいだけど。 なおフォーマットは pdf, epub, mobi のどれでもダウンロードできる。すごい。日本はなぜこうじゃないの。 で、読んだ。76ページの短い本。 ざっくり言うと 英語だけどすごく簡単な英語で書かれてて、きわめて簡単に読める。manとか普通に英語で読んでる人なら楽勝だと思う。読めば普通に導入からいろんなクエリを発行するところまで行ける。リファレンスには使えない*1けど、それはまあ、wikiを見ればいいんじゃないですかね。 各トピックについてはかなり短いが、必ず前提になるテーブルの準備をするためのクエリ*2
ログ解析環境についてなんとなく書いてみる - wyukawa's diary
ふとログ解析環境についてなんとなく書いてみたくなったので書いてみる。 データサイエンティストブームなるものがあると思いますが、データサイエンティストって言ったときに、Hadoop/Hiveあたりを使ってデータをきれいに整理して分析しやすいように加工するデータエンジニア（某氏が命名）と加工されたデータを使って分析するアナリストの２種類いると思うんですよね。両方できればもちろん良いんですけどさすがにそれは難しいので分業が必要です。ただアナリストもHadoopの運用ができる必要性は低いと思いますがSQLは書けた方が良いとは思います。 ちなみに僕は仕事でログ解析周りを担当しており現状はアナリストではなくデータエンジニアですね。 KPIというか統計値は毎日レポーティングする仕組みは既にあるのですが新しい統計値を知りたいという要望もちょいちょいあります。 最近は自社サービスも安定して運用されているので
SQLライクにHadoop Hiveを使い倒す!
パーティションを利用する 今回は少し凝ったテーブルを定義をしてみましょう。 郵便番号データは毎月更新されるので、テーブル指定時にバージョンも指定できるようにします。このような場合、Hiveではパーティションを使います。 以下に郵便番号を保存するテーブル「zip」を定義しますが、日付型DATEのパーティションverを設定するようにします。 hive> CREATE TABLE zip (zip STRING, pref INT, city STRING, town STRING) > PARTITIONED BY (ver DATE) > ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' > LINES TERMINATED BY '\n'; OK Time taken: 0.128 seconds
"Programming Hive" 輪読会 #1
掲題の会を社内で実施しました。 幸い（？！）なことに、メンバー中で僕が一番Hiveについて詳しくない、という状況で輪読会が実施できたので、「皆に教える」というより、「自分の拙い部分を指摘してもらい、僕が勉強する」という、僕としては理想的な会になりました。 使用した資料は以下です。 "Programming Hive" Reading #1 from moai kids 資料としてはかなり説明不足な点が多いので、会の中で教えてもらった事も含めて補足します。 ◯P8 Bucketing Table "CLUSTERD BY" に指定したカラムがBucket数分一様に分散されるのであれば動作するが、たとえば特定のBucketにデータが偏るような状況では上手く動作しないケースがある。 Bucketing Tableの作成時には、基本的にはBucket数分Reducerが動作します。 たとえばBuc
第2回NHNテクノロジーカンファレンスでしゃべってきた - たごもりすメモ
勤務先が主催でNHNテクノロジーカンファレンスという技術者向けイベントをやってるんだけど、その登壇者として社外の誰かから推薦されたらしいので(何故……)、ひとセッションしゃべってきた。なお「HBase at LINE」の発表は「HBaseについて誰かいない？」と主催の伊勢さんに聞かれたのに自分が推薦しました。みんなありがたがるといいよ。 他の人の話も、懇親会でのあれやこれやも大変楽しかった。HBaseなー、火山かー、みたいな。そのうち techblog にまとめエントリが上がるんじゃないでしょうか。それまでこっちでも見ると当日の状況が多少なりわかるかもしれません。 第2回NHNテクノロジーカンファレンス #nhntech まとめ - Togetterまとめ で、自分がしゃべったときのスライドはこちら。(slideshareのembed用タグを埋めてもはてなダイアリーに弾かれてしまう…… 対
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hadoop＋Hive検証環境を構築してみる