@johtaniの日記 3rd

Kuromojiを調べてみた(Jugemより移植)

以前から春山さんのブログ（リンク）や勉強会で耳にはしていたのですがソースは読んでいませんでした。先日、Luceneにcontributeされた（リンク）ので軽くソースを読んでみました。公式サイトはこちらまずはMeCabのページにある比較表（リンク）を基準に特徴を調べてみました。せっかくなので、lucene-gosenも隣に。 Kuromoji lucene-gosen 解析モデルなし（学習機能なし）なし（学習機能なし）コスト推定なし（学習機能なし）なし（学習機能なし）学習モデルなし（学習機能なし）なし（学習機能なし）辞書引きアルゴリズム Double Array Trie Double Array Trie 解探索アルゴリズム Viterbi Viterbi 連接表の実装 2次元 Table 3次元 Table 品詞の階層無制限多階層品詞？ipadic、unidic形式に対応無制限多階層品詞未知語処理字種 (動作定義を変更可能)（おそらく。）字種（変更不可能）制約つき解析たぶん、不可？たぶん、不可？ N-best解不可能不可能こうやって比較してみるとlucene-gosen（Sen）とあまりかわりはありませんが、lucene-gosenが少し古いのがわかりますね。。。

2011-07-20 by johtani

NAIST-JDic for MeCabのPreprocessorの実装に関する備忘録(Jugemより移植)

忘れてしまうので、備忘録を残しておきます。一応、ソースには少しずつコメントをいれてはいるのですが。私は残念ながら、自然言語処理は初心者に毛が生えた程度（現在、鋭意勉強中）で、対応方法に問題があるかもしれません。気づいた方はコメントをいただけると助かります。

2011-07-12 by johtani

lucene-gosen 1.1.1リリース(Jugemより移植)

lucene-gosen 1.1.1をリリースしました。先日お知らせしたバグ修正を取り込んだjarを用意いしました。ダウンロードはこちらから

2011-07-04 by johtani

Lucene/Solr 3.3リリース（速報）(Jugemより移植)

Solr/Lucene 3.3がリリースされました。（速報）以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせリリースのタイミングがどんどん早くなってる。。。

2011-07-01 by johtani

Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）に参加しました。(Jugemより移植)

