データ抽出からウェアハウスまで: AWS 向け ETL ツールの力を解き放つ

ETL は、抽出、変換、ロードの略です。 ETL ツールは、さまざまなソースからデータを抽出し、ターゲット システムまたはデータ モデル要件に適した中間形式に変換します。そして最後に、ターゲット データベース、データ ウェアハウス、さらにはデータ レイクにデータを読み込みます。

15 年から 20 年前、ETL という用語が何であるかを理解しているのはほんの一部の人だけだった頃のことを思い出します。さまざまなカスタム バッチ ジョブがオンプレミス ハードウェアでピークを迎えたとき。

多くのプロジェクトが何らかの形式の ETL を実行していました。たとえ知らなかったとしても、ETL という名前を付ける必要があります。その間、私が ETL プロセスを含む設計を説明したり、それらを呼び出してそのように説明したりするたびに、それはほとんど別世界のテクノロジのように見え、非常に珍しいものでした。

しかし今日では状況が異なります。クラウドへの移行が最優先事項です。そして ETL ツールは、ほとんどのプロジェクトのアーキテクチャにおいて非常に戦略的な部分です。

結局のところ、クラウドへの移行とは、オンプレミスからデータをソースとして取得し、それをクラウド アーキテクチャと可能な限り互換性のある形式でクラウド データベースに変換することを意味します。まさに ETL ツールの仕事です。

ETLの歴史と現在へのつながり

ETL の主な機能は常に同じでした。

抽出

ETL ツールは、さまざまなソース (データベース、フラット ファイル、Web サービス、最近ではクラウドベースのアプリケーションなど) からデータを抽出します。

これは通常、Unix ファイル システム上のファイルを入力として受け取り、前処理、処理、後処理を行うことを意味します。

次のようなフォルダー名の再利用可能なパターンが確認できます。

• 入力
• 出力
• エラー
• アーカイブ

これらのフォルダーの下には、主に日付に基づいた別のサブフォルダー構造も存在しました。

これは、受信データを処理し、ある種のデータベースに読み込む準備をするための標準的な方法でした。

現在、Unix ファイル システムは (以前とは異なりますが) 存在しません。おそらくファイルさえ存在しません。現在では API、つまりアプリケーション プログラミング インターフェイスが存在します。可能ですが、入力形式としてファイルを使用する必要はありません。

すべてキャッシュメモリに保存できます。ファイルのままでも構いません。それが何であれ、構造化されたフォーマットに従う必要があります。ほとんどの場合、これは JSON または XML 形式を意味します。場合によっては、古き良きカンマ区切り値 (CSV) 形式でも同様に機能します。

入力形式を定義します。このプロセスに入力ファイルの履歴の作成も含まれるかどうかは、あなた次第です。これはもはや標準的な手順ではありません。

変換

ETL ツールは、抽出されたデータを分析に適した形式に変換します。これには、データ クリーニング、データ検証、データ エンリッチメント、データ集約が含まれます。

以前はそうであったように、データは Pro-C または PL/SQL の手続き型データ ステージング、データ変換、およびデータ ターゲット スキーマ ストレージのステップの複雑なカスタム ロジックを通過しました。これは、ファイルが処理された段階に基づいて受信ファイルをサブフォルダーに分割する場合と同様に、必須の標準プロセスでした。

それが同時に根本的に間違っていたとしたら、なぜそれが自然だったのでしょうか?永続的なストレージを使用せずに受信データを直接変換することにより、生データの最大の利点である不変性が失われていました。プロジェクトはそれを再構築する機会もなくただ廃棄しました。

まあ、どうだろう。現在、実行する生データの変換は少ないほど良いとされています。つまり、システムへの最初のデータ ストレージの場合です。確かに、次のステップは重大なデータ変更とデータ モデルの変換になるかもしれません。ただし、生データをできるだけ変更せず、アトミックな構造で保存する必要があります。私に言わせれば、オンプレミスの時代からの大きな変化です。

負荷

ETL ツールは、変換されたデータをターゲット データベースまたはデータ ウェアハウスにロードします。これには、テーブルの作成、関係の定義、適切なフィールドへのデータのロードが含まれます。

おそらく読み込みステップは、長年にわたって同じパターンに従っている唯一のステップです。唯一の違いはターゲット データベースです。以前はほとんどの場合 Oracle でしたが、現在は AWS クラウドで利用可能なものであれば何でも可能です。

今日のクラウド環境における ETL

データをオンプレミスから (AWS) クラウドに取り込む予定がある場合は、ETL ツールが必要です。それなしでは成り立たないため、クラウド アーキテクチャのこの部分がおそらくパズルの最も重要なピースとなったのです。このステップが間違っていると、その後に何かが起こり、どこでも同じ匂いが共有されます。

