Monthly Archive for December, 2014

Hadoopが金融のメインストリームへ (Whitepaper要約)

 

“Bringing Hadoop into the banking mainstream”はグローバル銀行が技術、商習慣、規制を如何に乗り越えてHadoopをミッションクリティカルなアプリに使用しているかの事例です。詳細は以下のURLを参照ください。

https://www.brighttalk.com/webcast/11809/134895

背景:

事例の銀行は北米、ラテンアメリカ、ヨーロッパ、アフリカ、APACで事業を展開、従業員は225千人、資産はUS$2500M。保有するアプリは数千。Hadoopを導入し大幅なコスト削減を達成している。しかしながら何人かのIT担当役員はHadoopの成熟度に懸念を示していた

挑戦:

この銀行が感じているHadoopの主な問題点は以下のとおり。

・バックアップ、信頼性、クラスタ間・地域間でのデータ一貫性

通常、DistCPをベースとしたツールが使われているが、高負荷で他のアプリに影響を与えてしまう。このためバックアップをとるのは1日1回が限度となっている。ロードバランサーで工夫はできるが、復旧不能なデータロスも起こる。こうした状況は規制の観点から受け入れられないところである

・混在するワークロードでの性能保障

いくつかの重要なリアルタイムアプリをインメモリで動かそうとするが、Hadoopはクラスタ内にゾーンを作ることができない。このため、次のような問題が発生する。①すべてのアプリをハイエンドサーバで動くようにすると予算オーバ ②ハイエンド、ローエンドサーバの組み御合わせて全てのアプリを動かすと重要なアプリに最適化されない ③アプリの特性毎に個別クラスタを作ると冗長、柔軟性欠如であり運用費もUP

・データレイクとプライバシー保護法

EUの一部、アルゼンチン、サウジアラビア他では個人情報を国外に転送することを法律で禁止。Hadoopでグローバルな分析を行う際にDistCPでデータを移動することができず、特別なアプリが必要になってしまう

・複数地点のデータのタイムリーな解析

標準的なHadoopではデータをいくつものサイトからコピーする必要があり、時間がかかるし、信頼性も問題となる

解決策:

Non-Stop Hadoopは以下のような特長があり、銀行の要望を満足

・可用性とデータの一貫性保障による規制への準拠

いくつもの規制は特定のデータが常に利用可能であることを要求。バックアップ、ディザスタリカバリが必要であり、かつそのデータが元データと整合していることが求められている。Non-Stop HadoopのActive-Active複製がソリューションとなる

・コンピュータリソースを100%利用する事によるコスト削減

Active-ActiveアーキテクチャによりすべてのサーバはRead/Write可能。従い、Read Onlyのバックアップ・ディザスタリカバリセンタをアプリからも使用できる。

・データ保護規制への準拠

Non-Stop Hadoopは複製する範囲を選択可能。また、複製しないデータについては、ローカルに存在しないときはデータのあるセンタをアクセスします(WAN/LAN経由)。従い、不正検出、マーケット解析をグローバルなデータセットで規制に準拠しつつ、実行可能

・クラスタゾーンによる性能最適化とコスト削減

Non-Stop Hadoopは仮想クラスタを作れます。ハイエンドサーバからなる仮想クラスタをキーとなるデータセンタ内につくり不正検出、マネーロンダリング防止のアプリを動かしている。大きなHWへの投資なしにクリティカルなアプリの性能の担保をすることが可能

・高速、高信頼のデータ複製と複数データセンタでのデータロード

データはどこのセンタで投入されても任意の数のデータセンタに複製が自動的に作成される。DistCPでのコピーする際に発生しうるエラーや運用者の負荷が下がる。一方、クライアントアプリはLANスピードでのRead/Writeが可能。銀行の顧客(攻撃もふくめ)は多国籍になってきており、例えば不正検出をグローバルベースで行うことがクリティカルです。

avatar

About Kenji Ogawa (小川 研之)

WANdisco社で2013年11月より日本での事業を展開中。
以前は、NECで国産メインフレーム、Unix、ミドルウェアの開発に従事。その後、シリコンバレーのベンチャー企業開拓、パートナーマネージメント、インドでのオフショア開発に従事。

