ETLとは、データの抽出、変換、ロードのことです。ETLは、様々なソースからデータを収集し、処理して1つのデータストアに格納し、後で分析することができます。企業では様々なデータソースにアクセスしていますが、多くの場合、そのデータはあなたにとってあまり使い勝手が良いとは言えない方法で表示されています。また、その分析結果は、ビジネス戦略や意思決定のために利用される可能性があります。

現在、データ分析の要求が、標準的なレポーティング・アプリケーションの処理能力を超過する時代になっています。Google AnalyticsやMixpanelのような標準的なソリューションで必要なことができないと判明したら、カスタム・ビジネス・インテリジェンス(BI)ソリューションの構築を検討してみてはいかがでしょうか? 新しいBIソリューションの基盤となるのは、ETLとも呼ばれるデータ統合レイヤーです。この記事では、ETLとは何か、そしてどのようにして企業がETLの恩恵を受けることができるかについて掘り下げて行きたいと思います。 

Table of Contents

ETLとは?

なぜETLが必要なのか?

最新のETLはビジネスにどのように役立つか?

ETLの仕組み

ETLとは?

抽出、変換、ロード処理の各ピースをもっと詳しく見てみましょう。

Extract(抽出)

データの抽出(Extract)とは、データソースをターゲットにして、そこからデータを引っ張ってきて、データを変換したり、統合したり、別の場所に保存したりできるようにすることです。様々な種類の様々なデータベースをターゲットにして抽出を行うことができ、それぞれの抽出をスケジュールに沿って実行することで、定期的に最新かつ正確なデータを取得するための一連の流れを手に入れることができます。

Transform(変換)

データは必ずしも欲しい形で来るとは限らず、通常は変換する必要があります。保存しているデータをいくつかのフィールドだけに制限したり、すべての列が特定の順序になるように並べ替えたりしたい場合があるでしょう。また、複数のテーブルを結合したい場合や、重複したレコードで煩雑となっているデータベースをクリーンアップしなければならない場合もあるでしょう。変換(Transform)は、ETLプロセスの中で、データにアクセスしたときに最も有用なデータになるようにデータを準備するステップです。

Load(ロード)

最後に、データがソートされ、クリーンになり、検証され、準備万端になったら、そのデータをどこかにロード(Load)します。最も一般的なロード先はデータウェアハウスで、将来の分析やトレンドの追跡のためにデータを保管しておくことができます。

For more information, refer to A Deep Dive into Extract, Transform, Load later in this article.

Related Reading: ETL vs ELT

データウェアハウスでのETLの実装

ETLプロセスを使用してデータベースをデータウェアハウス(DWH)にロードする場合、各フェーズは物理層で表現されます。

  • Mirror/Raw layer - この層は、ソースファイルまたはテーブルのコピーで、加工のためのロジックやエンリッチメントは含まれていません。ソースデータはコピーされ、ターゲットのミラーテーブルに追加されます。
  • Staging layer - ミラーテーブルからの生データが変換されると、すべての変換されたデータはステージングテーブルに格納されます。これらのテーブルは、途中のETLサイクルのインクリメンタル部分のデータの最終形を保持します。
  • Schema layer - これらは、クレンジング、エンリッチメント、変換後の最終形のすべてのデータを格納している送信先のテーブルです。

  • Aggregating layer - いくつかの場合、全データセットから日次レベルまたは店舗レベルにデータを集約することは理にかなっています。これにより、レポートのパフォーマンスが向上し、計算された指標にビジネスロジックを追加することが可能になり、レポート開発者がデータを理解しやすくなります。

なぜETLが必要なのか?

簡単に言うと、ETLはデータの抽出と準備にかかる時間を大幅に節約し、節約された時間を情報の評価や活用に充てることができます。

