Stream Processing Casual Talks 2 にいってきた & しゃべってきた - たごもりすメモ
開催されたので参加してきた。 ついでにちょっと前に社内でのやりとりで思い付いてそのまま温めてたアイデアがあったので形にしてしゃべってみた。 connpass.com しゃべってきた Perfect Norikra 2nd Season from SATOSHI TAGOMORI 社内でしゃべってたのは、ストリーム処理クエリって結局自分がもってるデータしか参照できなくて、じゃあ3年前のデータとJOINしたかったらクエリを3年走らせつづけないといけないの? 無理じゃね? みたいなあたり。過去データを参照したいケースは(特にビジネス要件のクエリで)普通に存在するいっぽう、現行のストリーム処理エンジンはクエリを開始した時点から受け取ったデータそのものしか参照できない*1 んで、いやよく考えたら過去データからストリーム処理クエリの計算中の状態を再現できれば、クエリ開始時に3年前からのデータをどこかか
Hive Client Webアプリケーション shib をつくった - たごもりすメモ
(2013/04/02追記 see: http://d.hatena.ne.jp/tagomoris/20130402/1364898063 ) まだ完成度がいまいちだからなーと思ってエントリ書いてなかったんだけどLTでしゃべっちゃったので、ちゃんと書いておく。 Hiveにクエリを発行して結果を確認するためのWebアプリケーションを社内用途で作ってるんだけど、普通に他でも使えると思うので公開してあります。 tagomoris/shib · GitHub シブ と読みます。 セットアップ方法はドキュメントを参照のこと。起動してブラウザでアクセスするとこんな画面が出てくる。 使いかたは見ればわかる、と思う。たぶん。クエリは参照専用(SELECTのみ)。 __KEY__ とか __KEY1__ とかがプレースホルダですよってくらいかな。エディタ内でプレースホルダを書くとプレースホルダを置換する値
はじめてのmaven central 公開 - たごもりすメモ
前置き：このエントリはJavaおよびJava周辺の*1開発環境に全く縁の無い人間が、可能な限り依存ソフトウェアを少なく手順をシンプルに保ったままやろうとしたものであり、知識・経験のある人にとっては全く最適な手段でなかろうことをお断りします。 先日のエントリ で書いたとおり woothee 1.0.0 をリリースした。Perl, Ruby, Node.js および PHP などはそれぞれの言語毎のモジュールリポジトリに登録されている。 が、Javaについては自分が Maven Central の勝手がわからず、されてると便利だよなーとは思いつつ放置していた。 が、なんと @making さんからMaven Central登録用の pull requestがきた 。きてしまった。これで最大の問題(xmlを書く)はおおむね解決されてしまったので、覚悟を決めて登録作業をすることにした。 せっかくや
Reverse Proxyがなぜ必要か、勝手に補遺 - たごもりすメモ
「全体のリソース効率を上げましょう」というためのものである。 Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー これは完璧に正しくて、ただ「リソース効率」という概念はあまり具体的な想像が追い付かない人がいそうだなと思ったので、ちょっとだけ補足しようと思った。 Reverse Proxyを入れることでリソース効率の向上を狙うんだけど、それは以下のような複数の場面におけるそれぞれのリソース効率向上を複合的に狙うものだ。 通常時のトラフィック配信におけるCPU・メモリ使用率を最適化する バースト時(過負荷時)のトラフィックをより細かく制御可能とする 障害時におけるダウンタイムおよび総合的な計算・配信能力の低下を極小化する 多数のサーバによる構成全体を増強・入れ替え・移動あるいは削減する際の自由度の向上を狙う 簡単にコンピュータの性能だけで言うと最初の項目だけをリソース効
NATやファイアウォールの向こうへデータをお届けする fluent-plugin-pull_forward を書いた - たごもりすメモ
Fluentdにおけるネットワークごしデータ転送プラグインといえば forward が組み込みであるし、通信路を暗号化したければ secure-forward がある。 しかしこれらFluentdのネットワーク転送プラグインは基本的に全て送信元から送信先に対してプッシュする形になっており、ネットワーク接続も送信元から送信先に対して行うことになっている。このため送信先のFluentdがNAT下にある場合やファイアウォールで保護された場所にある場合、もしくはダイヤルアップ接続……は、まあ今は無いだろうけど、例えば移動するデバイス上にある場合など、こういったときにはうまくデータの転送を行う構成がとれない。 なぜこういう状況、つまりプッシュ型で転送を行うプラグインばかりなのかというと、FluentdのBuffer pluginの仕組みによる。細かく設計上の話をあれこれしてもアレだし面倒くさいので省
RAIDレベルの話: 1+0と6はどっちが安全か？ - たごもりすメモ
仕事でちょっくら12台のHDDを使ったRAIDアレイを組むんだけど、その折にちょうどTwitterで「RAID-1+0にしないとRAID-6とか怖くて使えませんよ！」というウソ八百な内容のWebページのURLを見掛けたので、いいかげんそのような迷信が消え去ってもよかろうと思って書くことにした。 1重ミラー設定のRAID-1+0は安全性においてRAID-6に劣る。ただし、正しく運用されている場合に限る。*1 知っている人はずっと前から知っている事実ではあるんだけど、某巨大SIerなんかでも高い方が安全に決まってる的な残念な脳味噌の持ち主がいっぱいいて「いやあデータの安全性を考えるとRAID-1+0」とか考えもなしにクチにし、そっちの方がディスクがいっぱい売れて嬉しいストレージベンダーもニコニコしながら否定せず売りつけて去っていくといううわなにをす(ry まあそんな感じで。ちなみに正しくない運
CDH4 NameNode HA (QJM)でクラスタ構成 - たごもりすメモ
CDH4と延々格闘してたが、ようやくひととおり設定が終わったのでまとめ。 特にNameNode HA QJM版はドキュメントもけっこうグチャグチャで何をどうすればいいのかの把握が困難だった。また Auto Failover は設定するとマトモに動かなかったので無効にした。そのうち調べてもいいけど、実運用上も特に要らなそうだし、まあいいかな、と。 で、手順と設定のポイントについていくつか。なおNameNode Federationは使ってないので知らん。使うならクラスタ名の指定とかに影響があるはず。 セットアップ順序 基本的にはこのドキュメントを読む。 Redirecting... が、通常のセットアップとの関係やどういう順序で全体を進行すればいいかがいまいちちゃんと書いてなくて不明なところが多い。簡単に概要をまとめると以下のようになる。パッケージ名はyumでのものなので適当に読み替えを。
「Hadoop Hacks」読んだ - たごもりすメモ
「Hadoop Hacks」を著者陣のご高配を得てオライリー・ジャパンから献本いただきました。ありがとうございます。 Hadoop Hacks ―プロフェッショナルが使う実践テクニックposted with amazlet at 12.04.26中野 猛 山下 真一 猿田 浩輔 上新 卓也 小林 隆 オライリージャパン 売り上げランキング: 2139 Amazon.co.jp で詳細を見る で、ざっと読んだ(自分でやってないところは眺めた程度)ので感想をざらっと。 なんというか、さすがにちょっと扱う内容が広過ぎる＆プログラミングを避けられない箇所が多過ぎる感はあって、苦労したんだろうなー、という気がする。読んで「ああこれは役に立つよね」というのがだいぶ少なくてちょっと残念。100行単位でコードを書かないといけない内容をこういう本で「hack」といって紹介するのはやっぱりちょっときびしいなー
Review: Instant Apache Hive Essentials How-to - たごもりすメモ
突然英語でメールがやってきてレビューしてくれないかと頼まれ、面白そうだから引き受けて読んでみた。日本語でしかレビュー記事書かないけど大丈夫？ と確認したら大丈夫だといって電子書籍データをもらいました。すごいことやってる会社があるなあ。イギリスの(電子書籍専門の？)出版社みたいだけど。 なおフォーマットは pdf, epub, mobi のどれでもダウンロードできる。すごい。日本はなぜこうじゃないの。 で、読んだ。76ページの短い本。 ざっくり言うと 英語だけどすごく簡単な英語で書かれてて、きわめて簡単に読める。manとか普通に英語で読んでる人なら楽勝だと思う。読めば普通に導入からいろんなクエリを発行するところまで行ける。リファレンスには使えない*1けど、それはまあ、wikiを見ればいいんじゃないですかね。 各トピックについてはかなり短いが、必ず前提になるテーブルの準備をするためのクエリ*2
fluentdとシステム設計の小ネタ - たごもりすメモ
あるいは http://yugui.jp/articles/879 へのreply。 システム監視をfluentdに統合してしまうべきか否か システム監視は分けておいた方がいいと思う。分けるべき、とまでは言わないけれど。 それらの仕組みには相応の必要な機能セットがあり、それらは長い歴史の中で比較的決まった機能セットに収斂してきており、その収集・モニタリング・可視化・アラート通知など決まりきったパターンを様々な項目について停止なく行う必要がある。 Fluentdの各種プラグインを用いることで同じような機能は実現できる。そのプラグインのうち数割は自分が書いものだったりする。とはいえ各ホストのシステム監視までそこで行うことを想定して書いたかというと、もうちょっと高いレイヤでの監視・集計、つまりサービス単位などを目的としたものが多い。サーバ単位で行おうとしたときに設定が雑多なものになるのはおそらく
RubyでMySQLに繋ぐためのruby-mysqlとmysql2 - たごもりすメモ
このエントリは MySQL Casual Advent Calendar 2011 - MySQL Casual の10日目の記事です。 こんばんは。tagomorisです。さとしです。タゴモリスの s はさとしの s です(実話)。Twitterで #さとし というハッシュタグが流れるたび、ひそかにびくっとしてます。 RubyからMySQLに繋ぐときにどうするの、ととりあえず gem search -r mysql とかやると思います。そして大量にあれこれ出てきてどうすればいいんだ！ という気分になると思います。そういう気分になったことがあるので、現状を簡単にまとめてみました。 ruby-mysql 昔からの定番ですね。作者は id:tmtms のとみたまさひろさん。rubygemsとか使われる前から Ruby/MySQL というライブラリ名で知られていました。Googleで検索するとト
Webサーバログ転送・ストリーム処理系私案 - たごもりすメモ
HTTPアクセスログをHiveが読める書式への変換やその他必要なデータ変換などストリーム処理で行いつつ転送して最終的にHDFSに時間ごとに書き込むぜー、というシステムを作ってる途中なんだけど、だいたい部品が揃いつつあるところでいったんまとめて書き出してみて見落としがないかどうか考えてみるテスト。 実在のシステムとは異なる可能性があるので(特に後日これを読む人は)あまり真に受けないほうがよいです。あと解析処理自体はHadoop上でHiveでやるのが大前提で、そこにデータをもっていくまでがここに書く話です。 (12/1 考えた末、構成を変えることにしたのでエントリ後半に追記した。) 前提システム 既にscribeを使用したログ収集・配送・保管系がある。各Webサーバは scribeline を使用してログをストリーム転送する。 scribelineのprimaryサーバとして配送用サーバ、se
xargs を使ってカジュアルに並列処理 - たごもりすメモ
シェルからでも重い処理というのはちょこちょこあって、例えば超デカいログファイルを移動して圧縮したりというお仕事は世界中のあらゆる場所で毎日行われていたりする。コマンドラインからでも大量の圧縮済みログファイルをいっぺんに展開したい、とか。 あるディレクトリ以下に存在するたくさんのファイルを(圧縮済みのものを除いて)全部 bzip2 圧縮したい！と思ったら、とりあえずさくっと次のようにコマンドラインで叩けばいい。 $ find . -not -name '*.bz2' | xargs bzip2 これで、まあそんなに問題なく効率的にbzip2圧縮ができる。だがしかし。 最近は複数コアのCPUが普通に転がってるし、あまつさえHyperThreadingが有効になってたりしてOSから見える論理CPU数がハンパない。普通に8とかある。その一方で複数コアを使用してくれるコマンドというのはあんまりなくて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