Hadoopが金融業の主流に

米調査会社のForesterリサーチと弊社のWebinarの紹介です。Webinarのリプレイは以下で見ることができます。

https://www.brighttalk.com/webcast/11809/134895

最初のスピーカはForesterのJost Hoppermann VP。金融業でのビッグデータ事例を紹介。最初はRisk管理が最重要課題であり、データウェアハウス、インメモリ技術を適用し、これに対応したドイツの銀行の例です。銀行はビッグデータという名前は使わないが、実際はビッグデータであるという一例。次に別の観点からのビッグデータの必要性を指摘している。81%の銀行が2018年までに変革を考えているとの調査結果があり、この実現にはビッグデータが必要。どこからこの変革を起こすかといえば、非定型も含めた顧客データからであり、ビッグデータがこれを支えるのは間違いない。コアバンキングも例えば顧客との組み合せでビッグデータが入り込むチャンスはあるとしている。少し視点が変わるが、クロスボーダーでの可能性が紹介された。個人情報は国外持出し制限、全面禁止となる国もあるが、必要データを切り分け、一つのデータセンタに集めることで統一されたリスク管理ルールを使用して成果をあげた事例が示された。

次のスピーカはLeslie Owen VP。現状は利用可能データの15%しか使われていないことを指摘。従来の整理された高価なデータから、安価で多様なデータを利用して世界の動きを理解する将来の姿に向け、考え方が変わりつつあるのが現在と分析。2014年のビッグデータの定義は「利用可能な大量のデータとそれをビジネスの為に使う能力のギャップを縮める技術と商習慣」としている。2012年の定義は5つV(Volume、Verity, Variability, Velocity, Value)を如何に扱うかとの技術視点であったが、これにビジネス視点が加わりバランスのとれたものになったと見ている。ビジネスおよび技術のデシジョンメーカへのビックデータへの期待に関するアンケートからのこの傾向が見てとれる。次にパラダイムシフトに必要な3C(Culture, Competence, Capability)について触れている。ビッグデータで成功している会社はR&Dとして投資するCultureを持っているとのこと。従業員が、Fact(データ)がどうなっているかを考えるような環境作りが重要。

最後にWANdisco社のRandy Defauwが金融業の3つのイノベーションについて説明。一つ目はアルゴリズムに基づく意思決定。金融業は一過性のデータも使い、遅延ない意思決定を行おうとしている。不正検出がよくある例として挙げられている。2つ目は前述と関連するがData Lakeの話。兎に角、いろいろなデータをため込み顧客・市場を理解すること。3つ目はプロセスのイノベーション。金融業界は特に短期間でのリターンが要求される。伝統的なデータウェアハウスからHadoopに変えて大きなコスト削減を行っている。これらにイノベーションの要求に如何にNon-Stop Hadoopが答えるかについての説明している。

この詳細については次回Whitepaperをベースに紹介します。

avatar

About Kenji Ogawa (小川 研之)

WANdisco社で2013年11月より日本での事業を展開中。
以前は、NECで国産メインフレーム、Unix、ミドルウェアの開発に従事。その後、シリコンバレーのベンチャー企業開拓、パートナーマネージメント、インドでのオフショア開発に従事。

The hunger for low latency big data

Good grief: Spark has barely hit a 1.0 release and already there are several projects vying to improve on it and perhaps be the next big thing.  I think this is another sign that Spark is here to stay – everyone is focusing on how to beat it!  In fact even the Berkeley lab that developed Spark has come up with an alternative that is supposedly a couple orders of magnitude faster than Spark for some types of machine learning.

The bigger lesson here for CIOs and data architects is that your Hadoop infrastructure has to be flexible enough to deploy the latest and greatest tools.  Your ‘customers’ – data scientists, marketers, managers – will keep asking for faster processing time.

Of course here at WANdisco we’ve got some of the best minds in Big Data working on exactly this problem.  Our principal scientists have been working on the innards of Hadoop almost since day one, and they’re evolving our Hadoop products to support very sophisticated deployments.  For instance, Non-stop Hadoop lets you run several Hadoop clusters that share the same HDFS namespace but otherwise operate independently.  That means you can allocate distinct clusters (or carve off part of a cluster) to run dedicated processing pipelines that might require a different hardware or job management profile to support low latency big data operations.

