OSSプロジェクト「Egeria」で実現するエンタープライズ規模のメタデータ・ガバナンス
OSSデータカタログをお探しのみなさま。ちまたにはLyft社製のAmundsenやLinkdIn社製のDataHub、WeWork社製のMarquezなど、一流のテックカンパニーが様々なOSSデータカタログ・プロジェクトを進めているわけですが、まだまだあるんです。今回はLinux Foundationが進めているEgeriaというプロジェクトをご紹介します。
Egeriaとは？
Egeriaは、Linux FoundationのODPiが進めているオープンなメタデータ・ガバナンスを実現するためのエンタープライズ向けのサービスです。種々のデータツールやリポジトリがシームレスにメタデータを共有・交換できるようにするために、Egeriaでは一連のAPI、データ型、フレームワーク、コネクタ、相互交換プロトコル（interchange protocol）をバンドルしています。
エコシステム全体の構造として、Automation（自動化）、Business Value（ビジネス価値）、Connectivity（接続性）の3点を柱としています。それぞれの意味は箇条書きにまとめておきます。
- Automation
- 個人個人が手作業でメタデータを運用・維持するのはコストが高い
- → Governance Server群で、メタデータの抽出と同期を自動化
- → その内、Stewardship ServerとDiscovery Serverでメタデータの管理と保存
- Business Value
- メタデータが統合された後、そのデータやサービスに対して新しいインサイトを付与
- → フェデレーテッド・クエリを使用して、各サービスへまとめてアクセスし、リネージを表現する
- Connectivity
- AutomationとBusiness Valueを実現するためには、メタデータを分類し統合する機能が不可欠
- → 異なるメタデータリポジトリ間でパイプライン（Metadata Highway）を構築し、メタデータの交換や紐付け、フェデレーションを実現
またEgeriaは、単なるメタデータ用のツールというだけではなくメタデータの標準規格として側面も強いです。Egeriaのメタデータ標準規格を各社ベンダーが製品に組み込むことによって、製品間のメタデータの受け渡しがスムーズになり、ユーザーはサイロ化することなくメタデータを管理することができるようになります。すでに、IBMやSASといった大手ベンダーがEgeriaプロジェクトに参画し、自社製品にも取り入れているみたいです。
このメタデータの標準規格は、以下の8次元に分割されています。かなり上手く抽象化されているので、データに関わる仕事をしている人は必見の図だと思います。
- 参照・出典
このEgeria、ドキュメントの量が多いため全貌を掴みづらいのが玉にキズなんですよね。通常は公式のEgeria Dojoからチュートリアルを始めるべきなのでしょうが、動画視聴って周りくどくて苦手です。
色々探してみた結果、Open Metadata LabsというDocker Composeで立ち上がる環境を発見したので、今回はこちらで肌感を掴んでいきたいと思います。
環境構築
EgeriaのGitHubから最新のバージョンをダウンロードします。当バージョンは2.10で、macOS Big Sur 11.4上で実行していきます。
解凍後、下記のディレクトリに入りdocker-composeコマンドを実行するだけです。
cd ./egeria-2.10/open-metadata-resources/open-metadata-deployment/compose/tutorials/ docker-compose -f ./egeria-tutorial.yaml up -d
セットアップ完了後、http://localhost:18888/にアクセスするとEgeriaのJupyter Labに入れます。手始めにread-me-first.ipynbを開いておきましょう。
このHands-on Labでは"Coco Pharmaceuticals"という仮想の会社を想定し、会社内のそれぞれの役割（ペルソナ）がどのようにEgeriaを使用していくのかを体験できるよう作られています。それぞれのHands-on Labで用意されているペルソナは以下の5人です。
- Administration Labs
- Gary Geeke（ITインフラのリーダー）
- Egeriaのプラットフォームとサーバーをどのように管理していくか？
- Gary Geeke（ITインフラのリーダー）
- Asset Management Labs
- Peter Profile（アナリスト）、Erin（アーキテクト）
- Coco Pharmaceuticalのアセットのカタログを構築・管理
- Callie Quartile（データ・サイエンティスト）
- 必要なアセットの場所を特定して分析に使用するために、カタログを使用する
- Peter Profile（アナリスト）、Erin（アーキテクト）
- Information Architecture Labs
- Erin
- Coco Pharmaceuticalsの情報標準をセットアップする
- Erin
- Conformance Testing Labs
- Polly Tasker（テスター）
- Egeriaの適合テスト（conformance test）を実施し、メタデータサーバーがEgeriaのオープンメタデータプロトコルに適合するか確認する
- Polly Tasker（テスター）
- Asset UI Labs
- Callie Quartile
- メタデータのフローを理解するために、EgeriaのUIを利用して調査を実施する
- Callie Quartile
まずは、Starting up the Egeria platformsの通り、CorePlatform、DataLakePlatform、Dev Platformの3つのサーバーがactiveになっているかどうか、以下のコマンドで確認します。
%run common/environment-check.ipynb
Checking OMAG Server Platform availability...
Core Platform is active
Checking OMAG Server cocoMDS2
... cocoMDS2 needs configuring
Checking OMAG Server cocoMDS3
... cocoMDS3 needs configuring
Checking OMAG Server cocoMDS5
... cocoMDS5 needs configuring
Checking OMAG Server cocoMDS6
... cocoMDS6 needs configuring
Data Lake Platform is active
Checking OMAG Server cocoMDS1
... cocoMDS1 needs configuring
Checking OMAG Server cocoMDS4
... cocoMDS4 needs configuring
Checking OMAG Server cocoView1
... cocoView1 needs configuring
Dev Platform is active
Checking OMAG Server cocoMDSx
... cocoMDSx needs configuring
Done.
全サーバーがneeds configuringとなっている通り、ハンズオンを始める前に初期セットアップが必要です。
初期セットアップ
早速、Open Metadata and Governance (OMAG) ServerというEgeriaの中核サーバー群（Cohort）の初期設定を行っていきます。別のノートブックConfiguring Egeria Servers Labに書かれてある手順通りにコードを実行していきましょう。
ここで新しく出てきたCohort Membersとは、Peer-to-Peerでメタデータの保存・交換を行うOMAGサーバー群のことを指します。"Cohort"は日本語で「似た性質を持つ集団」といった意味合いがあります。Cohort Membersは3タイプに分けることができます。
- Metadata Server
- Egeria純正のメタデータ・リポジトリ
- OMAGサーバー群のうち、少なくとも一つは必要
- Egeriaの機能を直接使いたいユーザーや、3rdパーティー・ツールのメタデータとのギャップを埋めたい時に重宝
- Metadata Access Point
- メタデータ・リポジトリは持たない
- フェデレーテッド・クエリでCohortに接続している他のリポジトリからメタデータを取得・保存ができる
- Repository Proxy
- 3rdパーティーのメタデータサーバーと接続する
Cohort Memberにどのサーバーを使用するかは、既存の環境や要件に合わせて自身で登録することができます。Cohort Memberとして構成するメリットは、例えばCohort Memberは他のMemberのメタデータの更新状況をTopicを通して同期することができたり、あるOMAGサーバーがCohortから離脱した時、他のOMAGサーバーへ自動で登録解除のリクエストを飛ばせたりすることができます。下図は、OMAGサーバーが連携するイメージです。
さて、このハンズオンのITインフラのGaryは、会社のアセットに合わせて以下のようにCohort Memberを決定しました。
- cocoMDS1 (Data Lake Operations)
- データレイクのデータを管理するメタデータサーバー
- cocoMDS2 (Governance)
- ガバナンスチームがガバナンス・プログラムを実施するためのメタデータサーバー
- cocoMDS3 (Research)
- 新しい治療法を開発しているリサーチチーム用のメタデータサーバー
- cocoMDS4 (Data Lake Users)
- 一般ビジネスユーザーやエクゼクティブチームがデータレイクのデータにアクセスするための、メタデータ・アクセスポイント
- cocoMDS5 (Business Systems)
- 部署横断のデータの移動を管理する既存のETLツールに接続するための、リポジトリ・プロキシ
- ビジネスシステムからデータレイクへのデータ・リネージを表現するためにも重要
- cocoMDS6 (Manufacturing)
- 倉庫や製造、物流チームが使用するメタデータサーバー
- cocoMDSx (Development)
- ソフトウェア開発チームが使用するメタデータサーバー
- cocoEDGEi (Manufacturing sensors edge node servers)
- 収集されたセンサーデータをカタログ化する、メタデータサーバー
さらに、ユーザーインターフェースやメタデータ処理の自動化用に以下の3つのサーバーを追加しました。
- cocoView1
- 稼働中のサービスを可視化する
- exchangeDL01
- 3rdパーティーとメタデータを自動で交換するためのデーモン
- governDL01
- エコシステム上のすべてのメタデータの監視・検証・訂正・価値付加といったガバナンス機能を実行する
まとめると以下のような構成です。
そしてこれらのサーバーがどのCohortに属するかを以下のように分類しました。
- cocoCohort
- ビジネスを稼働・連携・管理するための全てのサーバーを含めた本番環境
- devCohort
- 開発チームが新しい機能を構築・テストするための開発環境
- 開発中のソフトウェアコンポーネントやソフトウェア・ライフサイクルの管理をメタデータで示す
- iotCohort
- 製造システム内でのセンサーやロボットを管理する
- センサーやロボットから生成されたメタデータのみ、製造チームやガバナンスチームが扱う
Cohortの設計は以上です。以降、ノートブック上のコードを実行していくので、ざっくりと概要をまとめます。
- Apache Kafkaの接続情報の定義
- 先ほど触れたTopicは、内部ではApache Kafkaのトピックがデフォルト
- 各Cohort Memberが、どのOpen Metadata Access Services (OMAS)にアクセスできるか整理
- Open Metadata Access Services (OMAS)
- オープン・メタデータを統合するツールやプラットフォームのための、ドメイン固有のサービス
- 今回は下表のように整理された
- Open Metadata Access Services (OMAS)
| Access Service | cocoMDS1 | cocoMDS2 | cocoMDS3 | cocoMDS4 | cocoMDS5 | cocoMDS6 | cocoMDSx | cocoEDGEi |
|---|---|---|---|---|---|---|---|---|
| asset-catalog | Yes | Yes | Yes | Yes | No | Yes | Yes | No |
| asset-consumer | Yes | Yes | Yes | Yes | No | Yes | Yes | No |
| asset-owner | Yes | Yes | Yes | No | No | Yes | Yes | No |
| community-profile | Yes | Yes | Yes | Yes | No | Yes | Yes | No |
| glossary-view | Yes | Yes | Yes | Yes | No | Yes | Yes | No |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| data-science | No | No | Yes | Yes | No | Yes | Yes | No |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| subject-area | No | Yes | Yes | No | No | Yes | Yes | No |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| governance-program | No | Yes | No | No | No | No | No | No |
| data-privacy | No | Yes | No | No | No | No | No | No |
| security-officer | No | Yes | No | No | No | No | No | No |
| asset-lineage | No | Yes | No | No | No | No | No | No |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| discovery-engine | Yes | No | Yes | No | No | Yes | Yes | No |
| governance-engine | Yes | Yes | Yes | No | No | Yes | Yes | No |
| asset-manager | Yes | No | Yes | No | No | Yes | Yes | No |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| data-engine | Yes | No | No | No | No | Yes | No | Yes |
| data-manager | Yes | No | No | No | No | Yes | No | Yes |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| it-infrastructure | No | Yes | No | No | No | Yes | Yes | No |
| project-management | No | Yes | Yes | No | No | Yes | Yes | No |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| software-developer | No | No | No | No | No | No | Yes | No |
| devops | No | No | No | No | No | No | Yes | No |
| digital-architecture | No | No | No | No | No | No | Yes | No |
| design-model | No | No | No | No | No | No | Yes | No |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
- REST API用のURLを定義
- メタデータを保存するデータベースの選択
- in-memory repository: 一時的な保存などテスト用に使える ←今回はこちらを選択
- local graph repository: 永続的な保存用
- Open Metadata Security Connectorの選択
- Open Metadata Security
- 各組織で異なるセキュリティ要件を満たすために、Connecterを通した粒度の細かい権限管理を実現する
- Open metadata platform security connector
- OMAG Serverに限らないプラットフォーム・サービスへのアクセス制御
- 新規サーバーの作成・開始・停止といった管理者権限も含む
- Open metadata server security connector
- OMAG Serverの固有のサービスへのアクセス制御
- サーバーそれ自体や、サーバー内のサービス、特定のアセットや接続情報などを含む
- Connectorのイメージは下図の通り
- Open Metadata Security
- 1リクエスト辺りのメタデータ数の上限を設定
- OMAGサーバーの個別設定
- 定義したパラメータやアクセス権限を各OMAGサーバーに反映させる
- cocoMDS1 (Data Lake Operations metadata server)
- cocoMDS2 (Governance metadata server)
- cocoMDS3 (Research)
- これまでリサーチチームは、会社全体のシステムから組織的に切り離されていた
- 今回でエコシステムの一部となり、パーソナライズされた薬や治療法を開発できるようになるので、組織的・ビジネス的には大きな転換点
- cocoMDS4 (Data Lake Users)
- cocoMDS5 (Business Systems)
- cocoMDS6 (Manufacturing)
- cocoMDSx (Development)
- exchangeDL01 (Integration Daemon)の設定
- Integration Connector
- Integration Daemonが3rdパーティ製ツールと接続するためのコネクタ
- 今回はローカルファイルやディレクトリを扱うData Files Monitor Integration ConnectorとData Folder Monitor Integration Connectorを選択
- 構成要素の図は下記
- 2021年5月現在で提供されているコネクタなど
- Data Files Monitor Integration Connector
- Data Folder Monitor Integration Connector
- PostgreSQL Database Integration Connector
- Apache Ranger Integration Connector
- CSV Discovery Service
- Sequential Discovery Pipeline
- Generic Element Watchdog Governance Action Service
- Generic Folder Watchdog Governance Action Service
- Move/Copy File Provisioning Governance Action Service
- Origin Seeker Remediation Governance Action Service
- Kafka Open Metadata Topic Connector
- JanusGraph OMRS Repository Connector
- In-memory OMRS Repository Connector
- Read-only OMRS Repository Connector
- Apache Atlas OMRS Repository Connector
- IBM Information Governance Catalog (IGC) OMRS Repository Connector
- Console Audit Log Connector
- slf4j Audit Log Connector
- File Audit Log Connector
- Event Topic Audit Log Connector
- Cohort Registry File Store Connector
- Open Metadata Archive File Connector
- Avro File Connector
- Basic File Connector
- CSV File Connector
- Data Folder Connector
- Integration Connector
- governDL01 (Governance Engine Hosting Server)の設定
- Asset Analysis
- アセットの実世界に対応するモノを分析し、アノーテーションを定義したレポートを作成する
- 今回はAssetDiscoveryとAssetQualityを使用
- Governance Action
- メタデータやそれの実世界に対応するモノ（real-world counterparts）を監視・評価・維持する
- 今回はAssetGovernanceを使用
- 構成要素の図は下記
- Asset Analysis
- View ServerとView Servicesの設定
- 最後に、設定をサーバーにデプロイして反映
以上でOMAGサーバーの初期セットアップは完了です。read-me-first.ipynbに戻り、%run common/environment-check.ipynbを2回ぐらい実行して以下のログが表示されるか確認しましょう。
%run common/environment-check.ipynb
Checking OMAG Server Platform availability...
Core Platform is active
Checking OMAG Server cocoMDS2
... cocoMDS2 is configured
... cocoMDS2 is active - ready to begin
Checking OMAG Server cocoMDS3
... cocoMDS3 is configured
... cocoMDS3 is active - ready to begin
Checking OMAG Server cocoMDS5
... cocoMDS5 is configured
... cocoMDS5 is active - ready to begin
Checking OMAG Server cocoMDS6
... cocoMDS6 is configured
... cocoMDS6 is active - ready to begin
Data Lake Platform is active
Checking OMAG Server cocoMDS1
... cocoMDS1 is configured
... cocoMDS1 is active - ready to begin
Checking OMAG Server cocoMDS4
... cocoMDS4 is configured
... cocoMDS4 is active - ready to begin
Checking OMAG Server cocoView1
... cocoView1 is configured
... cocoView1 is active - ready to begin
Dev Platform is active
Checking OMAG Server cocoMDSx
... cocoMDSx is configured
... cocoMDSx is active - ready to begin
Done.
全サーバーが設定済みになっています。
次のステップ
セットアップだけでかなり長くなってしまったので、実際のハンズオンは別記事に分けました。ただ、ハンズオンを見ても何やってるのかよくわからないと思うので、所感のメモを先に書いておきます。
- マイクロサービスを謳うだけあって、サーバーをかなり細かくセットアップできる
- あらゆるDBやシステムの抽象化レイヤーとして介在する
- Egeriaの標準規格に準拠しているサービスの場合は、Egeriaのプラットフォームとシームレスに連携可能
- 準拠していないサービスの場合は、そのサービスの仕様とEgeriaをマッピングで繋げたような層を別途追加する
- 分散型データカタログ
- それぞれの組織・部署で最適なサービスやデータカタログを使ってもらい、それをEgeriaが裏で連携させる、といった仕組み
- そのため、「一つのデータカタログを立ててガバナンスを統合しよう！」という用途ではない
- 気軽に使えない
- 他のOSSや製品のデータカタログと異なり、インストールしたらそのまま使えるというわけではない
- Egeriaの仕様を理解し、自社の組織に最適化するようサーバーをセットアップし、組織ごとに使っているサービスの仕様をEgeriaに連携するためのコーディングが必要
ハンズオンの詳細はこちらをご覧ください。
![[アップデート]Amazon DataZoneで生成系AIベースのビジネスデータカタログ強化のための機能が発表されました（プレビュー） #AWSreinvent](https://devio2023-media.developers.io/wp-content/uploads/2023/11/eyecatch_reinvent-2023-newservice-update.png)