ETLの3つの各主要コンポーネントは、用意されたデータフロー内で一度に行うことで、時間と開発の労力を節約します。

  • Extract(抽出) - 「鎖は最も弱いつなぎ目以上には強くならない」ということわざがあります。ETLの文脈において、チェーンの強さは最初のつなぎ目によって決まります。抽出段階では、さまざまなデータソース、各ソースの更新頻度(頻度)、およびそれらの間の優先順位(抽出順序)が決定されますが、これらはすべて、データ活用までの時間に大きく影響を及ぼします。
  • Transform(変換) - データをETL環境に抽出した後、変換により、初期のデータの沼地に明確さと秩序をもたらします。例えば、日付は指定された時間形式に統一され、文字列はビジネス上意味するところに解析され、取引情報はイベントにモデル化され、位置データは座標、郵便番号または都市/国に変換され、測定値は合計され、平均化され、数値は丸められ、無用なデータやエラーは後の検査のために脇に置かれます。またPIIデータ(個人情報)は、GDPR、CCPA、およびその他のプライバシー要件を遵守するためにマスクすることができます。
  • Load(負荷) - 最後のフェーズでは、最初のフェーズと同様に、データのロード先と更新頻度が決定されます。さらに、ロードフェーズでは、新しいデータの適用方法としてロード処理が追加で行われるか、「アップサート」(既存のデータを更新して新しいデータを挿入する)が必要かを決定します。

最新のETLはビジネスにどのように役立つか?

今日のデータは、サイズだけでなく、影響力、可能な解釈、ユースケースにおいても、実際に大きな部分を担っています。収益の流れやユーザーを管理・監視するだけでなく、現代の企業の各部門はビッグデータから独自のインサイトを必要としています。

  • 営業部門では、見込み客に関する質の高い情報を必要としています。
  • マーケティングはキャンペーンのコンバージョン率と今後の戦略を見極める必要があります
  • カスタマーサクセスは、顧客のニーズや問題を解決したり改善するために、1行ごとのイベントまでドリルダウンしたいと考えています。

このような多様なデータ要求を、いくつか存在するデータバージョンに埋もれることなく満たすため、ETLは民主的なデータガバナンスを維持する環境を構築します。

  • データガバナンス - エンタープライズデータの可用性、ユーザビリティ、完全性、セキュリティの総合的な管理。これは、一貫性のあるコネクタされたデータレイヤーを作成するためのプロセスです。データガバナンスは、あらゆるデータクライアントに拡大し続けるデータの世界に全体的な視点をもたらすことで、データ民主主義を可能にします。
  • データ民主主義 - 企業内でデータ分析にアクセスする必要があるすべての人が、急な学習曲線を和らげ、適切なデータの問い合わせを実施し、その答えを明らかにするプロセスに関与できるようにします。

ETLの仕組み

このセクションでは、ETLプロセスの3つのステップのそれぞれについて詳しく見ていきます。

ETLは、スクリプト(カスタムで作ったプログラム)を使って実装することも、専用のETLツールを使って実装することもできます。ETLは以下のような多くの重要な機能を実行します。

  • 解析/クレンジング - アプリケーションによって生成されたデータは、JSON、XML、またはCSVのような様々な形式で作成されます。解析段階では、データはヘッダー、列、行を持つテーブル形式にマッピングされ、指定されたフィールドが抽出されます。
  • データのエンリッチメント(強化) - アナリティクス用にデータを準備するためには、通常、次のような特定のエンリッチメント手順が必要です:微調整、専門知識の付与、地理的な修正、ソース間の列のマッチング、不正データの修正。
  • 頻度の設定 - 頻度とは、データ読み込みの頻度、新しいデータを挿入するかどうか、既存のデータを更新する必要があるかどうかを指します。
  • データの検証 - データが空だったり、破損していたり、重要な要素が欠けていたり、少な過ぎたり、肥大化していたりする場合があります。ETLはこれらの発生を検出し、関連する管理者に警告を発しながら、プロセス全体を停止するか、スキップするか、調査のために別途保管しておくかを決定します。

抽出 

