Application Specific Data? It’s So 2013

Looking back at the past 10 years of software the word ‘boring’ comes to mind.  The buzzwords were things like ‘web services’, ‘SOA’.  CIO’s Tape drives 70sloved the promise of these things but they could not deliver.  The idea of build once and reuse everywhere really was the ‘nirvana’.

Well it now seems like we can do all of that stuff.

As I’ve said before Big Data is not a great name because it implies that all we are talking about a big database with tons of data.  Actually that’s only part of the story. Hadoop is the new enterprise applications platform.  The key word there is platform.  If you could have a single general-purpose data store that could service ‘n’ applications then the whole of notion of database design is over.  Think about the new breed of apps on a cell phone, the social media platforms and web search engines.  Most of these do this today.  Storing data in a general purpose, non-specific data store and then used by a wide variety of applications.  The new phrase for this data store is a ‘data lake’ implying a large quantum of every growing and changing data stored without any specific structure

Talking to a variety of CIOs recently they are very excited by the prospect of both amalgamating data so it can be used and also bringing into play data that previously could not be used.  Unstructured data in a wide variety of formats like word documents and PDF files.  This also means the barriers to entry are low.  Many people believe that adopting Hadoop requires a massive re-skilling of the workforce.  It does but not in the way most people think.  Actually getting the data into Hadoop is the easy bit (‘data ingestion‘ is the new buzz-word).  It’s not like the old relational database days where you first had to model the data using data normalization techniques and then use ETL to make the data in usable format.  With a data lake you simply set up a server cluster and load the data. Creating a data model and using ETL is simply not required.

The real transformation and re-skilling is in application development.  Applications are moving to data – today in a client-server world it’s the other way around.  We have seen this type of reskilling before like moving from Cobol to object oriented programming.

In the same way that client-server technology disrupted  mainframe computer systems, big data will disrupt client-server.  We’re already seeing this in the market today.  It’s no surprise that the most successful companies in the world today (Google, Amazon, Facebook, etc.) are all actually big data companies.  This isn’t a ‘might be’ it’s already happened.

Complete control over Hadoop data locality

Non-Stop Hadoop provides a unified data layer across Hadoop clusters in one or many locations. This unified data layer solves a number of problems by providing a very low recovery point objective for critical data, full continuity of data access in the event of failure, and the ability to ingest and process data at any cluster.

Carrying implementation of this layer to its logical conclusion, you may ask if we’ve introduced a new problem in the process of solving these others, namely, what if you don’t want to replicate all HDFS data everywhere?

Perhaps you have to respect data privacy or locality regulations, or maybe it’s just not practical to ship all your raw data across the WAN. Do you have to fall back to workflow management systems like Falcon to do scheduled selective data transfers, and deal with the delays and complexity of building an ETL-style pipeline?

Luckily, no. Non-Stop Hadoop provides a selective replication capability that is more sophisticated than what you could build manually with the stock data transfer tools. As part of a centralized administration function, for each part of the HDFS namespace you can define:

  • Which data centers receive the data
  • The replication factor in each data center
  • Whether data is available for remote (WAN) read even if it is not available locally
  • Whether data can be written in a particular data center

This solves a host of problems. Perhaps most importantly, if you have sensitive data that cannot be transferred outside a certain area, you can make sure it never reaches data centers in other areas. Further, you can ensure that the restricted part of the namespace is never accessed for reads or writes in other areas.

Non-Stop Hadoop’s selective replication also solves some efficiency problems. Simply choose not to replicate temporary ‘working’ data, or only replicate rarely accessed data on demand. Similarly, you don’t need as high a replication factor if data exists in multiple locations, so you can cut down on some local storage costs.

Selective replication across multiple clusters sharing a Nonstop Hadoop HDFS data layer: Replication policies control where subsets of HDFS are replicated, the replication factor in each cluster, and the availability of remote (WAN) reads

Selective replication across multiple clusters sharing a Nonstop Hadoop HDFS data layer: Replication policies control where subsets of HDFS are replicated, the replication factor in each cluster, and the availability of remote (WAN) reads

Consistent highly available data is really just the starting point for Nonstop Hadoop.  Nonstop Hadoop also gives you powerful tools to control where data resides, how it gets there, and how it’s stored.

