Google
Cloud Platform
Amazon Web Services
Microsoft Azureデータレイクハウス の相互運用性とユーザビリティ
この記事では、 相互運用性とユーザビリティ の柱のアーキテクチャ原則について説明し、レイクハウスとユーザーや他のシステムとの相互作用を参照します。 レイクハウスの基本的な考え方の1つは、レイクハウスを使用するすべてのペルソナに優れたユーザーエクスペリエンスを提供し、外部システムの幅広いエコシステムと対話できるようにすることです。
相互運用性 とは、システムが他のシステムと連携し、統合する能力です。 これは、異なるコンポーネントと製品間、場合によっては複数のベンダー間、および同じ製品の過去バージョンと将来のバージョン間の相互作用を意味します。
ユーザビリティ は、タスクを安全、効果、効率的に実行するための可能な限り最高のエクスペリエンスをユーザーに提供するシステムの特性です。
この柱の原則に従うことは、次のことに役立ちます。
一貫性のあるコラボレーション可能なユーザーエクスペリエンスを実現します。
クラウド間の相乗効果を活用します。
レイクハウスとの間の統合を簡素化します。
トレーニングとイネーブルメントのコストを削減します。
そして最終的には、価値実現までの時間を短縮できます。
相互運用性とユーザビリティ の原則
統合の標準を定義する
統合にはさまざまな側面があり、さまざまな方法で行うことができます。 ツールとアプローチの急増を回避するには、ベスト プラクティスを定義し、十分にサポートされ、推奨されるツールとコネクタの一覧を提供する必要があります。
重要なアーキテクチャ原則の1つは、緊密な統合ではなく、モジュール性と疎結合です。 これにより、コンポーネントとワークロード間の依存関係が減り、副作用が排除され、さまざまなタイムスケールでの独立した開発が可能になります。 データセットとそのスキーマをコントラクトとして使用します。 データ ラングリング ジョブ (データレイクへのデータの読み込みや変換など) などのワークロードを、付加価値ジョブ (レポート、ダッシュボード、データサイエンス特徴エンジニアリングなど) から分離します。 データ形式、データ品質、およびデータ ライフサイクルのガイドラインを含む中央データカタログを定義します。
オープンインターフェイスとオープンデータ形式を優先する
多くの場合、特定のシステム経由でのみデータにアクセスできるソリューションが開発されます。 これはベンダー ロックインにつながる可能性がありますが、そのシステムを介したデータ アクセスにライセンス料がかかる場合は、莫大なコスト要因となる可能性もあります。 オープンなデータ形式とインターフェイスを使用すると、これを回避できます。 また、既存のシステムとの統合が簡素化され、すでにツールをレイクハウスと統合しているパートナーのエコシステムが開かれます。
データサイエンスに Python や R などの オープンソース エコシステムを使用したり、データ アクセスやアクセス権の制御に Spark や ANSI SQL を使用したりすると、プロジェクトの担当者を簡単に見つけることができます。 また、プラットフォームとの間の潜在的な移行も簡素化されます。
ユースケースを実装するための障壁を下げる
データレイクのデータを最大限に活用するには、ユーザーがプラットフォーム上でユースケースを簡単にデプロイできる必要があります。 これは、プラットフォーム アクセスとデータ管理に関する無駄のないプロセスから始まります。 たとえば、プラットフォームへのセルフサービス アクセスは、中央チームがボトルネックになるのを防ぐのに役立ちます。 新しい環境をデプロイするための共有環境と事前定義されたブループリントにより、すべてのビジネスユーザーがプラットフォームをすぐに利用できるようになります。
データの一貫性と使いやすさを確保
データ プラットフォームでの重要なアクティビティは、 データの公開 と データの使用です。 出版の観点からは、データは製品として提供されるべきです。 パブリッシャーは、コンシューマーを念頭に置いて定義されたライフサイクルに従う必要があり、データはマネージド スキーマや説明などで明確に定義する必要があります。
また、消費者が異なるデータセットを簡単に理解して正しく組み合わせることができるように、意味的に一貫性のあるデータを提供することも重要です。 さらに、すべてのデータは、適切にキュレーションされたメタデータとデータリネージを備えた中央カタログを通じて、消費者が簡単に見つけてアクセスできる必要があります。
