連載
» 2017年02月08日 05時00分 公開

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

[嶋内翔,Cloudera株式会社]
前のページへ 1|2       

【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)。

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

今回のまとめ

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

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

筆者紹介

嶋内翔(しまうち しょう)

photo

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


前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。