大規模データ分析システムの現在。Asakusa Frameworkの実力、Azureの多機能、シスコのハイブリッドクラウドソリューションを見る［PR］ 大規模に収集したデータを分析して企業の意思決定に生かすということが、一般的になろうとしています。この新しいビジネスニーズに合致する大規模データ分析システムとは、どのようにあるべきなのでしょうか。 シスコシステムズ合同会社および日本マイクロソフト株式会社の協賛のもと、株式会社ノーチラス・テクノロジーズ主催の「IoT時代のハイブリッドクラウドによる最新のデータ活用セミナー」が10月初旬に開催されました。 各社による大規模データ分析のためのソリューションを見ていきましょう。 シスコのIntercloud Fabricでハイブリッドクラウドを実現 大規模なデータ処理をおこなうための基盤とはどうあるべきなのか。その効率性を考えると「プライベートクラウ
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
Jinrikisha - Asakusa Framework Starter Package - — Jinrikisha 0.10.4 documentation
使い方¶ ダウンロードしたインストールアーカイブを任意のディレクトリで展開します。 展開したファイルに含まれる setup.sh を実行するとインストールが開始されます。 Jinrikishaのインストールディレクトリなどいくつかのインストールパラメータの入力が促されるので、インストーラの指示に従ってインストールを実行してください。 インストール手順の詳細やインストール時の注意事項は、 Jinrikisha インストール手順 を参照して下さい。 インストールした開発環境を利用する¶ Jinrikishaのインストールが完了したら、サンプルコードを確認したり、実際にアプリケーションを開発してみましょう。 インストールディレクトリ配下の README には、インストールした後にAsakusa Frameworkの開発環境で使用するコマンドやEclipseの使い方などを簡単にまとめた Getti
というわけで2014年に突入ですが・・・ 景気が回復しつつある現状で、SIの受注も好調なようです。ユーザー企業でも多少の予算の余裕も出てくるところもあり、システム投資には多少前向きになっているところも感じます。多少のでこぼこや、業界・業種によって色合いは異なるでしょうが、今後数年は景気の回復基調はコンセンサスになりつつあるようです。IT業界も例外ではないでしょう。もたもたしているビッグデータ案件を尻目に、システムリプレースや既存改修、新規でのシステム開発もスタートしつつあり、SI業界の件数ベースは今年は昨年を確実に上回るでしょう。 とはいえ一方で不採算案件も相当増えるように見えます。結果、SIビジネスはトレンド的には案件増・売上増ですが、利益減（または横ばい）というのが実態になるかと。要するに単金はそうそう簡単にはあがりませんが、案件は増えて、人繰りが追いつかず、結果限りなく失敗に近い「よ
二年経過したので記録として置いておく感じで。 ということで気がついたら設立から二年経過していました。正直、まだ二年しか経過していないのか、という感じがします。この一年は二年分ぐらいの時間感覚でした。まじで時間経過が速すぎて死ぬかと思った。去年の今頃はAsakusaの立ち上げで、特にSI屋向けのサポートに力を入れていた時分で、今と状況がまるで違う状況でした。この一年では大きな試行錯誤を二回ほどやった感じになっていて、現在ではAsakusaの向こう側の違う方向性の模索し始めているところです。 大きな方向性としては、この一年で以下が大きく違ってきていると思います。 1.クラウド・コミットが普通になってきた、とはいえ、一方でまだまだというところも実情。元々クラウド上で構築や作業や環境の獲得は普通にやってきましたが、やはり、春先の西鉄ストアさんの基幹業務系をAWSで動かしたというのは、それなりのイン
ちょっと諸般の事情で放りだしてあったのですが、まとめておかないと忘れるので、記録的においておきます。あとでたぶん自分でも見直すと思うので。 このエントリーは完全にトランザクションの人向けです。現時点これが本当に必要な人は世界でたぶん50人ぐらいだと思います。全日本的には絶対わかんないとまずいという人はたぶん5人ぐらいです。 ただし、分散DBガチの人はわかっていた方がいいと思うので、おいておきます。 論文はこちら http://sydney.edu.au/engineering/it/~hyungsoo/vldb2011.pdf 内容はSerializable Snapshot Isolation (以下SSIと略記)の分散環境下への適用に関する論文です。一応実装もあってベンチマーク結果が出ています。SSIについては下記エントリーを参照にしてください。 http://d.hatena.ne.
先日をもって無事に読了しました。記念に記録しておきます。 読んだ本はこれ Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery http://www.amazon.co.jp/Transactional-Information-Systems-Algorithms-Concurrency/dp/1558605088/ref=sr_1_1?ie=UTF8&qid=1370746124&sr=8-1&keywords=transactional+information+systems 始まったのが、2011年の秋からだったので、ほぼ一年半かかりました。スタート時点は10名ほどいたメンバーも徐々にいなくなり、最後は不動の4人のレギュラー
基幹システムをクラウドへあげるのは簡単ではなかった。ノーチラス・テクノロジーズがクラウドの現実を語る（後編） 基幹システムをクラウドで実現する。その過程でどのような技術を用い、どのような苦労があったのか。小売り流通業である西鉄ストアの基幹システムをAmazonクラウド（以下、AWS：Amazon Web Services）の上で実現したノーチラス・テクノロジーズが、その詳細について紹介したセミナーを5月15日、アマゾンジャパン本社のセミナールームで開催しました。 （本記事は「基幹システムをクラウドへあげるのは簡単ではなかった。ノーチラス・テクノロジーズがクラウドの現実を語る（前編）」の続きです） 和製クラウドでトラブルが続き、やむなくAWSへ移行 インフラについて。やはり和製クラウドベンダのインフラは値段が高い。いろいろ話をして安くならないかと相談したけれど、無理でした。理由は簡単です。デ
基幹システムをクラウドへあげるのは簡単ではなかった。ノーチラス・テクノロジーズがクラウドの現実を語る（前編） 基幹システムをクラウドで実現する。その過程でどのような技術を用い、どのような苦労があったのか。小売り流通業である西鉄ストアの基幹システムをAmazonクラウド（以下、AWS：Amazon Web Services）の上で実現したノーチラス・テクノロジーズが、その詳細について紹介したセミナーを5月15日、アマゾンジャパン本社のセミナールームで開催しました。 大規模システム開発の現状、Hadoopの可能性、クラウドのメリットとデメリットなど、参考にすべき多くの内容が語られたセミナーでした。この記事ではその概要を紹介します。 止まってはいけない基幹システムをクラウドへ ノーチラス・テクノロジーズ 代表取締役社長 神林飛志氏（写真中央）。 西鉄ストア様の本部基幹システムをクラウドへ移行する
某エントリーの話で、「なんでもかんでもクラウド化なのか？」というお話もご意見も多数頂戴いたしまして。一応念押しですが、そういうつもりはまったくないですよ。以下、個人的な補足メモです。会社の意見ではありません。一応、会社の公式声明は「できるものは、とっとクラウド化したほうがいいですよ。」です。 クラウド化の是非については、いろいろあるでしょう。ユーザーの所属する産業毎にシステムのあり方・考え方は違うでしょうし、当然クラウド化すべきだという意見や、いやそもそも無理があるという意見もあると思います。ただ、今までのように先例がないから無理、という理屈は通用しなくなっているのが現状でしょう。その意味では無茶な理屈ではなく、普通に選択肢としてクラウド化が候補になっている、と思います。その上で、クラウド化しない、するという議論が普通にできる状態になりつつあると思います。 そんな中でいろいろ思うところをち
snapshot isolationを分散環境に適用する場合の「基本」の内容のまとめになります。（基本自分用のメモなので、間違っていたらすみません） まずワーディングの整理 ・snapshot isolation TXの分離レベルとしてのsnapshot isolation（以下SI）は、現在のRDBMSのTX管理では、ほぼ実装的にはデファクトと見ていいと思います。ただしANSIの規定のISOLATION_LEVELには定義がないので、どのあたりに位置づけるのかは、DB実装のそれぞれの取り扱いにより異なります。とはいえ、どのDBでもほぼSERIALIZABLEに近い位置づけにしているところが多いですね、というか、SI（特にSerializable SI）ぐらいでないとserializableに現実的には近づけないというのが実態かと思います。（勿論理論上はS2PLで実装は可能ですが、まぁパフ
業務システムへ安心して分散処理を適用頂けるよう、Asakusa Frameworkのサポートサービスをご用意しております。Asakusa Frameworkのみならず、Hadoop,Sparkに関しても経験豊かなエンジニアによる適切かつ迅速なサポートをご提供いたします。 概要 Asakusa Framework on MapReduce, Spark, M³BPを利用したシステムに対するサポートサービス。 ・Asakusa Frameworkの製品仕様に対する問合せ ・Asakusa Frameworkが原因と思われる事象に関する問合せ ＊MapReduce,Spark,M³BPのうちいずれか1つをご指定頂きます。 ＊下記例のような内容に関してはサポートサービス対象外となり、別途プロフェッショナルサービスにて対応致します。 例) -アプリケーションの設計、実装、テスト方法に関する問合せ -
ノーチラス・テクノロジーズは2013年4月16日、分散バッチ処理ソフト「Hadoop」を使って基幹系バッチ処理を実行するフレームワーク「Asakusa Framework」のPaaS（プラットフォーム・アズ・ア・サービス）である「Node0 DBR」を開始した。 ユーザーはIDE（統合開発環境）からプログラムをPaaS上に展開するだけで、HadoopとAsakusa Frameworkを使ったバッチ処理が実行できる。バックエンドのITインフラには、「Amazon Web Services（AWS）」を使用する。 サービス名称にあるDBRは、「Distributed Batch Runtime（分散バッチ実行環境）」の略。「Hadoopのような分散処理基盤はセットアップや運用に労力が必要なので、ユーザー企業が自前でシステムを構築、運用するのは難しい」（ノーチラスの神林飛志社長）と考え、Paa
個人的には割と大変だったので、その辺をまとめておきます。 ニュースリリースはこちら。 http://www.nautilus-technologies.com/topics/20130409.html 要するに本部系バックエンド基幹システムの「一式」のクラウド移行です。完全なミッションクリティカルシステムで、止まった段階で業務に確実に影響が出ます。 システムの機能概要 1.売上の確定処理と債権管理 POSデータの直結です。売上確定処理を行います。同時に債権管理も行い、F/Bからの入金データをそのままつなぎ込み、入金処理・債権の消し込み処理を実行します。マッチングは自動処理できるものは処理を行い、ヒューリスティックなものはユーザー判断に従います。 2.仕入・費用の計上と確定処理、および支払いデータの作成 費用・在庫の計上確定処理です。当時に支払データの確定処理を行います。EDI（BMS）との
ホーム>お知らせ>ノーチラス・ テクノロジーズは、西鉄ストアの本部基幹システムを Asakusa Framework/Hadoopにて開発、ミッションクリティカルなシステムを アマゾン ウェブ サ―ビス上で本稼働開始 ノーチラス・ テクノロジーズは、西鉄ストアの本部基幹システムを Asakusa Framework/Hadoopにて開発、ミッションクリティカルなシステムを アマゾン ウェブ サ―ビス上で本稼働開始 PDF版のダウンロードはこちら 株式会社ノーチラス・テクノロジーズ(以下ノーチラス)は、株式会社西鉄ストアの本部基幹システムの刷新を行い、2013年3月末に全面稼働を開始したことを発表いたします。 この本部基幹システムは、Hadoop/Asakusa Framework™(*1)を利用した基幹系システムでは、現時点で日本最大規模となります（当社調べ 2013年4月9日現在）。また
Making Snapshot Isolation Serializable 再考 ■2013年的な位置付け まずちょうど年度の開始なので、今年は自分的にはRDBMS関連の位置付けとか整理しておきます。去年の後半あたりからの匂いですが、NoSQL的な発展と合わせて、本格的なDB回帰が始まっている感じです。NoSQL系のほぼ致命的な弱点の一つがtransaction処理であることは指摘も多いところです。要するにデータが書き込めても不整合が発生しますね、ということになってしまいます。これではなかなか使えない、というのが現状でしょう。 なので、RDBMの最良のノウハウであるtransaction処理とNoSQL的な分散処理をちゃんと整合性とれるようにしましょう、という自然な流れは従前よりもより強い要請が働くでしょう。(できるかどうかは別ですが。) それで、そろそろなんかその手のものがRDBMSサ
ニュースリリースというか記事はこちら。日経の中田さんの記事ですね。 http://itpro.nikkeibp.co.jp/article/NEWS/20130306/461423/ この辺の解説を記録のために書いておきます。個人的にはちょっとしたマイルストーンなので。 まずEDIの定義ですが、これはElectronic Data Interchangeの略で、B2Bでの電子データ交換の仕組み自体をさします。歴史的にはITの歴史と同じくらい古い。当然インターネットよりも古い。昔は（場所によっては今も）電話で”ぴー”とか”がー”とかやっていた代物です。多分50年以上の来歴を誇る仕組みですね。業界ごとにその業界に応じたプロトコルが制定されており、いわゆる標準化がもっとも進んだ分野のひとつです。そして、大抵はミッションクリティカルな業務に属します。エンタープライズ系のITでは最下層に位置するレイ
Hadoop Conference Japan 2013 http://hcj2013w.eventbrite.com/ 先週終了。かなりの盛況で終わった感じです。まずは開催をサポートして頂き、相当の負担まで頂いたリクルート・テクノロジー様に感謝申し上げます。どうもありがとうございました。 さて、えっと、前回がそもそもいつだったのか、良く覚えてないわけで。2011 Fallだったような。 http://hadoop-conference-japan-2011-fall.eventbrite.com/ 2011年の9月なので、1年4ヶ月ぶりという感じですね。Track数が増えて2から3で、会場もベルサールからビッグサイトになっていました。人数も1000人超になっております。 以下、感想文です。記録としておいておく感じで。 ・内容で印象に残ったもの ・HBase~LINEのバックボーンで使って
この10月でノーチラスの設立1年という運びになりました。お世話になったお客様・パートナー様・応援して頂いた皆さんに感謝申し上げます。ありがとうございます。 ということで気づけば一年経過ということで、陳腐なようですが「光陰矢のごとし」の一言に尽きます。思えばこの一年はいろいろありましたというか、有り過ぎました。 ■Asakusaの状況「Hadoopの使い方としてのバッチ処理」という意義は市場ではアクセプトされた感もあります。この一年は、SI屋さんを始めベンダーさんやトップ・ノッチのエンドユーザーさんでの検証・小手調べの期間だったかな、と思います。結果としては「まぁ確かに速くはなるね」という点と、「まぁ確かに開発効率は高いわね」という二点については、程度の差こそあれ、大抵の利用者・検証者には認識してもらえた感じです。 一年終了時点での市場でのプレゼンスはそこそこには出せているので、まずは及第点
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
