(株)日立製作所研究開発グループデータマネジメント研究部の角井です。

オープンソースのデータカタログであるApache Atlasについて，2回に分けてご紹介させていただきます。第1回目となる本記事では，データカタログとしてのApache Atlasの背景と機能について，第2回目はビルドとインストールの手順についてご説明します。

1. Apache Atlasとは

Apache Atlasはオープンソースの「データカタログ¹」です。

データカタログは，DBMSやデータレイクなどに格納されているデータ資源を検索・参照できるようにするソフトウェアです。ただしデータそれ自体を格納しているわけではなく，代わりにデータ資源を活用したり管理したりするために有用な情報を抽出した，「データに関するデータ」すなわちメタデータを収集して格納しているのが特徴です²。データカタログは，データユーザやデータ管理者が，数多くのデータ資源の中から必要なデータを見つけ出すのを支援します。

Apache AtlasはApache Software Foundation(ASF)の管理下で開発されており，ライセンスはApache License 2.0で提供されます。オープンソースのデータカタログはApache Atlas以外にも存在しますが，ASFのようなオープンソース支援団体の傘下で開発され，特定のユースケースに限定されない汎用性を備え，一定の実績があるものとしてはほぼ唯一の存在です³。

※以降，Apache AtlasのことをAtlasと略記することがあります。

2. Atlasの背景とその歴史

Apache Atlasは，もともとApache Hadoopを中心とした一連のオープンソースソフトウェアからなるデータプラットフォーム，いわゆるHadoopエコシステムの中で生まれたソフトウェアです。

初期のHadoopはMapReduceモデルに基づく並列分散処理のフレームワークとして注目されましたが，同時に分散ファイルシステム(HDFS)という一面も備えています。やがてApache Hiveの登場により，HadoopがSQLライクなクエリ言語でアクセス可能なデータウェアハウスとしても使えるようになり，さらにリソース管理機能のYARNが実装されて分散処理フレームワークとしての汎用性が向上すると，Hadoopは組織内の多様なデータを対象として蓄積・加工・分析までの役割を一手に担うデータレイクを構築するためのプラットフォームと見做されるようになります。データレイクに，多様なデータ発生源に由来するデータ資源が大量に蓄積されるようになると，どんなデータがその中にあり，どのように使われているのかを把握するのが困難になります。データ資源が組織の意思決定を左右する「データ資産」となり，その重要性が増してくるにつれ，これらを漏れなく把握し管理するためのデータガバナンス(data governance)のソリューションが求められるようになります。

もう一つ，データの民主化(data democratization)という潮流があったことも見逃せません。データ資源が組織運営の根幹を支えるデータ資産になると，データが組織内の部門の壁を越えて横断的に活用されるようになり，データレイクはそのためのプラットフォームという側面も持つようになります。すると，データを活用するユーザの側からも，データレイクの中にどんなデータが格納されているのかを知りたいというニーズが生まれてきます。

こうして，Hadoopを基盤として構築されたデータレイクにあるデータ資産の管理(データガバナンス)のため，そしてユーザによるデータ活用の促進のためという二つのニーズを背景として，オープンソースのデータカタログを開発するプロジェクトが始まります。プロジェクトを主導したのは，Hadoop関連サービスやディストリビューション開発を手掛けていたHortonworksでした。開発は2014年末にスタート，2015年5月には"Atlas"と命名されてASFでインキュベーションに入り，同年7月には最初のリリースであるバージョン0.5.0をリリース。2017年6月にインキュベーション段階を卒業し，"Apache Atlas"としてASFのトップレベルプロジェクトに認定されます。

またASF傘下のオープンソースプロジェクトの進展と並行して，HortonworksのHadoopディストリビューションであるHortonworks Data Platform (HDP)には，2015年7月リリースのHDP 2.3を皮切りに，データカタログとしてAtlasがバンドルされるようになります。

一方で，Hadoopディストリビュータのもう一つの雄であったClouderaは，同社のHadoopディストリビューションであるCloudera's Distribution including Apache Hadoop (CDH)に独自開発のCloudera Navigatorというツールをバンドルしてデータカタログの機能を提供しました(こちらはプロプライエタリなソフトウェアでした)。こうしてHadoopエコシステムにおけるデータカタログのポジションには，CDHのCloudera NavigatorとApache Atlas，さらにサードパーティのデータカタログ製品群⁴が併存する状況となります。

やがてHadoopエコシステムが成熟の域に入った2018年，HortonworksとClouderaの両社は合併を発表，新生Clouderaが誕生します⁵。これを契機として，HDPとCDHは新たなHadoopディストリビューションであるCloudera Data Platform (CDP)に統合されます。このCDPではデータカタログとしてAtlasが採用されたことで⁶，AtlasはHadoopエコシステムにおけるデータカタログとして標準のポジションを得ることになりました。