Sound interesting?  It’s a fast-moving field and we’re ready to help!

Paxosと分散コーディネーションエンジン(DConE)

分散環境でのActive-Active複製を可能にするDConEの紹介です。Paxosを拡張して、WAN環境でも情報の一貫性が保障されるようになっています。
1. Paxosについて
Leslie Lamportが提案した信頼性の低いプロセッサから構成されるネットワークにおいての合意の問題を解決するためのプロトコルの集合。Paxosプロトコルは1990年に登場し命名されたが、論文として出版されたのは1998年でした。
PaxosアルゴリズムではState Machine(状態機械)が分散システムの各ノードにインストールされ、トランザクションの順序を保障します。State MachineはProposers、Acceptors、Learnersのいずれかの役割を果たす。Paxosアルゴリズムでは以下の3つのフェーズがコンセンサスの取れるまで繰り返されます。①CoordinatorになるNodeが選択され②トランザクションProposeがブロードキャストされ、受け取ったノードはAcceptするかReject③関連するノードの過半数がAcceptすれば、コミットメッセージがブロードキャストされトランザクションを実行。プロポーザル番号は一意となるようにします。

2. DConE(Distribution Coordination Engine)についてスライド1
DConEはPaxosをWANでも使えるように拡張したものです。DConEの主な構成要素は図の通りです。実際の動きを簡単に説明します。
アプリケーションの書き込みトランザクションが発生すると当該ノードのProposal ManagerはLocal Sequence Number(LSN)を付与したProposalを生成し、障害発生に備え、セーブします(Proposal Log)。次にAgreement Managerは保持しているGlobal Sequence Number(GSN)をIncrementしたAgreement Memberを決定します。GSNは全てのNodeでAcceptされた最後のProposalの番号です。このAgreement Memberにより当該トランザクションに関するコンセンサスをすべてのノードに対して取ることを試みます。このデータもAgreement Logとしてセーブされ、障害時にはProposal Logと一緒に回復処理に使われます。
過半数がAcceptすれば、Agreement NumberがそれらのノードのGSNになります。コンセンサスに達するとDConEはトランザクションをLocking Managerに渡します。Proposalを発行したNodeはGSNの合意は待ちますが、他のノードのトランザクションの完了を待つことはありません。以下、DConEの特長を説明します。