数多くのコンテストがありますが、ここでは私が個人的に最も経験のある 3 つのコンテストに焦点を当てたいと思います。

• データ移行サービス (DMS) – AWS のネイティブ サービス。
• Informatica ETL – おそらく ETL 界の主要な商業プレーヤーであり、ビジネスをオンプレミスからクラウドに移行することに成功しています。
• Matillion for AWS – クラウド環境内の比較的新しいプレーヤーです。 AWS ではネイティブではありませんが、クラウドではネイティブです。 Informatica に匹敵する歴史はありません。

ETL としての AWS DMS

AWS Data Migration Services (DMS) は、さまざまなソースから AWS にデータを移行できるようにするフルマネージド サービスです。複数の移行シナリオをサポートします。

• 同種の移行 (例: Oracle から Amazon RDS for Oracle)。
• 異種移行 (Oracle から Amazon Aurora など)。

DMS は、データベース、データ ウェアハウス、SaaS アプリケーションなどのさまざまなソースから、 Amazon S3 、 Amazon Redshift 、 Amazon RDS などのさまざまなターゲットにデータを移行できます。

AWS は、DMS サービスを、あらゆるデータベース ソースからクラウドネイティブのターゲットにデータを取り込むための究極のツールとして扱います。 DMS の主な目的はクラウドにデータをコピーすることだけですが、途中でデータの変換もうまく行います。

DMS タスクを JSON 形式で定義して、ソースからターゲットにデータをコピーする際のさまざまな変換ジョブを自動化できます。

• 複数のソース テーブルまたは列を 1 つの値にマージします。
• ソース値を複数のターゲット フィールドに分割します。
• ソース データを別のターゲット値に置き換えます。
• 不要なデータを削除するか、入力コンテキストに基づいて完全に新しいデータを作成します。

つまり、はい、DMS をプロジェクトの ETL ツールとして使用できることは間違いありません。おそらく、以下の他のオプションほど洗練されていないかもしれませんが、事前に目標を明確に定義しておけば、十分に機能します。

適合性係数

DMS はいくつかの ETL 機能を提供しますが、主にデータ移行シナリオに関するものです。ただし、Informatica や Matillion などの ETL ツールの代わりに DMS を使用した方がよいシナリオもいくつかあります。

1. DMS は、ソース データベースとターゲット データベースが同じである同種の移行を処理できます。これは、Oracle から Oracle へ、または MySQL から MySQL へなど、同じタイプのデータベース間でデータを移行することが目的の場合に利点となります。
2. DMS は、いくつかの基本的なデータ変換およびカスタマイズ機能を提供しますが、その点ではあまり成熟していない可能性があります。データ変換のニーズが限られている場合でも、これは利点となります。
3. 一般に、DMS ではデータ品質とガバナンスのニーズが非常に限定されています。ただし、これらはプロジェクトの後半段階で、その目的に合わせて他のツールを使用して改善できる領域です。 ETL 部分をできるだけ単純に実行する必要がある場合があります。その場合、DMS は完璧な選択です。
4. DMS は、予算が限られている組織にとって、よりコスト効率の高いオプションとなります。 DMS は、Informatica や Matillion などの ETL ツールよりもシンプルな価格モデルを備えているため、組織はコストの予測と管理が容易になります。

マティリオンETL

はクラウドネイティブ ソリューションであり、これを使用して、データベース、SaaS アプリケーション、ファイル システムなどのさまざまなソースからのデータを統合できます。 ETL パイプラインを構築するためのビジュアル インターフェイスを提供し、Amazon S3、Amazon Redshift、Amazon RDS などのさまざまな AWS サービスをサポートします。

Matillion は使いやすく、ETL ツールを初めて使用する組織や、それほど複雑ではないデータ統合のニーズがある組織にとっては良い選択肢となります。

一方、マチリオンは一種のタブラ・ラサです。事前に定義された潜在的な機能がいくつかありますが、それを実現するにはカスタム コードを作成する必要があります。たとえその機能が定義上備わっていたとしても、Matillion がそのままの状態で仕事をしてくれることを期待することはできません。

Matillion は、自分自身を ETL ツールではなく ELT であると表現することもよくありました。つまり、Matillion が変換前にロードを実行する方が自然であるということです。

適合性係数

言い換えれば、Matillion は、データがデータベースに保存された後でのみデータを変換するという点で、以前よりも効果的です。その主な理由は、すでに述べたカスタム スクリプトの義務です。すべての特別な機能を最初にコーディングする必要があるため、その有効性はカスタム コードの有効性に大きく依存します。

