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 ServerDiscovery 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上で実行していきます。

Releases · odpi/egeria

解凍後、下記のディレクトリに入り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のプラットフォームとサーバーをどのように管理していくか?
  • Asset Management Labs
    • Peter Profile(アナリスト)、Erin(アーキテクト)
      • Coco Pharmaceuticalのアセットのカタログを構築・管理
    • Callie Quartile(データ・サイエンティスト)
      • 必要なアセットの場所を特定して分析に使用するために、カタログを使用する
  • Information Architecture Labs
    • Erin
      • Coco Pharmaceuticalsの情報標準をセットアップする
  • Conformance Testing Labs
    • Polly Tasker(テスター)
      • Egeriaの適合テスト(conformance test)を実施し、メタデータサーバーがEgeriaのオープンメタデータプロトコルに適合するか確認する
  • Asset UI Labs
    • Callie Quartile
      • メタデータのフローを理解するために、EgeriaのUIを利用して調査を実施する

まずは、Starting up the Egeria platformsの通り、CorePlatformDataLakePlatformDev 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)
      • オープン・メタデータを統合するツールやプラットフォームのための、ドメイン固有のサービス
    • 今回は下表のように整理された
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のイメージは下図の通り
  • 1リクエスト辺りのメタデータ数の上限を設定


  • 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に連携するためのコーディングが必要

ハンズオンの詳細はこちらをご覧ください。