データ抽出には、以下の4つのステップがあります。

    1. 抽出するデータを特定する:データ抽出の最初のステップは、データウェアハウスに組み込むデータソースを特定することです。これらのソースは、MySQL のようなリレーショナル SQL データベースかもしれませんし、MongoDBやCassandraのような非リレーショナルNoSQLデータベースである可能性もあります。また、Salesforceやその他のSaaS(Software as a Service)プラットフォームからの情報の場合もあります。データソースを特定した後は、抽出したい特定のデータフィールドを決定することも必要です。
    2. データ抽出のサイズを見積もる:データ抽出のサイズは重要です。500ギガバイトのデータを抽出するのか、50ペタバイトのデータを抽出するのか。データの量が多ければ、異なるETL戦略が必要になります。例えば、日レベルではなく月レベルに集約することで、より大きなデータセットをより扱いやすくすることができ、抽出のサイズを小さくできます。あるいは、サーバーの設定をアップグレードして、より大きなデータセットを処理することもできます。
    3. 抽出方法を選択する:データウェアハウスは、最も正確なレポートを作成するためにデータストアを継続的に更新する必要があるため、データ抽出は継続的なプロセスであり、分単位で行う必要がある場合があります。情報を抽出するには、主に3つの方法があります。
    • 更新の通知:抽出の好ましい方法は、更新の通知です。ソースシステムは、レコードが更新されたときに通知を送信します。その後、データウェアハウスは新しい情報のみで更新します。
    • インクリメンタル抽出:2 番目の方法は、更新通知が不可能な場合、増分抽出です。これには、変更されたレコードを識別し、それらのレコードのみを更新する抽出が含まれます。インクリメンタル抽出では、削除されたレコードを常に識別できるとは限りません。
    • 全抽出:最初の2つの方法がうまくいかない場合は、全抽出によってすべてのデータを完全に更新する必要があります。
    1. SaaSプラットフォームを検証する:企業は以前、会計やその他のレコード管理を社内のアプリケーションに頼っていました。これらのアプリケーションでは、オンサイト・サーバー上で管理されているOLTPトランザクション・データベースを使用していました。今日では、Google Analytics、HubSpot、SalesforceなどのSaaSプラットフォームを使用する企業が増えています。これらのプラットフォームからデータを引き出すには、プラットフォーム独自のAPIと統合することが可能なXplentyのようなソリューションが必要になります。

    XplentyのようなクラウドベースのETLソリューションは、以下の方法で人気のあるSaaS APIからデータを抽出します。

    • 最も人気のあるSaaSアプリケーションのためのすぐに使えるAPI統合を設計することができます。(Xplentyの何百ものすぐに使えるAI統合をここで参照してください)。
    • 複雑なREST APIをナビゲートしたり、SOAPを自動的にRESTに変換することもできます。
    • 様々なSaaS APIに見られるカスタムリソースやフィールド、そして多くのビルトインリソースエンドポイントに対処するための戦略を構築します。
    • 失敗する可能性のあるデータ接続に対して定期的に更新や修正を提供してくれます。たとえば、Salesforce が API を更新したにもかかわらず、ユーザへの通知がうまく伝わらず、解決策を探すのに苦労することになるかもしれません。XplentyのようなETLプラットフォームは、SaaSディベロッパーとの関係を構築しており、リリース前にこのような種類のアップデートについて事前通知を受け取ることで、予期せぬ混乱を未然に防ぐことができます。

    データ変換

    従来のETL戦略では、ステージングエリア(抽出後)で発生するデータ変換は 「多段階データ変換」と呼ばれています。ELTでは、データウェアハウスにデータをロードした後に行われるデータ変換は、「ウェアハウスデータ内変換」と呼ばれます。

    ETLを選択してもELTを選択しても、以下のようなデータ変換が必要になることがあります。

    • 重複排除(正規化):重複した情報を特定して削除します。
    • キーの再構築:テーブルから別のテーブルにリレーションを定義します。
    • クレンジング:データの精度を最大限に高めるために、古いデータ、不完全なデータ、重複したデータを削除します。
    • フォーマットの修正:日付/時刻、男性/女性、測定単位のような異なるデータセットのフォーマットを、一貫性のある1つのフォーマットに変換します。
    • 派生:データに適用される変換ルールを作成します。たとえば、分析する前に、事業収益の数値から特定のコストや税金負債を差し引く必要がある場合などです。
    • 集計:データを収集して検索し、要約されたレポート形式で表示できるようにします。
    • 統合:各要素が標準的な名称と定義を持つように、データウェアハウス内の同じデータ要素に適用される多様な名称/値を再調整します。
    • フィルタリング:データセット内の特定の列、行、フィールドを選択します。
    • 分割:1つの列を複数の列に分割します。
    • 結合:複数のSaaSプラットフォームの支出情報を追加するなど、複数のソースからのデータをリンクします。
    • サマリゼーション:値の合計を計算することで、異なるビジネス・メトリクスを作成します。例えば、特定の営業担当者が行ったすべての売上を集計して、特定の期間の総売上メトリクスを作成することができます。
    • 検証:さまざまな状況で従うべき自動ルールを設定します。たとえば、行の最初の5つのフィールドがNULLの場合、その行に調査のフラグを立てたり、それ以外の残りのデータと一緒に処理されないようにしたりすることができます。

    データロード

    データローディングとは、抽出した情報を送信先のデータリポジトリにロードするプロセスです。ロードは、「フルロード」(最初にデータをウェアハウスにロードするとき)または「インクリメンタルロード」(新しい情報でデータウェアハウスを更新するとき)によって起こる可能性のある継続的なプロセスです。インクリメンタルロードは最も複雑なので、このセクションではそこに焦点を当てて解説します。 

    インクリメンタルロードの種類

    インクリメンタルロードは、前回のインクリメンタルロード以降に現れた新しい情報を抽出してロードします。これには2つの方法があります。 

    • バッチインクリメンタルロード:データウェアハウスはパケットまたはバッチで情報を抽出します。特に大規模なバッチであれば、システムの遅延を防ぐために、毎日、毎週、または毎月のようなオフピーク時にバッチロードを実行するのがベストです。しかし、最新のデータウェアハウスは、XplentyのようなETLプラットフォームを使用して、分単位(最短15分間隔)で小規模なバッチで情報を抽出することもできます。これにより、エンドユーザーのためにニアリアルタイムの更新を実現することができます。
    • ストリーミングインクリメンタルロード:データウェアハウスは新しいデータをリアルタイムで抽出します。エンドユーザーが完璧なタイミングで意思決定のためにリアルタイムの更新を必要とする場合に特に有効です。ただし、ストリーミングインクリメンタルロードは、更新に含まれるデータ量が非常に少ない場合にのみ可能です。ほとんどの場合、分単位のバッチ更新は、リアルタイム・ストリーミングよりも堅牢なソリューションを提供します。

    インクリメンタルロードの課題

    インクリメンタルロードは、システムのパフォーマンスを低下させ、以下のような多くの問題を引き起こす可能性があります。 

    • データ構造の変更:データソースやデータウェアハウスのデータフォーマットは、情報システムのニーズに合わせて進化していく必要があります。しかし、システムの一部を変更すると、読み込みプロセスを妨げる不整合が発生する可能性があります。一貫性のないデータ、破損したデータ、または矛盾したデータに関連する問題を防ぐには、小さな変更がエコシステム全体にどのような影響を与えるかを拡大して検討することが重要です。そうすれば、システム全体で適切な調整を行うことができます。
    • 間違った順序でデータを処理している:データ パイプラインは複雑なステップを経るため、データウェアハウス内で誤った順序で情報を処理、更新、または削除してしまうことがあります。その結果、情報が破損したり、不正確になったりすることがあります。このため、データ処理の順序を監視し、監査することは非常に重要です。
    • 問題の発見を見逃す: 問題があることに気づかないでいると、必ずと言っていいほど問題が悪化します。そのため、APIがダウンした場合、APIのアクセス資格情報が古い場合、システムのスローダウンによりAPIからのデータフローが中断した場合、ターゲットのデータウェアハウスがダウンした場合など、問題を迅速に検出することが重要です。問題の検出が早ければ早いほど、迅速に問題を修正することができ、おまけに発生した不正確なデータや破損したデータの修正がより容易になります。

    カスタムETLソリューションに進む準備はできましたか?

    以下のリンクよりオンライン相談を是非お申し込み下さい。Xplentyを使ってデータを簡単に変換する方法をご紹介します。

    Xplentyのオンライン相談に登録して、無料トライアルでプラットフォームを試してみよう!

    Xplentyの機能概要や実際の操作感を見てみたい方は、定期的に開催している製品紹介セミナーがおすすめです。

    Xplentyのオンラインセミナーに申し込む。