Hadoop Summit 2013

Hadoopイベントとしてもはや定着した感がある「Hadoop Summit 2013」。

hs01

早いもので、Hadoop Summitは今年で6回目の開催である。

米Yahoo!のスピンアウト会社である米Hortonworksの主催だけに、Hortonworks色が強いイベントではあるが、西海岸の最先端Hadoopを感じる良い機会である。

では、Hadoopの今を表すキーワードと共に、「Hadoop Summit 2013」全体を振り返ることとする。

 

 

Data Lake

 

hs02

Hortonworksが今回発信するメッセージは「Data Lake」。すなわち次世代データ処理基盤としてのHadoopを打ち出してきたと言える。
Hadoop界隈のキャッチアッパーには既知の事項であるが、Hadoopは既にバージョン2.0となり、分散処理フレームワークに変化があった。

従来のMap Reduceは分散処理の一つのコンポーネントとなり、代わりに「YARN」と呼ばれる分散リソース管理層が導入された。これにより、以前のMap Reduceと比較すれば、より汎用的な分散処理が可能となったと言える。
インタラクティブなデータ処理(Apache Tez)、リアルタイムなデータ処理(Storm)などMap Reduceのモデルに従わないアプリケーションがHadoop上で実現可能になったことにより、如何なるデータ形式をも格納可能であり、如何なるデータ抽出手段にもまた対応可能となった。

即ち、次世代のデータ処理基盤である。

実際にどの程度業務利用に耐えうるかは、実務で利用するのが早い。

Hadoop=Big Dataという図式であったため、Big Dataで可能なこと混同されがちであったが、Hadoopに対する過度な期待より脱却し、地に足のついた製品へと方向性を変化させ始めたと感じる。

 

Schema on Read

 

hs04

「Schema on Read」は「Schema on Write」と対となる概念と言える。少々乱暴に言えば、前者がHadoop、後者はDBMSである。

どちらが優れているというわけではない。

IBM Data Magazineでは、以下のようにSchema on Writeについて述べている。
In traditional data ecosystems, most tools (and people) expect schemas and can get right to work once the schema is described The approach is extremely useful in expressing relationships between data points .It can be a very efficient way to store “dense” data .
しかしながら、Schema on Writeで解決できない問題について以下のように述べている。
Schemas are typically purpose-built and hard to change Generally loses the raw/atomic data as a source
Requires considerable modeling/implementation effort before being able to work with the data .
If a certain type of data can’t be confined in the schema, you can’t effectively store or use it (if you can store it at all) .Unstructured and semi-structured data sources tend not to be a native fit .
(出展:http://ibmdatamag.com/2013/05/why-is-schema-on-read-so-useful/)

これまでは、データ量の増加につれ、問題が顕在化することは多々存在する。スピードと変化への柔軟性が昨今のビジネス要請であるが、理想を言えば、データストアも柔軟であるほうがより良い。

しかしながら、柔軟なデータ構造は、データの一元化が難しいという側面があり、実際利用に耐えうるケースは少ない。

企業で扱うデータ量が膨大になればなる程、スキーマの変更は業務停止と直結しかねないため、この部分は注視してゆく必要がある。

 

SQL in Hadoop

 

hs03

構造化データ抽出のためのQL言語を、構造・非構造関係なく選入するHadoopインターフェースとすることに違和感を感じる方は多いはずだ。しかし、難しく考える必要は無く、Hadoop内の構造化データ抽出のための言語だ捉えれば良い。
Map Redueceによるスループット重視の処理ではなく、低レイテンシなデータ抽出要請に応じたものである。

データ・プラットフォームを目指すHadoopとしては、QL言語は様々なデータ処理方法の一つであろうが、QL対応による既存資産/既存ツール連携など、その意義は大きい。

現在、各社ともプロプライエタリな実装であるが、QLはHive互換を謳っており、利用者側が困惑することはなさそうである。

どの仕様が今後のデファクトスタンダードになるか?予測不能ではあるが、各ディストリビュータ共QLに注力するようだ。
以上、キーワードと共に今年のHadoop Summitを振り返った。西海岸では既にHadoopはデータストアとして活用されており、この潮流にしばらく変化はないだろう。

 

LINEで送る
Share on Facebook

Cloud基盤とSaaSが専門。主力エリアはUSとアジア