データ分析部が開発・運用するバッチ アプリケーション事情 - Gunosyデータ分析ブログ
はじめに こんにちは、データ分析部の森本です。 この記事ではGunosyデータ分析部がどのような視点に基づいてバッチアプリケーション（以下、バッチ）を開発・運用しているかしているのかを紹介します。 クライアントアプリ開発やAPI開発と比較してバッチ開発のノウハウなどをまとめたWeb記事の数は少なく感じます。 また、言語に関わらずWebフレームワークの数に対して、バッチフレームワークの数も少数です。 このような点を踏まえると一般的には難易度の高くない（ノウハウを必要としない、フレームワークに頼る必要のない）、もしくはニーズがあまりないなどの印象があるのかもしれません。 一方で我々は日々バッチ開発を行い、数多くの地雷を踏んできました。 これらの経験を踏まえてどのような点に気をつけているのかについて共有します。 理想的には多くの方の経験を共有して、建設的な議論に発展するとうれしいです。 はじめに
バッチ処理の通知・アラート管理 - CARTA TECH BLOG
こんにちは、nekoyaです。 システムを日々運用していく中で、その処理結果の記録や異常検知の仕組みは地味ながらも大切な存在です。 各種監視ツールからの通知や、ブラウザから利用可能なWebインタフェースなど、その形態も様々です。 今回はその中から、バッチ処理の結果通知について、我々のチームが実践している方式をご紹介します。 loggerを通して記録する まず前提として、通知する内容はプログラマ自身が出力することが基本になります。 自分はここ数年はPythonをメインに使っていて、標準のloggingモジュールを通して import logging logger = logging.getLogger(__name__) logger.info('hello!') のようにログを吐いておくと、スクリプトの終了時にそれまで出力したログがいい感じに集約されて通知されるようにしています。 ログレベ
続・Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのがそれ単体で勉強するのが難しく勉強しようとすると何に手を付けるべきかさっぱりわからないということは、先日のブログで述べたとおり。 自分が経験の中で得てきた知見は正しいのかどうか、世間の人に見てもらいたかったというのが書いた動機。 そして、新たな視点や指摘をゲットしてより不測の事態を考慮できている最高なバッチを作りたいという目的があったわけだ。 で、いろいろな意見をもらったのだけどその中で特に辛いと感じたのはこれ。 基幹システムにおけるバッチ処理みたいなものに関する知見については、カジュアルに学ぶ方法はありません。それを体系化した知識として整理した上で、実装できる組織があるんなら、それでメシが食えるんじゃないですかね。— 太一 (@ryushi) 2016, 2月 18 読んでいると 「俺達は障害でつらい思いをしてるし当然先人達も障害でつらい思いをしているはずだ。 なのに、
Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。 特に経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基本的なノウハウを知らないままに書いてしまうことが多い。 バッチ処理というのは実態を整理すると「何らかのトリガーを期に起動し、データをロード・加工・変換・集計してから、出力する」という事になる。 まぁ、INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。 システムの利用者(人に限らない)のアクションとは直接関係ない処理であったり、利用者のアクションをトリガーとしていても、即時にレスポンスがいらないor返せない場合に バッチ処理を選択する事が多い。 実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。 利用者の操作に対して対話的・同期的な処理はオンライ
HiveとImpalaにワークフロースケジューラーを入れてみた（前編） - CyberZ公式エンジニアブログ
こんにちは、CyberZのエンジニアの遠藤です。 もうすっかり秋めいてきたので、温泉に行きたい今日このごろです。 さて、今回は社内にあるデータ分析用基盤のHadoop環境にワークフロースケジューラーを導入したので、前編と後編に分けてCyberZでの導入事例を書きたいと思います。 弊社ではさまざまなデータの分析やレポートデータの集計にHadoopを利用しています。 主に、HiveとImpalaを用いており、日次や週次、月次で集計バッチを回していました。 これまで、特にワークフロースケジューラーは導入しておらず、Jenkinsを利用してバッチの管理や実行を制御していました。 しかし、Jenkinsではジョブ間の依存関係の制御が難しく、集計バッチを増やす際の追加が若干面倒であったり、障害等で集計が失敗したときのリトライ制御が難しいなど、運用上の問題や負担がいくつかありました。 2015年の夏頃に
リクルートライフスタイルのビッグデータ
リクルートライフスタイルのビッグデータ 300本のバッチが流れ、300人の分析者がクエリを投げるビッグデータ基盤 こんにちは、データ基盤チームの平本です。 我々、データ基盤チームのミッションは2つあります。 リクルートライフスタイル各サービスの分析担当者に対して、そのサービス、もしくは複数のサービスにまたがったユーザの行動を分析できる環境を提供する 各サービスのデータを使ったOne to One、Cross-use施策のバッチを開発・運用し、各サービスに価値を提供する 今回は第1回目ということで、我々が構築・運用しているビッグデータ環境の全体像について紹介します。 基盤の全体像 我々の基盤は、リクルートライフスタイル全サービスのデータを収集しています。 収集したデータを基に、分析に使うマートやレコメンドに使うデータを作成しており、レコメンドのデータをサービス側のDBへエクスポートしたり、レ
巨大なバッチを分割して構成する 〜SQLバッチフレームワークBricolage〜 - クックパッド開発者ブログ
トレンド調査ラボの青木峰郎（id:mineroaoki）です。 好きなRubyのメソッドは10年前からString#slice(re, nth)ですが、 最近はRubyよりCoffeeScriptとSQLのほうが書く量が多くて悩んでいます。 今日はわたしが開発している「たべみる」の背後で働いている 巨大バッチの構成について話したいと思います。 たべみるのバッチは約3000行のSQLで構成されており、 処理時間が1日で4時間程度かかる、そこそこの規模のプログラムです。 このバッチ処理プログラムをBricolage（ブリコラージュ）というフレームワークで構造化する手法について説明します。 「たべみる」とは まず最初に、「たべみる」がどういうものなのかごく簡単にお話ししておきましょう。 「たべみる」は企業のみに提供しているB2Bの分析サービスで、 クックパッドのレシピ検索の分析をすることができま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
