ビッグデータ基盤の本番環境設計──セキュリティ管理とデータ管理を考察する：「ビッグデータプロジェクト」の進め方（4）（2/2 ページ）

本連載は、「ビッグデータプロジェクトの“進め方”」を業務視点／ビジネス視点の両面から理解し、具体的に実践していくためのナレッジアーカイブです。今回は、ビッグデータ基盤における本番環境の設計で考慮すべき「セキュリティ管理」と「データ管理」の項目を解説します。

[嶋内翔，Cloudera株式会社]

【4】データ管理

　データ管理とは、データが何者であり、どのような品質のものであり、どのように作成されたのか、などのメタデータを管理することを指します。ここでは、HDFSのディレクトリ設計とDBのスキーマ設計、ビジネスメタデータとリネージの管理の3つに分けて説明します。

　DBと記載していますが、ここではRDBMSのDBではなく、SQLエンジンなどが活用するHadoop上のスキーマを指していることに注意してください。

HDFSのディレクトリ設計

　NASと同様に、構造的なディレクトリ設計にしないと、どこにどんなデータがあるかが分からなくなります。ビッグデータ基盤は多数のシステムが相乗りすることを前提としているので、ディレクトリ設計はより一層重要になってきます。

　ディレクトリ設計に絶対の正解はありませんが、全くアイデアのない企業に対して、筆者は以下のような構成を提案しています。

	/raw/<ドメイン名>/
		/www.example.com/accesslog
		/www.data.go.jp/cao/pdf
	/refined/<ユースケース名>/
		/public
		/master
		/meta
		/systemA
		/systemB
	/user/<ユーザ名>/

推奨しているディレクトリ設計

　rawディレクトリは、全ての生データが投入されるディレクトリです。例えばwebのアクセスログや、未整理の転送データなどです。

　第2階層のディレクトリはデータソースのドメインとします。これによって、どこからデータが流れ込んできたのかが明確になります。

　このデータをETL処理によって変換し、refined（精製済み）ディレクトリに保存します。データを活用するユーザーはこのディレクトリにアクセスします。

　refined以下のディレクトリはデータの属性によって分類するといいでしょう。例えば、公開データであればpublicに、システムAのデータであればsystemAなどにします。

　そして、userディレクトリも作成しておきます。これがあれば、ユーザーがアドホックに分析をしたりデータ活用したりするときに役立ちます。想定される主なユーザーはデータサイエンティストでしょうが、データドリブンな組織作りが進んでいけば、いずれ社内の全ユーザーがアクセスする日も来るでしょう。このuserディレクトリはデフォルトで作成されるため、意識して作成する必要はありません。

DBのスキーマ設計

　DBのスキーマ設計も絶対的な正解はありませんが、例えば以下のような構成が考えられます。

	default（デフォルトDB）
	systemA
	user001

推奨しているDBのスキーマ設計

　デフォルトDBであるdefaultは、一時的に作成したいテーブルなどのためにとっておきます。

　システムごとに個別のスキーマが必要な場合は、systemAなど個別にDBを作成しておきます。

　データサイエンティストなどのヘビーユーザーは自分のDBを欲しがるかもしれません。彼らのために専用のDBを用意してあげてもいいでしょう。

ビジネスメタデータ

　HDFSのディレクトリやDBのスキーマ設計をうまく行ったとしても、これだけではビジネス上のメタデータを表すことはできません。

　ビジネスメタデータとは、「業務の上での文脈」という意味となります。例えば、何度か例を出してきた「systemA」という名前は、「これをシステムAのデータとします」という説明がなければ、それが何を意味するかを理解できません。「systemAと書いてあるけれど、実は統合されたシステムBのデータも入っています」ということもあり得るのです。

　データの品質などもビジネスメタデータに属します。データが一時的に作成されたものなのか、それとも単なるバックアップで最新のデータとずれているのか、などの情報はテーブル名などからは判別できません。

　さらに、データの出どころも重要です。単に「営業集計データ」と書いてあっても、それが本当に正しいデータソースから取り出したものなのかは証明できません。実は最新のデータではない、古いバックアップデータに対してクエリを実行したものだとしたら、データを正しく分析できません。こうした情報を管理することも必要です。

　なお、これらの情報はMicrosoft ExcelのスタイルシートやWikiなどで管理することも可能ですが、その管理は煩雑になるために、かなり苦しい運用となってしまうでしょう。ちなみに、Clouderaが提供するCloudera Navigatorには、こうしたメタデータを管理するための機能と、データの流れと出どころを可視化するデータリネージの機能を備えています（図2）。

図2　Cloudera Navigatorに備わるデータリネージ機能

今回のまとめ

　今回は、非機能要求という観点で見たPoC環境と本番環境の違いと、本番環境の設計で考慮すべき4項目として「クラスタ管理」「リソース管理」「セキュリティ管理」「データ管理」を挙げ、リソース管理を除いた3つの項目の詳細を解説しました。

　次回は、「データの投入」から「アプリケーションの開発」「システムのリリース」までを説明していきます。

筆者紹介

嶋内翔（しまうち しょう）

Cloudera株式会社所属。京都大学工学部卒業後、NECでエンタープライズOSSのSI支援業務に従事。2011年にClouderaの最初の日本人社員として入社。サポートエンジニアとして3年務めた後、セールスエンジニアとしてHadoopを中心としたビッグデータ基盤に関する豊富な経験を積む。監訳書に「Apache Sqoop クックブック」。