形態素解析を行うだけのバッチをつくる - クックパッド開発者ブログ
研究開発部の原島です。今日は表題の渋いバッチをつくった話をします。 あっちでも形態素解析、こっちでも形態素解析 みなさん、形態素解析してますか？してますよね？クックパッドでもさまざまなプロジェクトで形態素解析をしています。 いや、むしろ、しすぎです。プロジェクト A でレシピを解析し、プロジェクト B でもレシピを解析し、プロジェクト C でもレシピを解析し、... といった具合です。ちなみに、形態素解析（の結果）が必要なプロジェクトとしてはレシピの分類やレコメンド、各種分散表現（e.g., word2vec）や BERT の学習などがあります。 もちろん、最終的に得たい解析結果が違うのであれば問題ありません。しかし、私が見たかぎり、ほとんどの場合は同じ（もしくは、同じにできそう）でした。であれば、 解析器をインストール（→ Dockerfile を試行錯誤） 解析対象を取得（→ SQL
転職会議から冪等でないバッチ処理を根絶した話 - LIVESENSE ENGINEER BLOG
こんにちは、かたいなかです。 最近転職会議のバッチ処理をすべて冪等にし、処理失敗時に気軽に再実行できるようにすることで運用性を向上させました。 今回の記事ではその取り組みを紹介します。 再実行すると重複送信につながるメール送信バッチ もともと、転職会議では一部のバッチ処理を除いてほとんどのバッチ処理が冪等に作られていました。しかし、残りの冪等ではないバッチ処理では、失敗するたびに毎回アドホックな対応をする必要があり運用性に課題を抱えていました 残っていたもので一番大きな問題を抱えていたのがメール送信バッチです。これは、以下の図のようなアーキテクチャで動いており、ワーカーにメールを送信するように指示するメッセージをSQSにキューイングする処理を行うものです。 このメール送信バッチのキューイング処理が途中で失敗した際に、雑に再実行してしまうと同一のユーザに重複してメールが送信されてしまう事にな
Pythonでいい感じにバッチを作ってみる - prefectをはじめよう - JX通信社エンジニアブログ
JX通信社シニア・エンジニアで, プロダクトチームのデータ活用とデータサイエンスのあれこれ頑張ってるマン, @shinyorke（しんよーく）です. 最近ハマってるかつ毎朝の日課は「リングフィットアドベンチャー*1で汗を流してからの朝食」です. 35日連続続いています. 話は遡ること今年の7月末になりますが, JX通信社のデータ基盤の紹介&「ETLとかバッチってどのFW/ライブラリ使えばいいのさ🤔」というクエスチョンに応えるため, このようなエントリーを公開しました. tech.jxpress.net このエントリー, 多くの方から反響をいただき執筆してよかったです, 読んでくださった方ありがとうございます！ まだお読みでない方はこのエントリーを読み進める前に流して読んでもらえると良いかも知れません. 上記のエントリーの最後で, 次はprefect編で会いましょう. という挨拶で締めさせ
1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
メルペイにおける大規模バッチ処理 | メルカリエンジニアリング
この記事は MERPAY TECH OPENNESS MONTH の 13日目の記事です。 こんにちは、メルペイ ソフトウェアエンジニアの laughngman7743 です。 メルペイではマイクロサービスにおけるデータストアのデータや、アプリケーションのログを有効活用できるような基盤づくりをデータプラットフォームチームとして行っています。 データプラットフォームではラムダアーキテクチャに基づき、スピードレイヤとして Cloud PubSub と Cloud Dataflow を利用した仕組みに加え、バッチレイヤとして Cloud Composer と Cloud Dataflow を利用した仕組みを構築しています。 この記事ではバッチレイヤのアーキテクチャについてご紹介します。 スピードレイヤのアーキテクチャについては 「GCPでStreamなデータパイプライン始めました」 を参照くださ
バッチプログラムの運用と監視について検討しよう | メルカリエンジニアリング
こんにちは。メルペイでバックエンドソフトウェアエンジニアをしている id:koemu です。 バッチプログラムのお話、今回は運用・監視についてお話したいと思います。当社はすべての業務が24時間行われていますので、システムがオンラインのときに動作するバッチプログラムについてのみ議論します。 過去の記事はこちらにあります。 運用に備えて バッチプログラムの運用について、「プリモーテム」「実行管理」そして「ログ管理」の3点について述べていきます。 プリモーテム ポストモーテムという言葉を聞いたことがある方はいらっしゃるかと思います。ポストモーテムとは、GoogleのSRE本の15章*1によれば、障害などの失敗を振り返り、今後に活かすプロセスの総称と捉えることができます。 さて、プリモーテム(プリモータム)とは何でしょうか。この言葉は、私が最近読んだThe Manager’s Path*2*3で使
バッチ処理の採用と設計を考えてみよう | メルカリエンジニアリング
こんにちは。メルペイで、決済・振込申請のバックエンドソフトウェアエンジニアをしている id:koemu です。 今日は、バッチ処理を行う理由について、考察を深めて設計に活かしていく話をしたいと思います。 はじめに バッチ処理とは、ある決まったタイミングで1つのプログラムが複数のデータを 一括処理 することを指します。この反対の言葉として、オンライン処理があります。オンライン処理とは、お客様の操作を初めとしたイベントをもとに 逐次処理 されるものです。OLTP(Online Transaction Processing)とも言います。 本エントリでは、バッチ処理を採用するにあたり、どういったユースケースが適切なのかを整理して、今後のソフトウェアの設計の指針にできることを目指しています。今回は、「バッチ処理を採用するとき」と「バッチ処理の設計」の2つについて取り上げます。 バッチ処理を採用する
データ分析部が開発・運用するバッチ アプリケーション事情 - Gunosyデータ分析ブログ
はじめに こんにちは、データ分析部の森本です。 この記事ではGunosyデータ分析部がどのような視点に基づいてバッチアプリケーション（以下、バッチ）を開発・運用しているかしているのかを紹介します。 クライアントアプリ開発やAPI開発と比較してバッチ開発のノウハウなどをまとめたWeb記事の数は少なく感じます。 また、言語に関わらずWebフレームワークの数に対して、バッチフレームワークの数も少数です。 このような点を踏まえると一般的には難易度の高くない（ノウハウを必要としない、フレームワークに頼る必要のない）、もしくはニーズがあまりないなどの印象があるのかもしれません。 一方で我々は日々バッチ開発を行い、数多くの地雷を踏んできました。 これらの経験を踏まえてどのような点に気をつけているのかについて共有します。 理想的には多くの方の経験を共有して、建設的な議論に発展するとうれしいです。 はじめに
バッチコマンドで定型処理を行う
コマンドを自動実行させるバッチ処理機能 前回まではコマンドプロンプトの基本と代表的なコマンドについて紹介してきた。GUIでは面倒な処理も、コマンドプロンプトを利用すると、簡単に実行できる場合があることがお分かりいただけただろう。 ただこれまでは、コマンド入力を受け付ける、コマンドプロンプトで、キーボードから1つのコマンドを入力して実行していた。この方法では、複雑なパラメーター指定を毎回手入力しなければならないし、一連のコマンドを実行する場合も、手作業で1つずつ実行する必要がある。こんなときには、毎回手入力するのではなく、一連のコマンドをファイルに記述しておき、それをまとめて実行できる「バッチコマンド」（単に「バッチ」とも言われる）が利用できる。 バッチとは、簡単に言えばコマンドラインで利用するコマンドを1つのファイルにまとめて、簡単に実行できるようにしたものだ。人手を介さずに、コンピュータ
Pythonでコマンドを実行しシェルスクリプトのように使う - cBlog
一部修正しました（取り消し線部） 一連のコマンドを走らせたかったのですが、私はシェルスクリプトの文法が苦手です。そこで、Python 3でシェルのコマンドを実行させる方法を調べてみました。書きやすいし、より高級なことができると思います。 subprocessモジュール 他にも何かあるみたいですが、現在はsubprocessモジュールのrun()関数を用いるのが推奨されているようです。Python 3.5で追加されたほやほやの関数です。 以下のようにすると$ ls -l /usr/binを実行できます。 cmd = ['ls', '-l', '/usr/bin'] subprocess.run(cmd) 結果は標準出力に出力されます。結果をプログラム内で使いたい場合は引数にstdout=subprocess.PIPEを追加してください。run()の返り値はCompletedProcessクラ
イマドキのジョブスケジューラについて考える - メドピア開発者ブログ
こんにちは。Ruby化をすすめるメドピアをお手伝いしている@willnetといいます。 メドピアではPHPからRubyに移行するにあたり、単純に言語を置き換えるだけではなく、言語以外の仕組みについても適宜見直しを行っています。今回はそのうちジョブスケジューラを見直した件について書いていきます。 言語を置き換えた話はこちらを参考にしてください。 レガシーな独自フレームワークから脱却してRailsへ徐々に移行している話 - メドピア開発者ブログ そもそもジョブスケジューラってなに 「毎日1時になったら前日のアクセスログを集計して統計データとしてまとめる」などといった定期的に実行するジョブを登録するためのものです。 ウェブサービスを作るときのジョブスケジューラといったらやっぱりcronですよね。メドピアでもこれまでcronを活用していました。しかしサービスが小さいうちはcronでもそれほど問題な
Job管理をAirflowからKuroko2に乗り換えたら幸せになった - hatappi.blog
Speeeアドベントカレンダー 2日目の記事です。 前日の記事は@hiragramのTravisCIでiOSの依存ライブラリの更新を自動化する - TECHNICA Speee engineer blog エンジニアの@hatappiです。 前年度のアドベントカレンダーでこんな記事書いてました。 hatappi.hatenablog.com 要するに定期処理をうまいこと実現したい！そのためにAirflowを使ってはどうかっていう記事です ※ Airflowはデータパイプラインのスケジュールとかモニタリングできるツールです。簡単にいうとジョブ管理ができるシステム Airflowを使うと 定期実行したい 成功、失敗において通知したい 画面上から再実行したい logを画面からおいたい といった定期処理でやりたいことを実現できるので、あれから実際に会社でも導入して 現在稼働しておりディレクターの方
続・Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのがそれ単体で勉強するのが難しく勉強しようとすると何に手を付けるべきかさっぱりわからないということは、先日のブログで述べたとおり。 自分が経験の中で得てきた知見は正しいのかどうか、世間の人に見てもらいたかったというのが書いた動機。 そして、新たな視点や指摘をゲットしてより不測の事態を考慮できている最高なバッチを作りたいという目的があったわけだ。 で、いろいろな意見をもらったのだけどその中で特に辛いと感じたのはこれ。 基幹システムにおけるバッチ処理みたいなものに関する知見については、カジュアルに学ぶ方法はありません。それを体系化した知識として整理した上で、実装できる組織があるんなら、それでメシが食えるんじゃないですかね。— 太一 (@ryushi) 2016, 2月 18 読んでいると 「俺達は障害でつらい思いをしてるし当然先人達も障害でつらい思いをしているはずだ。 なのに、
Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。 特に経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基本的なノウハウを知らないままに書いてしまうことが多い。 バッチ処理というのは実態を整理すると「何らかのトリガーを期に起動し、データをロード・加工・変換・集計してから、出力する」という事になる。 まぁ、INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。 システムの利用者(人に限らない)のアクションとは直接関係ない処理であったり、利用者のアクションをトリガーとしていても、即時にレスポンスがいらないor返せない場合に バッチ処理を選択する事が多い。 実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。 利用者の操作に対して対話的・同期的な処理はオンライ
A-AUTO 50 - 無料で使えるフリーのジョブ管理システム
イニシャルコスト・ゼロ、ランニングコスト・ゼロのジョブ管理ツールA-AUTO 50。OSSではなく商用ソフトウェアA-AUTOのキャパシティを小さくしたことで、”ずーっと無料”でご利用いただけます。中小企業の方など小規模システムの自動化・安定運用にご活用ください！
cronの代替になりそうなジョブ管理ツールのまとめ - Qiita
たまに検討するけど、よく忘れるのでまとめておく。ごく個人的な感想としては、Rundeck, Azkabanあたりで始めてみるのがいいかもと思う。 要件 重複実行の防止 ジョブの実行結果、かかった時間、ログ出力などが見れる 失敗時の通知 候補 OSS系 Rundeck http://rundeck.org/ Java Runtimeで動く RUNDECK PROという有料サービスもある http://simplifyops.com/ 参考: http://heartbeats.jp/hbblog/2015/01/rundeck.html Oozie http://oozie.apache.org/ Workflow Scheduler for Hadoop Java http://oozie.apache.org/docs/4.1.0/DG_Overview.html Webコンソールもある
リアルタイムとバッチの違い - kuenishi's blog
昨日、分散DB本読書会のあとに品川のラーメン屋でリアルタイムとは何ぞや〜みたいな話になった。自分の思いついたポエムをここに書いておこう。現場の問題とはあまり関係がない。 Stream Data Processing: A Quality of Service Perspective (Advances in Database Systems)という本によれば、DSMS (Data Steram Management System) とDBMS (Database Management System)の違いは、クエリを発行するデータ集合の性質にある。つまり、DBMSは今ある有限のデータに対して操作を行うための仕組みで、DSMSはこれからやってくる無限のデータに対して操作を行うための仕組みと定義されていた。このDSMSというやつは、古式ゆかしいストリーム処理システムのことで、まあいわゆるCEP
はじめてのjBatch - CLOVER🍀
このあたりのエントリを見て、ちょっとやってみようかなぁと思いまして。 JSR352-Batch Applicationを試してみた(Batchlet編) http://siosio.hatenablog.com/entry/2015/06/06/011830 JSR352-Batch Applicationを試してみた(BatchletでDBアクセス-JPA編) http://siosio.hatenablog.com/entry/2015/06/07/151425 その他、ちょっと目を通したのはこのあたり。 Jbatch実践入門 #jdt2015 http://www.slideshare.net/agetsuma/jbatch-jdt2015 The Java EE 7 TutorialのjBatchの章をテキトーに訳した http://kagamihoge.hatenablog.co
初めての運用管理者が知っておきたい監視・ジョブ管理向けOSS構成例4つの比較まとめ
初めての運用管理者が知っておきたい監視・ジョブ管理向けOSS構成例4つの比較まとめ：Zabbix＋JobSchedulerで効果的な運用監視とジョブ管理（1/2 ページ） 「監視」と「ジョブ管理」はシステム運用の要といえるもの。オープンソース、商用ともに多様なツールが存在しますが、本連載ではオープンソースソフトウエア（以降、OSS）に焦点を当て、「Zabbix」と「JobScheduler」の活用法を詳しく解説します。監視やジョブ管理の機能を持つツールは種々存在しますが、その中でも特にオープンソースソフトウエア（以降、OSS）のZabbixとJobSchedulerを活用する方法について解説します。 前編となる本稿では、監視とジョブ管理の正しい在り方と、ZabbixやJobSchedulerを用いることによるメリット、TISが開発したOSSであるZabbixとJobScheduler連携ツ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPで100万件バッチ回したら死ねる