By now you’ve probably thought of a problem that selective replication can help you solve.  Give our team of Hadoop experts a call to learn more.

スマートメータのデータをHadoopで解析

british gasConnected HomeはBritish Gasが開発をしているエネルギー使用をモニター・コントロールするサービス。暖房を点けたり、消したりするサービスアプリを提供している。インタネットは家庭の娯楽は大きく変えてきたが、日常生活そのものについてはまだこれからであり、3rd Partyも活用しサービスの差別化をしていくことをBritish Gasは目指している。

WANdiscoは2014年3月に100万世帯のスマートメータからデータを取得し、エネルギー使用のモニタ・コントロールを行うトライアルに参加した。収集されたリアルタイムデータを解析することで、需要パターンと供給をダイナミックにマッチングし、需要に見合う供給を行い、かつ企業および一般家庭での使用のコントロールが可能となることが実証することが目的。

リアルタイム性、コンプライアンス対応のため、Non-Stop Hadoopが導入され、100ノードのクラスタでのデータ損失、ダウンタイムを最小限にし、ストレージコストも大幅に削減することができた。

10か月のトライアルが成功裏に終わり、2倍のスケールで本番運用に入ることになった。WANdiscoは3年間のSubscription契約をUS$750KでBritish Gasと締結。

Wildcards in Subversion Authorization

Support for wildcards in Subversion authorization rules has been noticeably lacking for many years.  The use cases for using wildcards are numerous and well understood: denying write access to a set of protected file types in all branches, granting access to all sandbox branches in all projects, and so on.

So I’m very pleased to announce that WANdisco is now supporting wildcards for Subversion in our Access Control Plus product.  With this feature you can now easily define path restrictions for Subversion repositories using wildcards.

How does this work given that core Subversion doesn’t support wildcards?  Well, wildcard support is a long-standing feature request in the open source Subversion project, and we picked up word that there was a good design under review.  We asked one of the committers that works for WANdisco to create a patch that we can regression test and ship with our SVN MultiSite Plus and Access Control Plus products until the design lands in the core project.

Besides letting you define rules with wildcards, Access Control Plus does a couple of other clever things.

  • Let you set a relative priority that impacts the ordering of sections in the AuthZ file.  The order is significant when wildcards are in use as multiple sections may match the same path.
  • Warn you if two rules may conflict because they affect the same path but have a different priority.

acp-wildcard-conflictThis feature will likely be a life saver for Subversion administrators – just contact us and we’ll help you take advantage of it.

Is One Hadoop Cluster Enough?

A new report out from GigaOM analyst Paul Miller provides some insights into the question, is one Hadoop cluster enough for most Big Data needs?  It’s surprising how much attention this topic has garnered recently.  Up until a few months ago I hadn’t really thought that much about why you’d need more than a single cluster.  After all, most of the technical information about Hadoop is geared towards running everything on one cluster, especially since YARN makes it easier to run multiple applications on a single cluster.

But another recent study shows that a majority of Big Data users are running multiple data centers.  The GigaOM report dives into some of the reasons why that might be.  Workload optimization, load balancing, taking advantage of the cloud for affordable burst processing and backups, regulatory concerns – there are a host of reasons that are driving Hadoop adopters toward a logical data lake consisting of several clusters.  And of course there’s also the fact that many Hadoop deployments evolve from a collection of small clusters set up in isolation.

The report also notes that the tools for managing the flow of data between multiple clusters are still rudimentary.  DistCP, which underpins many of the ETL-style tools like Falcon, can be quite slow and error-prone.  If you only need to sync data between clusters once a day it might be ok, but many use cases are demanding near real-time roll-up analysis.

That’s why WANdisco provides active-active replication: Non-stop Hadoop lets your data span clusters and geographies.  In the interest of saving a thousand words:

nsh-ref-arch-total

Interested?  Check out some of the reasons why this architecture is attractive to Hadoop data consumers and operators.

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が可能。銀行の顧客(攻撃もふくめ)は多国籍になってきており、例えば不正検出をグローバルベースで行うことがクリティカルです。

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をベースに紹介します。

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

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.