オープンソースプロジェクトとしてのApache Atlasは現在に至るまで連綿と継続しており，2018年5月にはバージョン1.0.0，2019年5月にはバージョン2.0.0，そして2020年7月にはリリース版としては最新となるバージョン2.1.0をリリース，現在も機能強化が進められています。

3. Atlasが扱うメタデータ

3.1 メタデータとは

データカタログのコアとなる機能は，メタデータを収集・格納し，ユーザが参照できるようにすることです。データガバナンスの文脈におけるメタデータとは，データ資源を活用したり管理したりするために有用な情報のことを指します。データ管理のベストプラクティスを体系化してまとめた書籍，"DAMA-DMBOK: Data Management Body of Knowledge (2nd Edition)"によるメタデータの定義は次の通り(p.21)。

The data used to manage and use data is called Metadata. Because data cannot be held or touched, to understand what it is and how to use it requires definition and knowledge in the form of Metadata.

またメタデータは，データ資源のビジネス的な文脈での意味を記述する「ビジネスメタデータ」と，データ資源の格納場所やフォーマットなどITシステム上の文脈を記述する「テクニカルメタデータ」の二つに大別されます⁷。典型的には，テクニカルメタデータはソフトウェア的に自動収集が可能なもの，ビジネスメタデータはデータ管理者やユーザが登録するものです。

メタデータは，キーとバリューの組合せからなる「属性」という形を取ります⁸。例えばデータの名前であれば name: testdata，データの作成日時であれば createTime: 2021-01-01T12:34:56+09:00といった形になるでしょう。Atlasでは，データベースやテーブルといった管理対象となるデータ資源の一つ一つを「エンティティ」を呼び，登録されたエンティティにこうした属性を付与することでメタデータを格納します。

3.2 メタデータのメタモデリング

データカタログの第一の役割はメタデータを格納することにありますが，一般にデータを格納するソフトウェアには，データの入れ物の構造を定義したモデルが必要です。例えばRDBMSならばスキーマという形でデータモデルを設計します。RDBMSの基礎にはリレーショナルモデルがあり，これに基づいて個別のアプリケーションが要求するデータモデルを設計することになります。また別の例として，Unified Modeling Language (UML)はクラス・属性・メソッドといった部品を用いてソフトウェアをモデリングするための言語ですが，UMLの部品やそれらの関係も，UML自身を用いてモデルとして定義されています。

こうした「モデルを設計するためのモデル」のことを「メタモデル」と呼びます⁹。メタデータをモデリングするためのメタモデルについては，デファクトとしてオープンソース界で広く採用されているものはなく¹⁰，Atlasではメタモデルとして独自の型システムを開発し利用しています。

Atlasをデータカタログとして使うためには，この型システムに基づいてメタデータを格納するためのモデルを定義することになりますが，AtlasにはHadoopエコシステム向けに代表的なエンティティとその属性を定義したモデルが既にバンドルされているので，これをそのまま活用することができます。また，ユーザが自前で設計したモデルを登録して使用することももちろん可能です。メタモデルとしての型システムがあるおかげで，Hadoopエコシステム以外のデータストアもサポートできる柔軟性が生まれているわけです。

4. Atlasの機能

Atlasの機能について，基本機能であるメタデータの収集・登録・検索，そして付加機能として分類とラベル，グロッサリー，リニエージについて説明します。

4.1 メタデータの収集と登録

メタデータのうちテクニカルメタデータは，ソフトウェア的に自動収集することが可能です。Atlas開発の背景と経緯から，Apache HiveやApache HBaseといったHadoopエコシステムを構成するデータベースからメタデータを収集・登録するための「ブリッジ」と「フック」があらかじめ用意されています。ブリッジは，データベースからバッチ的に一括でエンティティとその属性を収集する仕組みであるのに対して，フックはデータベースの中にプラグインとしてインストールされ，エンティティが追加される(例えば新たなテーブルが追加される)のを契機としてメタデータを収集・登録する仕組みです。

またAtlasにはメタデータ登録用のインタフェースとして，同期通信のRESTful APIと，非同期通信のApache Kafkaトピックが用意されています。これらのインタフェースを使うことで，ブリッジやフックが用意されていないメタデータ源からメタデータを収集するプログラムを独自に開発することが可能となります。

