クラウドコンピューティングを前提とした大規模データ技術が利用可能となってきています。ここではBig Dataという適用分野の側面ではなく、データベース技術やアプリケーションアーキテクチャーの視点で、現在どのように技術が発展してきているかを解説します。
技術背景
大規模な分散システムは、ネットワーク、サーバ、ストレージなどのハードウェアの革新とコモディティ化、それらの運用技術の発展により利用可能となりました。その上で、大規模データ技術は、従来のRDBを中心とした技術に加えて、クラウドコンピューティングで利用可能となった大規模な分散システムの技術の台頭により、急激に発展しました。大規模データ技術の発展にはこうした背景があることは確かなのですが、一方では、Web 2.0から続くビジネス的な背景も大きく影響しています。
成熟した社会の多様化したニーズに対応するため、ユーザ参加型のサービスの提供や多様な要求の分析が不可欠になってきたからです。多様性の分析のために、多くのインターアクティブなデータの生成と収集が必要となり、リアルタームWebやM2M（Machine-to-Machine）のような環境が必要となってきたからです。
アーキテクチャーの革新
ハードウェアの革新やビジネスの進化はアプリケーションやデータアーキテクチャーの変化を促します。従来のレイヤーアーキテクチャーの論理構造や、論理的なマスターデータの統合とトランザクションデータ間の関係づけから価値を分析していく原則を守りながら、クラウドを含めて多くの物理的な形態（配置モデル）やデータベース技術を適切に導入していきます。
変わらぬアーキテクチャーの原則を守りつつ、多様化した要素技術の適切な選択と組み合わせが求められています。アーキテクトにはこれまで以上に“ぶれのない”アーキテクチャー原則の順守と、選択した要素技術の適切さに対する理由づけと説明責任が求められます。
たとえば、現在の大規模データ技術を採用する場合は、アプリケーションアーキテクチャーの各レイヤーで適切なデータモデル、データベース技術を選択しなければなりません。Webレイヤー（Webアプリケーション）では、HTML/XMLやJSONなどのメッセージの書き込みの最適化、HTTPのセッション管理、変更通知のためにイベント通知のサブスクライバー管理のためのデータモデル、データベースを選択します。MongoDB、Redis、CassandraなどのNoSQLです。バックエンドにおけるOLTPによる更新系では従来のRDBに加えて、よりトランザクション性能が高いnewSQL[1]と呼ばれるデータベースや、アプリケーションのデータモデルに合わせた分散キャッシュ技術がRDBとの間に介在した構成を検討します。分散キャッシュには、memcachedのような読み取りの性能を改善する技術に加えて、RDBへの書き込みの性能を改善し、アプリケーションのデータモデルの統一的なビューを提供するデータグリッド系の技術やインメモリデータベース[2]を検討します。
また、データの全件処理、特にI/Oの性能が求められる多重のバッチ処理にはMapReduceが新たな選択肢として加わります。MapReduceはデータインデックシングや非構造化データの前処理（ETL、クレンジング）への適用が有名ですが、より汎用的なバッチ処理のインフラ技術[3]として適用範囲が広がっています。
こうした技術の選択肢の中で、特にスケールさせるためにはデータを分割し、分散配置させることと、データの配置場所に処理を持っていくこと、つまり、シェアードナッシングのデータベース技術がアプリケーションアーキテクチャーに大きな影響を及ぼしています。
非構造化データを含めた大規模データ分析はMapReduceで実行し、その結果の集計やレポート機能にRDBを利用して分析結果の可視化をするのが現在は主流となっています。しかし、この方法は十分に全体最適化がされてなく、データ転送コストの無駄が発生してしまいます。そこで、バッチ処理部分とリアルタイムにデータベース内で処理する部分とを一体として管理するデータベース技術が登場しつつあります[4]。こうした技術が発展してくれば、またアーキテクチャーの物理構成が変わってくるはずです。
これまで、OLTPとデータウェアハウスによる情報分析では異なるワークロード特性を持つため、異なるデータベースでの処理が推奨されてきました。現実的には、基幹系と情報系を別システムで構築し、あるいは、アーキテクチャースタイルとしてCQRS（Command Query Responsibility Segregation）[5]の原則に従ってきました。しかし、更新結果をリアルタイムに分析して結果を見たいというニーズの高まりから、1つのデータベースがOLTPとデータ分析の両方を実行する要求を満たすことが求められています。技術的な批判[6]もありますが、今後はこの方面でのデータベース技術がさらに発展していくでしょう。
新しいデータタイプ、データモデルの位置づけ
一般に問題を解決するには、解決可能なサイズまで問題を分割し、それぞれの分割した問題を適切に解くアプローチを採ります。どのように問題を分割するかは、問題に依存しますし、深い経験が必要となるでしょう。ただ、ここで重要なのは、問題に対して直接的な解を求めないことです。すなわち、まず問題をその周辺の領域を含めて分析し、一般的な問題として定義します。そうした定義が分析モデルです。次に分析モデルに対して汎用的な解を当てはめます。それが設計モデルです。最後に設計モデルの実現法を実装して問題の解決を検証します。この一連の問題解決の手順を踏むことで、問題の真の要因を押さえることが可能となり、表面的な問題が時間とともに変化していったとしても、真の要因に対する汎用性の高い解を与えることができるのです。ソフトウェア開発が、分析、設計、実装という面倒な手順を踏むのは、こうした理由があるからです。
次に、分割した小さな問題の解には、適切にプログラミングパラダイムとデータモデルを選択します。たとえば、Hadoopのデータ分析用の言語としてHive[7]を考えましょう。HiveはHadoopのmapperやreducerを実装することなく、SQL類似の言語でデータ分析を実行します。つまり、Hiveはデータ分析という問題に対してHadoopという分散システムの要素技術を使い、SQL類似の関数型のプログラミングパラダイムを採用しています。また、Hadoopが利用するファイルシステムHDFSはデータをブロック単位で管理しますが、Hiveではブロックデータに対してカラム指向のデータレイアウトでアクセスできるようにデータモデルRCFile[8]を導入します。これにより、データ分析でのデータの読み取りアクセスを最適化します。ただし、新規のデータモデルの導入は、そのデータモデルを利用する開発者に対して新たな学習や開発上の制約を課してしまうことが課題です。そこで、データモデルの導入を単独で行うのではなく、それを利用するためのプログラミングパラダイムとセットにして導入します。そのプログラミングパラダイムを利用すれば、自動的に新規のデータモデルを利用して最適な実行の恩恵を得られるようにするためです。プログラミングパラダイムをSQLのようなメジャーなDSL（Domain Specific Language： ドメイン依存言語）で提供できれば、既存の知識だけで導入したデータモデルを利用することができます。
新規に導入するデータモデルには、上記のデータレイアウトによるデータアクセスの最適化の例のほかに、分散データへの操作を透過的に行い、分散データの可用性、一貫性の問題を解決する例[9]や、データへの同時性制御を最適化する振る舞いをデータモデルに隠ぺいし、OLTPでのデータアクセスのスケーラビリティを上げるためのデータモデル定義の例[10]などが存在します。
すなわち、分散システムの複雑な挙動や、並列処理における制御などの困難な問題をデータタイプやデータモデルの“裏側”に隠し、それらの機能を利用する開発者からは通常の開発言語で定義されるデータタイプやデータモデルをそのまま利用することで、既存のコンパイラやIDEを再利用可能とします。そして、必要に応じて、通常の開発言語に制約を加えたDSLを定義し、開発品質を保証するとともに、新規に導入するデータモデルの機能を利用します。
今後のデータベース技術
データタイプやデータモデルの採用による最適化、複雑さや困難な問題への対応の例は大規模データ技術の１つのアプローチを示しています。それでは、今後のデータベース技術はどのように発展していくのでしょうか？
大規模データ技術の発展の方向性を占う上で、Hadoopがどのように発展していくかを見ることが参考となると思われます。Hadoopの発展の方向性は複数の軸を持っています。それらの軸は、
- 分散した物理データ配置の制御や最適化。特に、コロケーション（関連するデータや、データと処理を同一の場所に配置）やin-database実行による最適化[11]
- メタデータ管理。特にMapR[12]に見られる間接参照の導入によるメタデータ数の爆発に対する改善や運用管理領域（データバックアップや所有者の管理など）のサポート
- 異なるワークロードの分散アプリケーション（たとえば、BSP（Bulk Synchronous Parallel）[13]やMPI（Message Passing Interface）[14]によるHPCアプリケーションなど）の分散タスクのスケジュール管理、リソース管理の統合化による最適化[15]
- MapReduceのバッチ処理と分散並列RDBとの融合
- MapReduceのリアルタイム化。ストリームデータへの対応[16]
- 開発の容易化。DSLや新しいプログラミングモデルとデータモデル、データタイプの導入[17]
すなわち、多くの軸が関連性を持ちつつそれぞれに発展の方向を模索している状況です。したがって、今後の大規模データ技術がどの方向に向かうかは明確には断言できません。しかし、より大規模なデータ処理を、より効率的に、より安価に、実行していくことでしょう。その根底には、冒頭に述べたように、成熟した社会の多様化したニーズへの対応があることを忘れてはなりません。
[1] newSQL http://blogs.the451group.com/information_management/2011/04/15/nosql-newsql-and-beyond/
[2] たとえば、GigaSpaces http://www.gigaspaces.com/
[3] Asakusa Framework http://www.asakusafw.com/
[4] Hadapt http://www.hadapt.com/
[5] CQRS http://martinfowler.com/bliki/CQRS.html
[6] M. Stonebraker, U. Çetintemel, "One Size Fits All: An Idea Whose Time Has Come and Gone", ICDE, 2005, pp. 2 - 11
[7] Hive http://hive.apache.org/
[8] Y. He, R. Lee, Y. Huai, Z. Shao, N. Jain, X. Zhang, Z. Xu, "RCFile: A Fast and Space-efficient Data Placement Structure in MapReduce-based Warehouse Systems", Proceedings of the IEEE International Conference on Data Engineering (ICDE), 2011
[9] Spark http://spark-project.org/
[10] W. E. Weihl, "Commutativity-Based Concurrency Control for Abstract Data Types", IEEE Transactions on Computers - TC , vol. 37, no. 12, 1988, pp. 1488-1505
[11] M. Y. Eltabakh, Y. Tian, F. Özcan, R. Gemulla, A. Krettek, J. McPherson, "CoHadoop: Flexible Data Placement and Its Exploitation in Hadoop", PVLDB 4(9), 2011, pp. 575-585
[12] MapR http://www.mapr.com/
[13] BSP http://en.wikipedia.org/wiki/Bulk_Synchronous_Parallel
[14] MPI http://en.wikipedia.org/wiki/Message_Passing_Interface
[15] Mesos http://www.mesosproject.org/
[16] T. Condie, N. Conway, P. Alvaro, J. M. Hellerstein, K. Elmeleegy, R. Sears, "MapReduce Online", UC Berkley Technical Report No. UCB/EECS-2009-136 http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-136.html
[17] C. Chambers, et al., "FlumeJava: easy, efficient data-parallel pipelines", Sigplan Notices - SIGPLAN , vol. 45, no. 6, 2010, pp. 363-375