Our Migration Journey from Hive metastore to Unity Catalog
によって Anup Segu による投稿
This blog is authored by Anup Segu, Co-Head of Data Engineering at YipitData
Original Blog : YipitData leverages Databricks Unity Catalog to Scale Data Services
翻 訳： junichi.maruyama
YipitDataは、Lakehouseに保存されている15ペタバイト以上の代替データを分析することで、クライアントに日々の市場洞察を提供しています。同社のデータ製品とサービスは、時計仕掛けの正確さと効率でデータ分析を活用する同社の複数のビジネスユニットによって、トップクラスの金融機関や企業から信頼を得ています。同社の内部データプラットフォームでは、200人以上のデータチームが、データエンジニアリングが直接関与することなく、毎日2000以上のETLパイプラインを通じて、大小さまざまなデータセットを独立して処理することができます。YipitDataは、データ運用をさらに拡大するために、メタストアサービスとしてDatabricks Unity Catalogを活用し、堅牢なデータガバナンスを提供するとともに、Lakehouseにある15万以上のテーブルの価値と利用率を高めています。ユニティカタログを通じて、YipitDataはアクティブなデータセットと非アクティブなデータセットを可視化し、BI統合のパフォーマンスを向上させ、クライアントにデータを提供する新しいチャネルを開拓しています。
このブログ記事では、Hiveメタストアの使用からUnity Catalogの採用までの道のりを紹介します。また、Lakehouseアーキテクチャの中心的存在としてUnity Catalogを導入して以来、私たちが経験した数々の利点についても説明します。
さらに詳しく知りたい方は、YipitDataがData + AI Summit 2023で発表するプレゼンテーションをご覧ください。
ここ数年、YipitDataはその組織を3倍に拡大し、数多くのデータ製品を通じて100以上の企業やセクターをカバーするようになりました。この間、複数のチームや部署が設立され、様々な独自のビジネス要件が存在するようになりました。あるチームは目的を達成するために幅広いデータアクセスを必要とし、他のチームは内部分析を安全に行うために隔離された環境を必要としています。データエンジニアリング部門とデータプラットフォームが一元化されているため、多くのビジネスチャンスをサポートすることは、技術的な課題となっていました。
Unity Catalogを導入する前、YipitDataのLakehouseは、データ資産を管理するために、クラウドプロバイダーを通じてロールベースのアクセスモデルを持つHiveメタストアに依存していました。設立当初は分かりやすいアーキテクチャでしたが、会社の拡大とともに、プラットフォームを管理するために必要な役割の数が20倍に増えました。新しいチームやプロジェクトの立ち上げは、複雑なインフラ展開のプロセスとなり、製品開発を停滞させることになりました。さらに、データセットが使用されていなかったり、権限の問題で重複していたりして、プラットフォーム利用者を混乱させ、データプラットフォームに負担をかけることになりました。メタストアには非常に多くのテーブルがあり、基礎となるメタデータ操作がタイムアウトするため、多くのBIツールが機能せず、顧客にリッチでインタラクティブなデータ体験を提供するための努力を阻害していました。
さらに、私たちのクライアントの多くは、異なるクラウドで運用されていたり、Hiveメタストアとの統合がうまくいかない様々なデータスタックを使用しています。そのため、当社のデータチームは、異なるクライアントのデータをspark以外の環境に複製し、そこで後処理を行う必要がありました。そのため、ストレージコストの増加やパフォーマンスのボトルネックに繋がっていました。
YipitDataのデータエンジニアリング部門は、このアーキテクチャが実行不可能であることを認識し、確立する新しいデータガバナンスソリューションを探しました：
Databricksでデータプラットフォームの上記のアーキテクチャのニーズを確認したところ、Unity Catalogは、既存のLakehouseのセットアップにプラグインしながら、きめ細かいアクセスコントロールAPIを提供するため、その機能性においてうまく調和していました。HiveメタストアとLakehouseで管理されているUnity Catalogのデータを同時にクエリできるため、Unity Catalogを起動することは、プラットフォームのほとんどのユーザーにとって苦痛ではありませんでした。時間の経過とともに、チームはすべてのデータ分析にUnity Catalogを完全に利用するようになり、データプラットフォームはHiveメタストアの代わりにUnity Catalogへのクエリーを徐々に切り替えていきました。
移行後、チームはデータベースとパイプラインをUnity Catalogの個別のカタログに割り当てたデータメッシュパラダイムで運用し、ビジネスユニット間のデータ資産の所有権と期待値をDatabricks UIで透明化することができるようになりました。Unityカタログは、デルタテーブルのコピーを1つ保持し、BIツール、DBSQL、Delta Sharingに同時に接続できるため、データ共有の取り組みもブロックされなくなりました。これにより、顧客は以前よりもシンプルな方法で当社の分析を利用できるようになり、社内ではそのような経験のためのデータ準備をリーン、パフォーマンス、およびオープンスタンダードとの一貫性 を保つことができるようになりました。
移行完了後、以下のような効果が確認されました：
Unity Catalogは、ガバナンスの向上、データセットの利用率の向上、外部システムやクライアントからのデータへのアクセスを配慮した形で実現しました。Unity Catalogのメタストアサービスは、テーブルメタデータのレイテンシーがミリ秒レベルという高い性能を持ち、これにより15万を超えるテーブルを整理し、効果的に権限を割り当てることができるようになりました。これにより、以前のRBACアーキテクチャにあったカスタムクラウド基盤リソース（ロール、バケット、バケットポリシー）のうち、～70％が廃止されました。データエンジニアは、Databricks UIとREST APIを使用して、より簡単にデータアクセスをプロビジョニングできるようになり、ビジネスユニットの目標達成に向けてより早くブロックを解除することができます。チームはUnityカタログでデータセットを発見し、自動生成された系統グラフを見ることで、重複するテーブルの統合や未使用のテーブル/テーブルカラムの削除を行うことができるようになりました。このデータレイクのクリーンアップにより、クラウドストレージのコストと計算コストも削減されています。さらに、YipitDataのデータ製品は、BIツールやDelta Sharingを利用したインタラクティブな分析でアクセスできるようになり、データアクセスや取り込みのボトルネックに多大な時間を費やすことなく、お客様が当社からより多くの価値を得られるようになりました。
YipitDataのデータエンジニアリング部門は、メタストアとアクセス管理サービスとしてUnity Catalogを採用し、データプラットフォームへの投資を継続することで、分析サービスの拡大に伴う成功に向けた位置付けに興奮しています。YipitDataは2023 Data + AI Summit に 参加し、Unity Catalogを採用するまでの道のり、ベストプラクティス、そしてデータプラットフォームとLakehouseアーキテクチャの将来について詳しく紹介します。
ブログを購読して、最新の投稿を受信トレイにお届けします。