一方，ビジネスメタデータの登録については，モデルに既定で定義されている description(エンティティの説明)やcomment(コメント)，owner(所有者)といった属性¹¹に，データ管理者がマニュアルでその値を書き込むという方法がありました。しかしこの方法では，これら事前にモデルに定義されている属性しか登録できないという不自由さがあります。そこでAtlasバージョン2.1.0からは，ユーザが任意の属性を追加登録してエンティティに付与できる機能(Business MetadataとCustom Attributes)が加わり，より便利になりました。

4.2 メタデータの検索

収集・登録されたメタデータは，Web UIを通して検索・参照することができます。Atlasは検索エンジンとしてApache SolrまたはElasticsearchを内蔵していますので¹²，メタデータ全体を対象とした全文検索が可能です。また，SQLライクなDSLでクエリを記述することで，エンティティの型や属性について詳細な条件を指定した検索も可能です。

また，全文検索・DSLのいずれの検索方式についても，RESTful API経由で外部のプログラムから利用することができます。

4.3 分類とラベル

モデルに事前に定義されている属性に加えて，エンティティに付加的な説明を加えるための機能として「分類」(classification)と「ラベル」があります。いずれもエンティティに対して任意の文字列¹³でタグを付ける機能で¹⁴，例えば個人情報を格納しているテーブルに"PII"(Personally Identifiable Information)というタグを付与するなどの用途が考えられます。

分類は，タグにさらにキー・バリュー型の属性を付与して内容を詳細化できたり，タグ付けする権限を持つユーザを制限できるなど，ラベルより高機能です。典型的には，分類はデータ管理者が設計して定義する「公式な」タグ，ラベルはユーザが自由に追加するカジュアルなタグ，といった使い分けが可能でしょう。

また分類には，伝播(propagation)という特徴的な機能があります。これは，あるエンティティに付与された分類を，リニエージ(後述)に従って他のエンティティにも自動的に付与するというものです。

4.4 グロッサリー

グロッサリー(glossary)は用語集のことです。一般に企業や組織には，その内部で業務に使われる特有の言葉(言葉としては一般的なものでも，業務上は特有の意味を帯びているものも含む)があります。こうした業務用語が不統一だったり，あるいは一つの用語が違った意味で使われていたりすると，部門を横断したコミュニケーションに支障をきたします。

そこで業務用語を体系化し，組織内で共通の意味を定義して管理すること，すなわち業務用語集(ビジネスグロッサリー)を作成することが，データガバナンスの上位概念としての情報ガバナンスの観点から重要になります。

ビジネスグロッサリーとデータカタログは直接関係ないように思えますが(実際，データカタログとグロッサリー管理の機能を別個の製品で提供していたベンダーもありました)，しかしデータ資源を体系的に分類する基準として，独自の分類体系を設計していたのではむしろ業務用語の不統一を助長することになってしまいます。データ資源の分類体系として，ビジネスグロッサリーを援用するのは自然な発想でしょう。

Atlasのグロッサリー機能は，用語(term)を階層構造に従って登録しておき，エンティティに対してタグのように用語を付与することで，特定の用語に結びついたエンティティを検索できるというものです¹⁵。業務用語を階層構造を持った体系として作成・運用している組織では活用できるでしょう。

4.5 リニエージ

リニエージ(lineage)，またはデータリニエージ(data lineage)¹⁶は，データの来歴情報のことです。データ資源は，その発生源から複製や加工を経て，ユーザの活用に適した内容とフォーマットになりデータストアに格納されます。こうしたデータ発生源から中間データ，最終的な格納先までに至る来歴の情報は，例えばデータにエラーが発見された場合にその原因を究明したり，データ発生源や加工の内容に変更が加わった場合にどの範囲に影響が及ぶかを分析したり(インパクト分析)といった，データ管理の上で有用な情報となります。

Atlasのブリッジやフックはリニエージを収集・登録する機能を備えており，例えばApache Hiveで CREATE TABLE ... AS SELECT 文¹⁷が実行され新たにテーブルが作成されると，フックはこれを検知してテーブルに対応する新たなエンティティを登録し，さらに SELECT の対象となった元テーブルとの間にリニエージを追加します。追加されたリニエージはWeb UIでビジュアルに表示されるので，直感的に把握することが可能です。

またリニエージの機能により，先述のようにあるエンティティに付与された分類を，そのエンティティから生成された別のエンティティに自動的に伝播させることが可能です。例えば"PII"(個人情報)のタグが付与されたテーブルから生成したテーブルにも自動的に"PII"の分類を適用する，といったユースケースが考えられます。

5. 他のソフトウェアとの連携

Atlasはそれ単体でもデータカタログとして有用ですが，Atlasに格納されているメタデータを他のソフトウェアに提供することで，さらに活用の範囲が広がります。