これはターゲット データベース システムでより適切に処理され、Matillion には単純な 1:1 ロード タスクのみが残され、ここでカスタム コードを使用してタスクを破棄する機会が大幅に減ることを期待するのは当然です。

Matillion はデータ統合のためのさまざまな機能を提供しますが、他の一部の ETL ツールと同じレベルのデータ品質とガバナンス機能を提供していない可能性があります。

Matillion は組織のニーズに基づいてスケールアップまたはスケールダウンできますが、非常に大量のデータを処理する場合にはそれほど効果的ではない可能性があります。並列処理はかなり制限されています。この点では、Informatica のほうがより高度で機能が豊富であるため、より良い選択であることは間違いありません。

ただし、多くの組織にとって、Matillion for AWS は、ニーズを満たす十分なスケーラビリティと並列処理機能を提供する可能性があります。

インフォマティカ ETL

Informatica for AWS は、AWS のさまざまなソースとターゲットにわたるデータの統合と管理を支援するように設計されたクラウドベースの ETL ツールです。これは、データ プロファイリング、データ品質、データ ガバナンスなど、データ統合のためのさまざまな機能を提供するフルマネージド サービスです。

Informatica for AWS の主な特徴には次のようなものがあります。

1. Informatica は、実際のニーズに基づいてスケールアップまたはスケールダウンするように設計されています。大量のデータを処理でき、データベース、データ ウェアハウス、SaaS アプリケーションなどのさまざまなソースからのデータを統合するために使用できます。
2. Informatica は、暗号化、アクセス制御、監査証跡などのさまざまなセキュリティ機能を提供します。 HIPAA、PCI DSS、SOC 2 などのさまざまな業界標準に準拠しています。
3. Informatica は、ETL パイプラインを構築するためのビジュアル インターフェイスを提供し、ユーザーがデータ統合ワークフローを簡単に作成および管理できるようにします。また、システムを接続して統合プロセスを可能にするために使用できる、事前に構築されたさまざまなコネクタとテンプレートも提供します。
4. Informatica は、Amazon S3、Amazon Redshift、Amazon RDS などのさまざまな AWS サービスと統合します。これにより、さまざまな AWS サービス間でデータを簡単に統合できます。

適合性係数

Informatica がリストの中で最も機能が豊富な ETL ツールであることは明らかです。ただし、AWS で利用できる他の ETL ツールよりも高価で、使用が複雑になる可能性があります。

Informatica は、特に中小企業にとって高価になる可能性があります。価格モデルは使用量に基づいているため、組織は使用量が増加するにつれて、より多くの料金を支払う必要がある可能性があります。

また、特に ETL ツールを初めて使用するユーザーにとっては、セットアップと構成が複雑になる場合があります。これには、時間とリソースに対する多大な投資が必要となる場合があります。

これはまた、「複雑な学習曲線」と呼ぶべき事態にもつながります。これは、データを迅速に統合する必要がある場合、またはトレーニングやオンボーディングに費やすリソースが限られている場合には不利になる可能性があります。

また、Informatica は、AWS 以外のソースからのデータの統合にはそれほど効果的ではない可能性があります。この点では、DMS または Matillion の方が良い選択肢になる可能性があります。

最後に、Informatica は非常にクローズド システムです。プロジェクト固有のニーズに合わせてカスタマイズできる機能は限られています。すぐに提供されるセットアップをそのまま使用する必要があります。したがって、それがソリューションの柔軟性を何らかの形で制限します。

最後の言葉

他の多くのケースでよくあることですが、AWS の ETL ツールのようなものであっても、万能のソリューションはありません。

Informatica の最も複雑で機能が豊富で高価なソリューションを選択することもできます。しかし、次のような場合には、ほとんどのことを実行するのが理にかなっています。

• このプロジェクトはかなり大規模であり、将来のソリューション全体とデータ ソースも同様に Informatica に接続されることは間違いありません。
• 熟練した Informatica 開発者と構成者のチームを連れてくる余裕があります。
• 強力なサポート チームがサポートしてくれることに感謝し、その対価を支払うことに抵抗はありません。

上記の何かが間違っている場合は、Matillion に試してみてください。

• 一般に、プロジェクトのニーズがそれほど複雑ではない場合。
• 処理に非常にカスタムなステップをいくつか含める必要がある場合、柔軟性が重要な要件になります。
• ほとんどの機能をチームと一緒にゼロから構築しても構わない場合。

さらに複雑でない場合は、ネイティブ サービスとして AWS の DMS を選択するのが明白であり、おそらく目的を十分に果たせるでしょう。

次に、データをより適切に管理するためのデータ変換ツールを確認してください。