Hadoopカウントダウン（Yet Another Advent Calendar HAHAHA)
-
- いいね！5
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
HadoopでのDSLの性格を位置づけるポイントはMapreduceに対応させる演算子に依存する。演算子が事実上の性格を決定する。Pigは独自の言語体系・HiveはSQLライクな言語体系・基幹バッチであれば、それに対応する演算子が必要である。 #HadoopCountDown
2010-12-31 20:55:39
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
HadoopMRは従来のアセンブラ言語の位置する。知ってて書けた方が良いが、大規模では実装コストが高すぎる。高級言語が必要。パフォーマンスや最適化を行うレベルではMR実装技術が必須。システムを象に構築するには、設計やDSLを使う技量が必須。 #HadoopCountDown
2010-12-31 21:00:20
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
Hadoopの利用方法の一つにライフログの解析が注目されつつある。人間の行動や動きをミクロレベルから積み上げて大規模な動きへシミュレーションする。サービスの最適化が高次のレベルで可能。ライフログを持てる企業とそうでない企業で差がつく可能性もある。 #HadoopCountDown
2010-12-31 21:02:48
Suguru ARAKAWA
@ashigeru
Hadoopで複雑なジョブグラフを構築する場合、テスト可能な論理単位を意識すること。さらにそれらを組みあせたものもテスト可能であること。早い時期にそれらをHadoop上で検証することが重要 #HadoopCountDown
2010-12-31 21:04:00
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
ライフログでの解析が普通にできるようになると、情報端末の位置づけも大きく変わる。細かいデータを絶えず送受信するものが注目を集めるだろう。ただしこれは一種の監視社会への入り口になるはずで、今後大きな論争になる素地となると思われる。 #HadoopCountDown
2010-12-31 21:04:30
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
MapReeduceの今後の大きな使い方は、データを分析するだけではなく、最適化を推論する方向にも軸足が移ると思う。推論エンジンは現在は広義のクラスター分析（とその延長）が主流だけど、今後大きく変化する可能性もある。ロジックを押さえた企業が強い #HadoopCountDown
2010-12-31 21:06:47
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
Bigデータを持つ企業はweb系ではなく、社会インフラ系の企業である。交通・運輸・テレコム・金融・流通・・各企業が顧客のライフログをこぞって収集分析する時代はすぐそこ。本当の意味でビジネス・インテリジェンスを活かした企業が勝ち組 #HadoopCountDown
2010-12-31 21:08:46
Shinpei Ohtani
@shot6
そもそも分散システムを主体とした開発手法や設計プロセスの欠如がシステム開発を行ううえで厳しい面が多い。HadoopでMapReduce1つがかけるだけではダメで、それをジョブフローとしてどの単位で効率よく設計できるかが大事。 #hadoopCountDown
2010-12-31 21:28:27
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
分散環境は広い意味での資源管理・運用管理の自動化が最低限の要件。HadoopもZooKeeperの層や種々のモジュールがその部分を担う。すなわち非機能要件は機能要件。この位置づけがつかめていない分散ミドルウェアは技術が優れていても普及はしない。 #HadoopCountDown
2010-12-31 21:31:25
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
分散環境ではセキュリティの実装が非常にやっかい。正直Hadoopは失敗していると言わざる得ない。今後は従来の分散環境でのA&Aの研究成果や実装が出てくるかどうかが注目だが、どうなるか。「間接認証へのもう一つの回答」が必要。 #HadoopCountDown
2010-12-31 21:33:11
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
Mapreduceの再利用性は、MapReduceそのものではプリミティブ過ぎる。それをまとめた上位の概念で行うことが重要。再利用の単位が一種のアトミック性の単位となりバックトラックポイントとも連携する。これは業務設計にも依存する。 #HadoopCountDown
2010-12-31 21:37:00
Kazuma Andoh
@KazumaAndoh
問い。すでにパラレルはShared Nothingしかないと思われていた20年前。Oracleは意表をついたShared Everything(RAC)に行って、市場を席巻した。なぜ？ "コモディティハードウエア"がなかったから？ #HadoopCountDown
2010-12-31 21:37:37
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
MRモジュールの再利用性を考慮するのであれば、頭に置いておくことは①交換可能性 ②順序性の保証の2点。設計時点で頭に置く必要がある。 #HadoopCountDown
2010-12-31 21:38:53
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
Hadoopで複雑なjob実行を行うには、設計が非常に大切。①データフローとその処理、これを抽象化し、かつ多層化する。②データモデル。特にキーと結合処理。ここを二つを重点的にデザインすることがまずは、非常に重要。 #HadoopCountDown
2010-12-31 21:46:22
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
多段のMapreduceの設計は、非同期メッセージ処理・データ処理の設計の嚆矢になるだろう。今後のDryadを始め、同じような仕組みはどんどん出てくる。設計のポータビリティは懸案の特定クラウド環境へのロックインの回避への一助となろう。 #HadoopCountDown
2010-12-31 21:48:04
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
ジョブフローを設計する際にはDAGはきわめて有用。但し、データ設計については検討が必要。いまのところ、汎用性を求めるよりも業務オリエンテッドなデータ設計がいいんじゃないか、とか思うわけですが。このレベルでミドルつくるならば数学の素養は必須ですね。 #HadoopCountDown
2010-12-31 21:49:50
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
テスト可能性の確保は非常に重要。特に並行処理が走った時の状態遷移や処理の受け渡し先の順序性の確認が必要。やり過ぎてもいけないし、やらなさすぎてもいけない。モデル検査とかそういう話題ですね。しらみつぶしは即死するので道具立てが命。 #HadoopCountDown
2010-12-31 21:52:41
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
Hadoopクラスターの運用はそれぞれのクラウドで位置づけが異なる。①プライベートな空間では秘匿性の高い情報を管理＋コストは度外視。②コミュニティークラウドは資源共有でもっともバランス。③パブリッククラウドはelastic性が最重要。 #HadoopCountDown
2010-12-31 21:56:08
三上俊輔
@shun0102
バッチ処理においてデータ量によってはHadoop が要らない時もある。しかし、今後のデータ量増加に備えて Hadoop への移行が容易なように設計するべき。その意味で今は使わなくてもHadoop を学んでおくのは重要 #HadoopCountDown
2010-12-31 22:02:41
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
Hadoopクラスターでのコミュニティークラウドの作りかた。インフラは①リソース管理（含むバッチ管理） ②ユーザー管理につきる。実際にはアレンジャー的「調停者」の位置づけが必要で、全自動は無理だと思う。システムよりもE/Uをまとめることが重要。 #HadoopCountDown
2010-12-31 22:03:48
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
金融セクターでのHadoopの利用検討は始まっている。フロントとバックでそれぞれ検討されておるようですね。個人的にはバックエンド方がバッチ的には合うとは思うけど、フロントへの夢も捨てきれません。とはいえ、「グリッドの悪夢」再びは避けないと。 #HadoopCountDown
2010-12-31 22:05:24
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
今後はHadoopでの開発の見積もり工数が話題になる。どのくらいの人間でできるのか？ノウハウは必要なのか？サイジングは、運用は、設計・実装は？経験的には「通常のの基幹システム＋Hadoopコアチーム」の単位でなんとかなる。 #HadoopCountDown
2010-12-31 22:06:31
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
Hadoopで基幹SIをやるときのHadoopコアチームの構成ね。アーキテクトx3人（Hadoop経験者か、すげー頭のいい人）＋下支えメンバー（環境・インフラ・気配り。これもHadoop経験必須））x3人これで大抵はひとチームになる。 #HadoopCountDown
2010-12-31 22:08:03
disktnkジョン飯
@disktnk
金融フロンティアでの利用は、いままで簡単にできてた事が一気に難しくなって、よくよく考えるとメリットを享受できなくなるから、慎重な設計と入念な検証によるリスクの把握が必要だと考えています。 #hadoopCountDown
2010-12-31 22:09:59