その一例がApache Rangerとの連携です。Apache RangerはHadoopエコシステムを対象としたデータセキュリティ管理のフレームワークで，ユーザによるデータ資源へのアクセスの可否を，データ管理者が制御することを可能にします。

このアクセス制御は，データ資源に対してユーザが実施可能な操作を定義するルールをまとめた「アクセス制御ポリシー」を設定することによって行います。その設定手段の一つとしてタグベースポリシーというものがあり，これは特定のアクセス制御ポリシーにタグとして名前を付与することで設定を容易化するものです。AtlasとRangerを連携させると，データ管理者がAtlasでエンティティに付与した分類がRangerに通知され，Rangerはその分類をタグと見做してエンティティにアクセス制御ポリシーを設定する，という一連のワークフローが実現できます。

他の例としては，サードパーティのデータカタログにはAtlasとの間でのメタデータの交換をサポートする製品もあります。またAtlasのRESTful APIを利用することで，独自のプログラムと連携させることも可能でしょう。先述した型システムも含めて，オープンソースならではの柔軟性が発揮される一面と言えます。

※次回の記事では，Apache Atlasのビルドとインストールの手順についてご説明します。

他社商品名称について

Apache，Apache Hadoop，Apache HBase，Apache Hive，Apache Kafka，Apache Solr，Hadoop，HBase，Kafkaは，Apache Software Foundationの米国およびその他の国における登録商標もしくは商標です。
Clouderaは，Cloudera, Inc.の米国およびその他の国における登録商標もしくは商標です。
UML，Unified Modeling Languageは，Object Management Group Inc.の米国およびその他の国における登録商標もしくは商標です。
Elasticsearchは，Elasticsearch B.V.の米国およびその他の国における登録商標もしくは商標です。
その他記載の会社名，製品名，サービス名，その他固有名詞は，それぞれの会社の登録商標もしくは商標です。
本文中では™，®マークは表記しておりません。

公式には"Data Governance and Metadata framework for Hadoop"と銘打たれていますが，一言で言えばデータカタログです。また，Apache Hadoop専用というわけではありません。 ↩
メタデータを管理するという点では，メタデータレジストリ(これはISO/IEC 11179での呼び方)やメタデータリポジトリ(これはDAMA-DMBOKでの呼び方)と呼ばれる分野のソフトウェアと機能的に重複する部分があります。近年のマーケティングタームとしては，よりわかりやすいデータカタログという呼称が使われることが多いようです。 ↩
オープンソース支援団体の傘下にある他のデータカタログの例としては，LF AI & Data Foundationでインキュベーション段階にあるAmundsenプロジェクトやMarquezプロジェクトがあります。 ↩
例えばAlation，Waterline Data，ZaloniといったベンダーがHadoop向けにデータカタログ製品を提供していました。 ↩
合併の完了は2019年1月。 ↩
CDHでCloudera Navigatorを利用していたユーザ向けに，NavigatorからAtlasへのマイグレーションスクリプトが提供されています。 ↩
これらに加えてプロセスメタデータ，オペレーショナルメタデータなどさらに細かく分類する流儀もありますが，ここではメタデータ類型学の追求は止めておきます。 ↩
AtlasのWeb UI上は"Properties"と表記されます。 ↩
ちなみにUMLの場合は，メタモデルのさらに上位のモデル，メタ-メタモデルとしてMeta-Object Facility (MOF)が定義されています。 ↩
デジュール標準としてISO/IEC 11179-3がありますが，オープンソースソフトウェアで採用された例は限定的なようです。 ↩
Atlasにバンドルされているモデルのうち，Asset型を継承する全てのモデルにはdescriptionとowner属性が既定で存在します。 ↩
Apache SolrとElasticsearchのいずれを使うかはビルド時に選択する必要があります。 ↩
モデルの定義に制約されないという意味では任意ですが，実際には分類のタグとして使用できる文字には制限があります。 ↩
Web UIで「分類」(Classification)はもともと「タグ」(Tags)と表記されていましたが，バージョン1.0.0から変更されました。 ↩
階層構造に従ったエンティティの分類という意味では，タクソノミー(taxonomy)を実現する機能とも言えます。実際，かつてはタクソノミーという機能名でテクニカルプレビューとして実装されていましたが，バージョン1.0.0からグロッサリーとして再実装されました。 ↩
「データ来歴」「データ系譜」「データ系統」などの訳語が当てられることもありますが，最近は訳さずカタカナで表記することが多いようです。 ↩
この種のクエリは，頭文字を取って俗にCTAS文と呼ばれたりします。 ↩

Apache Atlasことはじめ(1)