「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）」に参加しました。300名入るイベントルームでしたが、後ろの方まで人が埋まっていました。ということで、主に自分用ですが、メモを取ったので。 ※二次会行きたかった。。。 1.「鉄道システムへの誘い」 @ayasehiro（本名無理w） Hadoopの話はありません。 ○鉄道系基幹システムの開発実態：耐用年数：１０年以上開発期間：数年～５年程度開発規模：～10Mステップ、10k人月～ほとんどテスト、しかも異常系が主体。夜間に実際に鉄道を走らせて試験したり。開発サイクルが長い人材育成が難しい、ノウハウがたまらない。開発自体はほとんど時間がなく、設計・製造・試験など新規技術の採用が難しい。開発４年前の調査・検証自体が２年程度。 Hadoopも調査中。 ○鉄道システム３大システムマルス（予約オンラインシステム）（1960～）コムトラック（運行管理システム）（1972～）ヤックス（ヤード自動化システム）（1968～1984） ○鉄道輸送システムとは用語：運行を計画する=>輸送計画列車を運行する=>運行管理需要想定＋営業施策＋その他（お召し列車など）＝列車ダイヤ作成基本計画（長期）＋短期計画（数日～四半期程度）＝列車ダイヤ（重ねあわせてできあがり）ダイヤの計画（発車時刻など）と車両運用（車両自体の走る組み合わせ（仮の車両））の作成＋乗務員運用（乗務員の運用計画）運行管理：なにも起きなければすることなし。（車両故障、天候、人身事故などによる整合性を取る作業）＝事前に計画した輸送計画をすべて見直し遅延の検知は？昔：人による伝令今：システムによる検知（レールに電流流して検知）運転整理（実際に遅れた）：部分運休、折り返し駅の変更などにより対応元の計画になるべく近づく形で修正していく。新幹線、山手線、京浜東北線などは速度信号という信号が表示される。線路上に信号はないらしい。 ○鉄道システムを取り巻く情勢少子高齢化・人口減少のため凋落産業となっている。社会インフラの責務＝動くのが当たり前 2007年問題（ベテランの引退）＝スジ屋さんは最近いないらしい。高度な判断支援をするシステムが必要連続稼動＝分散技術を適用できない？関係各所との情報共有計画立案のための情報支援＝最適化技術を適用できない？ ○分散処理技術の適用個人的な感想可用性（連続稼動）のための仕組みバッチ処理 ○分散技術の適用・連続稼動 active-active構成がメイン主系の出力だけを行う。問題が出れば副系の出力。 3系統の出力を比較器にて出力もある magiシステム問題点：ハードが高い（H社）ソフトウェアの作り込みが複雑＝テストが前パターンできない解決案：汎用的なハードが使いたい。作り込みも減らしたい・バッチ処理： Asakusa使えないかなーw ○最適化技術の採用コンピュータ技術の発展 2007年問題職人に言わせれば最適化はいらない、俺の言うことを聞けｗ・車両運用のモデリング車両数大=>組み合わせ大制約条件が多い車両運用の場合、走行累積キロの条件もある ->有向グラフにモデル化される。（ただし、グラフ化するまでが大変）・乗務員運用のモデリング車両と違い、乗務員は1回で2人とか運べる（運転士＋移動する人とか）・車両割当のモデリングやはり、グラフ化が可能・乗務員交番のモデリング。。。など結構一般的なモデルに落とし込める。ただし、落し込みが大変。机上研究だったものが、コンピュータの発展により実証研究になりつつある。 ○まとめ鉄道システムはまだまだ未到の領域が残っている。開発サイクルが長いため、保守的な開発になる（35年前の設計思想からあまり変わってなかったりする）しかし業務要件やシステム利用者の意識は変化している興味を持たれた方は、ぜひ、我社に！（社名は2次会でｗ） ○Q&A Q：鉄道システムのカルチャーってイケイケ？保守的？（@okachimachiorgさん） A：最新技術も知らないとだめじゃないかという人が出てきている。コア部分（安全第一なところ）＋周辺領域（ある程度融通が効きそうな部分）と考えることができるんじゃないかって人も出てきている。 JR九○＝先進的 JR四○、北○道＝お金ない JR○海＝超保守（企業的に超保守） JR東、西＝うーむ？東京メト○（運行計画）、阪○＝先進的京○急行＝基本人間で進路制御w 基本的には新しいものには興味をもつ人たちでは。 Q：Su○caとかで分散処理は利用出来るんでは？ A：匿名なので外側から見ていると分散処理はいろいろ使えるんでは？ログデータからいろいろできるんじゃないの？活かすべきでないの？使いどころはいっぱいある。 Q：鉄道システムでどうしようもなくなったことはあるか？ A：保守体制が一番気になる。 OSSとかならまだ調べられる。ミドルウェアなどの保守契約が必要。保守体制が確立されてればある程度の保守費用は飲み込む。どうしようもないことはないが、今すごく困ってることは Excelで帳票を出したいとかいわれること。（ちょっと前に作ったシステムでExcel2003。バージョンあげると速度が遅くなったりするｗ） ilog社のものを使ってたが、IBMに買収されて保守費用があがってこまってるｗ保守が10年と長いため、サポートなどの折衝が必要。 Q：最適化の適用範囲は？ A：走行順序（どこで追い抜くか）の算出に活用。ほぼ完成でユーザ教育中。 1列車の波及がかなり影響が出る。ダイヤだけ見ると列車だけだが、乗務員も関係しており、大変。ある時点から終電までを最適化の対象としたりして割り切っている。また、不足分について算出が出来れば、そこで打ち切ったりもする。 2.「九州電力におけるHadoopの取り組みについて」株式会社キューデンインフォコム e－ビジネス部　@hisashi_yano 概要：2年間関係したOSSをメインにしたシステムの話。 ○九州電力の概要現在風当たりが強い業界。東電の1/10くらい部門ごとに大手ベンダーが関わってる。 ○Hadoop採用の経緯部門ごとに個別最適なシステムを導入していてベンダーロックインされてる。・ホストのリプレース・両現用センター構成への対応・スマートグリッドへの対応問題点・コスト削減・技術革新への中の人の対応（内部でも問題を理解できるように）・商用パッケージのカスタマイズの限界・脱ベンダーロックイン（実は楽なんだけど。。。） ○過去2年間の研究内容・H21年度の結果テーマ：クラウドの要素技術の研究 KVM、Eucalyptus、wakame、hadoop 性能比較：VMWareとKVM->ベンチマーク比較結論：性能的にあまり問題なし。 MapReduceの耐障害性などダミーデータにより台数増加による影響を検証結論：台数大->性能向上ストリーミングは性能劣化するスループットはリニアに向上信頼性は？実行中にノードを抜いたりして検証。結論：問題なし。クラウド環境におけるシステム管理手法複数ハードで1アプリという構成になる。監視対象が膨大になる。障害発生時の切り離しや監視対象も膨大。データセンター自体を監視する仕組みが必要では？というところで終了。・H22年度の結果分散に特化した研究前年度の課題サーバの仮想化・管理に関する課題分散処理に関する課題分散処理環境の運用監視に関する課題目的： Hadoopを本番への適用（実際にはダミーデータ＋本番の仕組み）柔軟なサーバ統合基盤（サーバを起動->バッチを起動->回す仕組み）＝MonkeyMagic libvirtを使ってる 50台の仮想サーバの起動が10数分で完了。運用監視基盤（monkey magic）仮想、実サーバ混在の監視監視状況（サーバの状況）から判断して制御する仕組みを構築 DSLにてルール（判断＋制御）を指定・ジョブの監視・ジョブの実行管理・構成管理の省力化 volanteと連携が可能＝AmazonWebServiceとも連携可能・サーバリソース＋アプリケーションの一括監視が可能分散バッチ処理の概要 RDBからKV形式にして抽出し、MRで回してRDBに戻すという研究対象：配電部門（電柱の設備情報の目視検査）のデータの月間バッチ処理現状： 19時間程度かかってる。テスト環境：実サーバ2台（仮想10台） MySQL、Javaで実装処理内容電柱104万本巨大バッチを分割して実装結果 MySQL1台では15日以上かかる処理（現行システムで19時間）処理が32分で終了！他でも効果でるよね。バッチ短縮の理由は？ 1.データアクセスが分散された 2.処理の並列化（多重化出来る部分がうまくできた）分散処理を書くのに2名死亡。。。適用基準の策定、開発ガイドライン、フレームワーク整備などが必要。・H23年度は？ Asakusaの適用など。・さらに今後は？スマートグリッドへの適用 ->メーターの交換が必要だが、10年くらいかかる ->スパンが長い（10年）ので商用製品だときつい？データ量も半端ない。テネシー州とClouderaでOpenPDCってのやってるらしい。電力と気温の関係は密接な関係あり。エアコンが割合を占めてるから。過去実績と予想気温データから分析するのにHadoop使える！・2年間やってきて思うこと将来目指すべき理想像を掲げるのが重要新技術導入は段階を踏むことが必要コミュニケーション大切！ ○Q&A Q：仮想化環境のオーバヘッドは？（I/O） A：台数を増やしたときにどうなるか？というのを検証したかった。アプリ配布も考えていたので、物理サーバに縛られたくなかった。 Q：仮想化に関して気をつけたM/RのPGで気をつけたことありますか？ A：まったくないです。 Q：日本でスマートグリッドははやるの？ A：電力会社的にはやりたくない。費用対効果があまりない。 Q：今後のスケジュールは？ A：文書管理システムの組織名変更などの処理時間が540時間とかでてくるらしい。これをHadoopで対応してみようかと思ってる。 Q：Asakusaをどう評価していくのか？ A：開発効率性があがるか？は検証する予定。1/3くらい楽になるんじゃないかなぁ？byのぐちさんバッチの種類などにもよると思うが、標準化も指標にする予定。結果はまたこの場で報告する予定。 Q：Asakusa＋MonkeyMagicの連携はどんなこと考えてる？ A：MonkeyMagicを運用基盤として行く予定。合意が取れればだけど。 ※MonkeyMagicもOSSにするよー

