Apache Atlasことはじめ(1)

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

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

# 1. Apache Atlasとは

[Apache Atlas](https://atlas.apache.org/)はオープンソースの「データカタログ[^genre]」です。

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

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

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

[^genre]: 公式には"Data Governance and Metadata framework for Hadoop"と銘打たれていますが，一言で言えばデータカタログです。また，Apache Hadoop専用というわけではありません。

[^datacatalog]: メタデータを管理するという点では，メタデータレジストリ(これは[ISO/IEC 11179](https://en.wikipedia.org/wiki/ISO/IEC_11179)での呼び方)やメタデータリポジトリ(これは[DAMA](https://www.dama.org/)-DMBOKでの呼び方)と呼ばれる分野のソフトウェアと機能的に重複する部分があります。近年のマーケティングタームとしては，よりわかりやすいデータカタログという呼称が使われることが多いようです。

[^others]: オープンソース支援団体の傘下にある他のデータカタログの例としては，[LF AI & Data Foundation](https://lfaidata.foundation/)でインキュベーション段階にある[Amundsenプロジェクト](https://www.amundsen.io/)や[Marquezプロジェクト](https://marquezproject.github.io/marquez/)があります。

# 2. Atlasの背景とその歴史

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

初期のHadoopはMapReduceモデルに基づく並列分散処理のフレームワークとして注目されましたが，同時に分散ファイルシステム(HDFS)という一面も備えています。やがて[Apache Hive](https://hive.apache.org/)の登場により，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，さらにサードパーティのデータカタログ製品群[^thirdparties]が併存する状況となります。

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

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

[^thirdparties]: 例えばAlation，Waterline Data，ZaloniといったベンダーがHadoop向けにデータカタログ製品を提供していました。

[^merger]: 合併の完了は2019年1月。

[^navigator]: CDHでCloudera Navigatorを利用していたユーザ向けに，NavigatorからAtlasへのマイグレーションスクリプトが提供されています。

# 3. Atlasが扱うメタデータ

## 3.1 メタデータとは

データカタログのコアとなる機能は，メタデータを収集・格納し，ユーザが参照できるようにすることです。データガバナンスの文脈におけるメタデータとは，データ資源を活用したり管理したりするために有用な情報のことを指します。データ管理のベストプラクティスを体系化してまとめた書籍，"[DAMA](https://www.dama.org/)-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システム上の文脈を記述する「テクニカルメタデータ」の二つに大別されます[^typology]。典型的には，テクニカルメタデータはソフトウェア的に自動収集が可能なもの，ビジネスメタデータはデータ管理者やユーザが登録するものです。

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

[^typology]: これらに加えてプロセスメタデータ，オペレーショナルメタデータなどさらに細かく分類する流儀もありますが，ここではメタデータ類型学の追求は止めておきます。

[^attribute]: AtlasのWeb UI上は"Properties"と表記されます。

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

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

こうした「モデルを設計するためのモデル」のことを「メタモデル」と呼びます[^uml]。メタデータをモデリングするためのメタモデルについては，デファクトとしてオープンソース界で広く採用されているものはなく[^metamodel]，Atlasではメタモデルとして独自の[型システム](https://atlas.apache.org/index.html#/TypeSystem)を開発し利用しています。

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

[^uml]: ちなみにUMLの場合は，メタモデルのさらに上位のモデル，メタ-メタモデルとして[Meta-Object Facility](https://www.omg.org/mof/) (MOF)が定義されています。

[^metamodel]: デジュール標準としてISO/IEC 11179-3がありますが，オープンソースソフトウェアで採用された例は限定的なようです。

# 4. Atlasの機能

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

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

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

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

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

[^description]: Atlasにバンドルされているモデルのうち，`Asset`型を継承する全てのモデルには`description`と`owner`属性が既定で存在します。

## 4.2 メタデータの検索

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

![全文検索](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1238846/339b31f4-5b65-1ccc-9b9d-9e19e0a8362c.png "全文検索:"address"を含むエンティティを検索")
![DSLによる検索](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1238846/713f1300-4b83-19a0-3113-1fb1d8761c83.png "DSLによる検索:名前が"sales*"でTable型のエンティティを検索")

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

[^search]: Apache SolrとElasticsearchのいずれを使うかはビルド時に選択する必要があります。

## 4.3 分類とラベル

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

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

![分類](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1238846/ac5cec04-782d-6949-af4d-b8cb9a0782b9.png "分類:"PII"とタグ付けされたエンティティ")

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

[^string]: モデルの定義に制約されないという意味では任意ですが，実際には分類のタグとして使用できる文字には制限があります。

[^tags]: Web UIで「分類」(Classification)はもともと「タグ」(Tags)と表記されていましたが，バージョン1.0.0から変更されました。

## 4.4 グロッサリー

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

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

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

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

[^taxonomy]: 階層構造に従ったエンティティの分類という意味では，タクソノミー(taxonomy)を実現する機能とも言えます。実際，かつてはタクソノミーという機能名でテクニカルプレビューとして実装されていましたが，バージョン1.0.0からグロッサリーとして再実装されました。

## 4.5 リニエージ

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

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

![リニエージの表示](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1238846/6e38ea69-6bff-7de5-ba42-c35dd8d7c089.png "リニエージの表示")

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

[^lineage]: 「データ来歴」「データ系譜」「データ系統」などの訳語が当てられることもありますが，最近は訳さずカタカナで表記することが多いようです。

[^ctas]: この種のクエリは，頭文字を取って俗にCTAS文と呼ばれたりします。

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

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

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

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

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

※[次回の記事](https://qiita.com/kkakui/items/1b03be81c010ae5b1fc7)では，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.の米国およびその他の国における登録商標もしくは商標です。
- その他記載の会社名，製品名，サービス名，その他固有名詞は，それぞれの会社の登録商標もしくは商標です。
- 本文中では™，®マークは表記しておりません。