タグ

Asakusaとsparkに関するkimutanskのブックマーク (4)

  • Asakusa 0.8 with M3BP - 急がば回れ、選ぶなら近道

    Asakusaが新規に高速実行エンジン(M3BP)をサポートした。M3BPはメニーコア特化型のC++で実装されたDAGの実行エンジンになる。ノーチラスとFixstarsの共同開発のOSSで、単ノード・メニーコアでの「処理の高速化」に振っている。いわゆるIn-memoryの実行エンジンで、ノードのCPUコアを使い切ることを目標しており、余計な機能はすべて削った。データがサーバ・メモリーに乗るクラスのバッチ処理であれば、ほぼ物理限界までパフォーマンスをたたき出す。 http://www.asakusafw.com/release/20160412.html 実際のベンチマークは以下のwhite paperにある。 http://www.asakusafw.com/wp/wp-content/uploads/2016/04/M3forBP_WP_JA_2016Apr12.pdf ベンチマーク対象

    Asakusa 0.8 with M3BP - 急がば回れ、選ぶなら近道
    kimutansk
    kimutansk 2016/04/12
    エッジサーバ上での性能を絞り切るという観点でも面白いですね。Beamよりも遥かに早い段階で同コンセプトを打ち出してるのでその点でも。
  • 神林節炸裂!Asakusa Frameworkは「分散」から「並列」へ (1/3)

    11月27日、ノーチラス・テクノロジーズは「2015 Asakusa Framework Day」を開催。舌鋒鋭い物言いで知られる同社の代表取締役社長 神林飛志氏は、ビッグデータとIoT市場の現状やHadoop/Sparkと日市場のミスマッチなどを指摘しつつ、次世代のAsakusa Frameworkの構想を披露した。 ビッグデータは既存のCRM、IoTはPoCレベル ノーチラス・テクノロジーズのAsakusa Frameworkは、業務システムのバッチ処理にHadoopやSparkでの分散システムを活用するための開発・運用フレームワーク。会計や在庫などの業務データから精度の高い分析情報を作成したり、バッチ処理に利用できるほか、分散システムのメリットを活かし、負荷分散や高い可用性などを実現する。OSSで公開されており、エンタープライズで多くの実績を持つ。 イベントの後半で登壇したノーチラ

    神林節炸裂!Asakusa Frameworkは「分散」から「並列」へ (1/3)
    kimutansk
    kimutansk 2015/12/01
    Asakusaの実行エンジンが増えますか。エンプラで中~大規模がないのでSpark効率悪すぎというのはそうですが、これをIBMスポンサードのSparkイベントでもぶっちゃけるのがすごいですよねw
  • Java8 Stream APIとApache SparkとAsakusa Frameworkの類似点・相違点

    JJUG CCC 2015 Fall http://www.java-users.jp/?page_id=2056

    Java8 Stream APIとApache SparkとAsakusa Frameworkの類似点・相違点
    kimutansk
    kimutansk 2015/11/29
    SparkMLlibみたいに収束するまで繰り返す、というパターンは無限循環でないから、一応DAGに含まれるんでしょうか・・・
  • Asakusa on Spark - 急がば回れ、選ぶなら近道

    Asakusa on Spark AsakusaがSpark上で動くようになりました。 Asakusa on Spark (Developer Preview) — Asakusa Framework Developer Preview 0.2.2 documentation すでに実際に番に利用しています。 ノーチラス・テクノロジーズがさくらインターネットにAsakusa Frameworkで開発した大規模データの高速処理基盤を導入し、顧客単位での精度の高い原価計算を実現高速処理基盤はApache Spark™で構築 | NAUTILUS OSSとしての公開を行いましたので、内容や位置づけをまとめておきます。例によってノーチラスは社内でいろんな意見は当然出ていますが、今回は概ね一致している感じです。 パフォーマンス 概ね「業務バッチ処理という観点で見れば、すべからくHadoopMapR

    Asakusa on Spark - 急がば回れ、選ぶなら近道
    kimutansk
    kimutansk 2015/07/08
    すべての処理を無理矢理Map・Reduceの形にしなければならない/Map・Reduceのタスク処理が実態としてはそれぞれが独立したjvmアプリケーションになっている がコストが大きいと。
  • 1