2011-06-29 by johtani

compositePOS（CompositeTokenFilter）のバグ修正(Jugemより移植)

以前、こちらで話題に上がっていた「未知語」に関するcompositePOSのエラーの件を調査しました。（Twitterでも流れてました。）次のような条件の場合にエラーが発生するようです。 compositePOSの設定に構成品詞として「未知語」が指定されたエントリが存在する。未知語が連続して出現する文字列をanalyzeする。（例：ニンテンドーDSi）ということで、trunkに修正版をコミットしました。 Issueはこちら。

2011-06-28 by johtani

NAIST-JDic for MeCab対応版（仮実装）(Jugemより移植)

lucene-gosenのtrunkbranches/impl-mecab-dicにNAIST-JDic for MeCabの辞書を利用出来るPreprocessorをコミットしました。ビルド方法は次のとおりです。

2011-06-21 by johtani

compositePOSの利用例（naist-chasenでの英単語の出力方法例）(Jugemより移植)

前回、naist-chasenではアルファベットが別々の単語としてanalyzeされてしまうという話をしました。ただ、これだと、英単語が含まれた文章を形態素解析すると、英単語がアルファベット単位に区切られてしまい、単語の意味をなさなくなってしまいます。

2011-06-14 by johtani

lucene-gosen 1.1.0 リリース(Jugemより移植)

lucene-gosenの1.1.0がリリースされました。大きな目玉はJapaneseTokenizerが出力する形態素に関するデータを遅延ロードすることで、パフォーマンスの改善を行ったことです。

2011-06-13 by johtani

lucene-gosenのTokenFilterたち(Jugemより移植)

lucene-gosenをSolr/Luceneで利用する場合、TokenFilterを利用してTokenizerが出力したToken対してさまざまな処理（Tokenに対する正規化や展開など）を追加することが可能です。

2011-06-06 by johtani