2.1 ローカルな順序の保持(米国特許#8364633)
DConEは性能向上のため、並列してコンセンサスの処理を行います。このため、ノード内でアプリが求める順序がGSNを決める際に逆転してしまう可能性があります。ノード内の順序を決めるためのLSN(Local Sequence Number)とネットワークで接続されたノードでのGSN(Global Sequence Number)の2つによりトランザクションの順番を決定します。ネットワークはLANでもWANでも対応可能です。

2.2 Locking Scheduler
Locking SchedulerはGlobal Orderは意識しません。ローカルキューに従ってトランザクションの処理をします。アプリとのインターフェースはDConE は持っておらず、Locking Schedulerが面倒をみます。Locking Schedulerという名前ですがロックのスケジュールをする訳ではなく、言ってみれば、Database Schedulerのような振る舞いをする訳です。

2.3 性能・スケーラビィリティの向上
DConEは大規模なWAN環境でもPaxosアルゴリズムが動くような強化をしています。主なものは以下です。

・Paxosは多数決論理で動く訳ですが、オプションで決め方が選べます。あるノード(Singleton)のみがプロポーザルのレスポンスをするような設定が可能です。一番多くユーザが使っているところをSingletonノードにすることでWANのトラフィックを下げることができます。リージョンで多数決論理を動かすことでFollow the Sunのようなことも可能です。また偶数ノードの場合はTie Breakerを決めることで対応できます。
・複数のプロポーザルの処理を並行して行うこともできます。Agreement Number取得の際に発生する衝突による性能劣化への対処もされています。新しいノードの追加・既存ノードの削除も動的に行えます。
・ディスク・メモリ上にセーブされたState Machineの情報をいつまで保持すべきかは、安全性とリソース使用率のバランスをとるのに苦労するところです。一定間隔でノード同士がメッセージをやり取りすることで解決しています。

2.3 自動バックアップとリカバリ
Active-Activeの複製により全てのノードのホットバックアップが取られます。あるノードにネットワーク障害が起きてもリードだけは可能としています。ライトは禁止されSplit Brainにより情報不一致が発生することを避けています。CAP定理によればC(Consistency)、A(Availability)、P(Partition-Tolerance)の3つを同時に満たすことはできません。DConEはCとAを優先するような設計思想となっています。
障害が復旧すれば、DConEが障害の期間中にAgreeされたトランザクションをAgreementログ、Proposal Logより自動的に復旧します。

3. 終わりに
以上、大まかな説明ですが、詳しくはDConEのWhitepaperを参照ください。
http://www.wandisco.com/system/files/documentation/WANdisco_DConE_White_Paper.pdf

avatar

About Kenji Ogawa (小川 研之)

WANdisco社で2013年11月より日本での事業を展開中。
以前は、NECで国産メインフレーム、Unix、ミドルウェアの開発に従事。その後、シリコンバレーのベンチャー企業開拓、パートナーマネージメント、インドでのオフショア開発に従事。

Hadoop security tiers via cluster zones

The recent cyberattack on Sony’s network was a CIO’s nightmare come true. The Wall Street Journal had a good summary of some of the initial findings and recommendations. One of the important points was that data integration, although a huge win for productivity, increases the exposure from a single security breach.

That started me thinking about the use of isolated Hadoop security tiers in Hadoop clusters. I’m as excited as anyone by the prospect of Hadoop data lakes; in general, the more data you have available, the happier your data scientists will be. When it comes to your most sensitive data, however, it may be worth protecting with greater rigor.

Hadoop security has come a long way in recent releases, with better integration with Kerberos and more powerful role-based controls, but there is no substitute for the protection that comes with isolating sensitive data on a separate cluster.

But how do you do that and still allow privileged users full access to the entire set of data for analysis? Non-stop Hadoop offers the answer: you can share the HDFS namespace across the less secure and more secure clusters, and use selective replication to ensure that the sensitive data never moves into the less secure cluster. The picture below illustrates the concept.

hadoop -ref-arch-5

Users on the ‘open’ cluster can only see the generally available data. Users on the ‘secure’ cluster can access all of the data.

Feel free to get in touch if you have questions about how to add this extra layer of defense into your Hadoop infrastructure.

Machine Learning as a Service?

Rick Delgado had an interesting article on how the widespread availability of machine learning will facilitate the rollout of the Internet of Things (IoT).  Intuitively it makes sense; as algorithms become widely understood and field tested, they evolve from black magic to tools in the engineering kit.  You can see this phenomenon in automotive safety technology.  In the mid 1990s I was working on machine vision algorithms for automotive applications.  Everything was new and exciting; there were a few standard theories, but they had barely been tested at any scale and the processing hardware hadn’t caught up to the data demands.  Now as the Wall Street Journal reports, Toyota is making collision-avoidance gadgets standard on almost every new model.  One driver is the reduced price of the cameras and radars, but I think a bigger driver is the trustworthiness of the autonomous vehicle algorithms that can reliably sense a possible collision.

Of course, here at WANdisco the IoT is of much interest.  For all of this new streaming data to be useful, it has to be ingested, processed, and used, often at very high speeds.  That’s a challenge for traditional Hadoop architectures – but one that we’re quite prepared to meet.

SmartSVN 8.6.3 General Access Released!

We’re pleased to announce the latest release of SmartSVN, 8.6.3. SmartSVN is the popular graphical Subversion (SVN) client for Mac, Windows, and Linux. SmartSVN 8.6.3 is available immediately for download from our website.

New Features include:

– Show client certificate option in the SSL tab in Preferences

Fixes include:

– Bug reporting now suggests the email address from the license file

For a full list of all improvements and features please see the changelog.

 

Note for Mac Os X 8.6.2 users:- If you installed version 8.6.2 as a new download (rather than autoupdating) you will need to download and reinstall 8.6.3 to stop the master password window from constantly reappearing
– You will be required to enter the master password once more after the installation

Contribute to further enhancements

Many of the issues resolved in SmartSVN were raised by our dedicated SmartSVN forum, so if you’ve got an issue or a request for a new feature, head there and let us know.

Get Started

Haven’t yet started using SmartSVN? Get a free trial of SmartSVN Professional now.

If you have SmartSVN and need to update to SmartSVN 8, you can update directly within the application. Read the Knowledgebase article for further information.

An essential Git plugin for Gerrit

One of the frequent complaints about Gerrit is the esoteric syntax of pushing a change for review:

git push origin HEAD:refs/for/master

Translated, that means to push your current HEAD ref to a remote named origin and to a special review ref (for master).

If you’re a Gerrit user, you need this plugin:

https://github.com/openstack-infra/git-review

It automates some of the Gerrit syntax so now you can just run:

git review

The only problem is that when you push to a non-Gerrit repository you start to wonder why your review command doesn’t work anymore.  That’s how deeply ingrained code review is to the Gerrit workflow.

Name Node単一障害点回避 (QJMとNon-Stop Name Node)

ThinkIT Web記事で「NameNode障害によって発生するSingle Point of Failure問題を解決するソリューション」として弊社のNon-Stop Hadoopを紹介して頂きました。http://thinkit.co.jp/story/2014/11/11/5413

同様のソリューションとしてQJMもありますので、少し補足をしておきたいと思います。

QJMについてスライド1

2012年にCloudera社のTodd Lipcon氏が提案したものです。HadoopのアーキテクチャではNameNodeが単一障害点になっていたのを冗長化するものです。StandbyのNamaNodeを追加し、Journal Nodeで複数のジャーナルをとり、Zookeeperにより障害を検出し手動・自動でのフェールオーバーが可能となりました。右上図のような構成になります。

 

Non-Stop NameNodeについて

Paxos(パクソス)を拡張したActive-Activeの複製を行う仕組み(Distributed Coordination スライド1Engine: DConE)をNameNodeに組みこんでいます。これによりHSDF-6469に準拠したConsensusNodeとして複数のNameNodeが同一のメタデータを保持し同等に動作することになります。あるNameNodeが障害になっても多数決論理によりNameNodeのメタデータの更新を行うので、過半数のNameNodeが生きていれば継続稼働が可能です。右下図では5つNameNodeがあるので2つが落ちてもHadoopが止まることはありません。当該NamaNodeの障害が復旧すれば最新のメタデータまで自動的に復元されます。

QJMと比較した特長は以下の通りです。

  • 100%の稼働を、運用者に障害時・回復時の負担を掛けずに実現できます
  • 全てのNameNodeはActiveであり、またQJMで必要となるJournal、Zookeeperも不要です。リソースは100%活用されます
  • 複数NameNodeによる負荷分散が可能となり、性能向上が可能です。またシステムを止めないで拡張が可能です

更にNon-Stop HadoopはDataNodeのデータを、指定した範囲で自動的に複製する機能を提供しています。これにより以下のようなことも可能となります。

  • NameNodeがWANを跨がった別のデータセンタにあってもメタデータの一貫性は保障されます。容量の大きいDataNodeの複製は非同期に行います。遠隔地にあるデータセンタに複製が自動的に作られ、ディザスタリカバリも可能となります。
  • 異なる場所のデータセンタにその地域で発生したデータを格納し、別の場所から使用することも可能になります。例えばクレジットカード使用データは東京、NY、シンガポールのデータセンタに適宜格納し、不正検出のアプリは東京で動かすといった使い方が可能となります。

要は複数のHadoopクラスタを、仮想的に一つに見せることが可能という事です。これはクラスタが別のデータセンタに分散している場合も可能です。

NameNodeのメタデータの一貫性が保障されることで、述べてきたようなことが可能になっています。分散環境での一貫性の保障を行うのがPaxosを拡張した弊社の特許技術であるDistribution Coordination Engineです。これについては別途、紹介したいと思います。

avatar

About Kenji Ogawa (小川 研之)

WANdisco社で2013年11月より日本での事業を展開中。
以前は、NECで国産メインフレーム、Unix、ミドルウェアの開発に従事。その後、シリコンバレーのベンチャー企業開拓、パートナーマネージメント、インドでのオフショア開発に従事。