jp.fivetran.com Open in urlscan Pro
52.69.142.38  Public Scan

Form analysis
1 forms found in the DOM

https://jp.fivetran.com

<form action="https://jp.fivetran.com">
  <input placeholder="検索" class="_1QfTx _3VLAa _1s37_ _3KmjQ _3z-44" name="s" value="">
  <button class="_18OvV _2opJe _2uLpp _3z-44" type="submit" title="Search">
    <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24">
      <path d="M15.5 14h-.79l-.28-.27C15.41 12.59 16 11.11 16 9.5 16 5.91 13.09 3 9.5 3S3 5.91 3 9.5 5.91 16 9.5 16c1.61 0 3.09-.59 4.23-1.57l.27.28v.79l5 4.99L20.49 19l-4.99-5zm-6 0C7.01 14 5 11.99 5 9.5S7.01 5 9.5 5 14 7.01 14 9.5 11.99 14 9.5 14z"
        fill="currentColor"></path>
      <path d="M0 0h24v24H0z" fill="none"></path>
    </svg>
  </button>
</form>

Text Content

料金
コネクタ
Categories
エンジニアリング解析
サポート分析
データベース
マーケティング分析
営業分析
製品分析
財務・運用分析
データベースコネクタ
Oracle
データベース

SQL Server on RDS
データベース

Oracle RAC
データベース

SAP ERP (S/4 HANA)
データベース
すべて →
Featured
Asana
エンジニアリング解析

Github
エンジニアリング解析

Marketo
マーケティング分析

Salesforce
サポート分析
すべて →
導入事例
ブログ
お問い合わせ

デモを入手する 今すぐ購入
Homeブログ
ETLとELT･･･データ統合に適した手法の選択



ETLとELT･･･データ統合に適した手法の選択

ETLとELTの違いを学ぶことで、お客様により役立つ手法を選択できます。



ETLの略語は、分析の裏付けに必要なデータ統合を意味するものとして使われることが多い言葉です。
データ統合には、以下の作業が含まれます。

 1. データの収集・抽出
 2. データの移動先への格納
 3. アナリストが使用できるモデルへのデータ変換

これらの作業の正確な処理順序はケースバイケースです。このブログでは、データ統合の２つの主な手法であるETLとELTについて解説します。

ETLとは

データ統合の伝統的な手法であるETL（E･･･抽出、T･･･変換、L･･･読み込み）の起源は1970年代にさかのぼり、データ統合の代名詞になるほど一般化しています。ETLの仕組みを簡単に説明すると、まずパイプラインによりソースからデータが抽出され、アナリストによるレポートやダッシュボードへの変換に適した
データモデルに変換されたあと、データウェアハウスに格納されるというプロセスです。

データ変換では通常、データの集計・要約により全体的なデータ量が縮小されます。ETLは、こうした格納に先立つ変換を通し格納されるデータ量を制限することで、ワークフロー全体の保管・処理・通信容量を節約します。ETLが最初に発明された1970年代には、組織の大半が非常に限られた技術環境のもとで運営していました。保管・処理・通信容量は、どの組織でも非常に限られていました。

ETLのプロジェクトワークフローは、以下の手順から構成されます。

 1. 必要なデータソースの特定
 2. プロジェクトによる解決が想定されている分析ニーズの正確な把握
 3. アナリストおよびその他のエンドユーザーが必要とする、データモデル／スキーマの特定
 4. 抽出・変換・格納機能を備えたパイプラインの構築
 5. 分析作業の実施および結果の抽出
    
    

ETLでは抽出と変換の両方がデータの移動先への格納前に行われるため、これら２つの作業は密接に結びついています。また、変換内容はそれぞれの分析作業に固有のニーズに左右されるため、ETLパイプラインは複雑かつカスタマイズされたソリューションとなります。そのため、特にデータソースやデータモデルの
追加など、拡張が非常に難しいのがETLの特徴です。

この作業のやり直しが必要とされる状況には、主に以下の２つがあります。

 1. 上流のスキーマの変更により、未加工データの所要データモデルへの変換に用いられるコードが無効となった場合。ソースにフィールドが追加・削除・変更された場合など。
 2. 下流の分析ニーズの変更により、変換コードの書き換えを通した新たなデータモデルの生成が必要とされる場合。まだ存在しない仕様のデータを必要とするダッシュボードやレポートを構築したい場合など。

データリテラシーの改善に常に取り組んでいる組織は、これら２つの状況に定期的に遭遇します。

抽出と変換の密接な関係はつまり、変換機能の停止が移動先へのデータ格納の妨げとなり、ダウンタイムが発生することを意味します。

そのため、ETLによるデータ統合には、以下の課題が伴います。

 * 継続的な保守の必要性･･･データパイプラインによりデータの抽出・変換の両方が行われるため、
   上流でのスキーマの変更時や下流でのデータモデルの変更時にパイプラインが崩壊し、コード基盤の大幅な修正が必要とされる。
 * カスタマイズ化による複雑化･･･データパイプラインは、データの抽出だけでなく、それぞれの分析作業に固有のニーズ似合った高度な変換処理も行わなければならないため、大量のカスタマイズされたコードが必要とされる。
 * 多大な手間と費用･･･カスタマイズされたコード基盤で起動するシステムのため、構築や保守に複数の専属データエンジニアが必要とされる。

そのため、計算処理・保管容量の節約というETLの利点は、こうした労力の犠牲の上に成り立っているといえます。

クラウド型データ統合へ移行する近年の動向

こうした手間のかかるプロセスは、保管・処理・通信容量が高価であり、また制限があるため、データ量やデータの種類が限られていた時代には通用していました。つまりETLは、技術資源が現在よりはるかに限られていた時代の産物なのです。

たとえば、ギガバイト当たりのストレージ単価は、約100万ドルから数セントまで急落し、40年間で5000万分の１の価格になりました。



計算処理のコストは、1970年代以降、数百万分の１に縮小しました。



インターネット通信料は、数千分の１になっています。



こうした動向により、ETLは２つの意味で時代遅れとなっています。１つ目は、計算処理・保管・インターネット通信コストの低下により、クラウド型サービスの急速な成長がもたらされた点です。クラウドの拡大により、データ量やデータの種類や複雑性も増大したため、限られた量のデータを統合する不安定なカスタムパイプラインでは、もはや対応しきれなくなっています。

２つ目は、最新のデータ統合技術では、保管されるデータ量や、ウェアハウス内で実行されるクエリーの頻度が以前ほど制限されない点です。計算処理・保管・インターネット通信コストの低下により、データ統合ワークフローの再編はもちろん、データウェアハウスでの未変換データの保管に関するコスト面の課題も解消されました。

ETLに代わるELTの台頭

未変換のデータをデータウェアハウスに保存できるようになったことで、変換段階の格納後への移動が可能になり、データを抽出後すぐに移動先に格納できるELT（E･･･抽出、L･･･格納、T･･･変換）と呼ばれる新しいデータ統合アーキテクチャが誕生しました。



これより、ETLに不具合が生じる２つの原因（上流のスキーマ変更および下流のデータモデル変更）による抽出・格納への影響が排除され、よりシンプルかつ強固なデータ統合が実現しました。

ELTワークフローでは、以下の作業がETLとは対照的な短周期で実行されます。

 1. 必要なデータソースの特定
 2. 自動抽出・格納の実行
 3. プロジェクトによる解決が想定されている分析ニーズの正確な把握
 4. 変換機能の構築を通したデータモデルの作成
 5. 分析作業の実施および結果の抽出
    
    

z

ELTでは、格納が変換より上流にあるため、変換に依存しない抽出・格納が実現します。上流のスキーマや下流のデータモデルの変更により変換レイヤーに不具合が生じる可能性はまだあるものの、これにより
データの移動先への格納が妨げられることはありません。それどころか、変換コードがアナリストにより定期的に書き換えられる場合でも、データの抽出・格納は継続されます。また、修正が最小限に抑えられた状態でデータが移動先に格納されることで、データウェアハウスのより包括的かつ最新のデータソースとしての機能が向上します。

ELTの最大の利点は、抽出および格納を変換から切り離せることで、抽出・格納の出力データをカスタマイズする必要がなくなる点です。ソースから移動先にデータが直接投入されるため、以前のようにデータの
クリーニングや正規化の必要はありません。クラウドの成長を踏まえると、これにより抽出・格納分野で以下が実現します。

 1. 委託化
 2. 自動化
 3. クラウドでの必要に応じた拡張・縮小

自動抽出・格納には、出力データが標準化され、テンプレート化された分析ツールなどの成果物を移動先に重ねて配置できるという利点があります。

また、データウェアハウス環境内で変換が実行されるため、ラッグ・アンド・ドロップ形式の変換インターフェイスを通して変換を設計したり、Pythonなどのスクリプト言語を用いて変換コードを記述したり、
異種データソース間での複雑なオーケストレーションの構築したりする必要がなくなります。
その代わりに、大半のアナリストが使い慣れているSQLで変換を記述できるようになります。これにより、データ統合を、ITまたはエンジニアを主体とする作業から、アナリストが直接気軽に処理できる作業に変えることができるのです。

ETLとELTの主な違い

以下の表は、ETLとELTの主な違いをまとめたものです。

ETLELT抽出、変換、格納抽出、格納、変換要約データまたはサブセットデータの統合あらゆる未加工データの統合変換が直接格納に影響変換が格納に影響しないデータ格納までの所要時間が長いデータ格納までの所要時間が短い変換の不具合によりパイプラインが停止変換に不具合が生じてもパイプラインが停止しない事前に用途の予測やデータモデルの設計が行われない場合、データパイプライン全体の見直しが必要いつでも新しい用途やデータモデルを追加できるカスタム既製継続的な構築・保守が必要自動構築・保守計算処理・保存容量の節約労力の節約スクリプト言語を用いた変換記述SQLを用いた変換記述エンジニア・IT主体の専門システムアナリスト主体･･･IT専門家でなくても使用可クラウド型または社内システムほぼクラウド型に限定

しかしながら、以下のようなケースでは、ETLがELTより適している可能性があります。

 1. 必要なデータモデルがよく知られており、すぐには変更されそうにない場合。ソースデータ生成用のシステムが同じ組織により構築・保守されている場合は特にこのケースが当てはまります。
 2. データに関する厳しいセキュリティ・規制要件への順守が求められ、これらの要件を100％満たせる場所でのデータ保管が求められる場合。

これらは、サービス型ソフトウェア製品に特化した非常に大規模な企業や組織で特に特徴的な状況です。
こうした場合、第三者のSaaS製品を用いたデータ統合にはELTを使用し、社内の私設データソースの統合には引き続きETLを使用するのが得策です。

ELTおよび自動化の利点の実現

LTを用いた自動化に取り組む企業は、データ統合ワークフローを劇的に簡素化できる可能性があります。
データ統合ワークフローの簡素化は、データエンジニアリングの強化をもたらし、データパイプラインの構築・保守ではなく、データインフラの最適化や予測モデルの作成などのよりミッションクリティカルな作業にデータエンジニアが集中できる環境を実現できます。アナリストやデータサイエンティストの職務はこれまで、分析作業自体よりむしろデータ統合作業に占められてきましたが、これによりビジネスニーズに関する専門知識を活かしたデータのモデリングや分析に、ようやく集中して取り組めるようになるのです。






FIVETRANを始めてみませんか

無料トライアルはこちら
Fivetranのスペシャリストに質問する

Fivetran
料金 コネクタ 導入事例 ブログ
会社概要
Fivetran について お問い合わせ
Follow Us

日本語 US English EU English Français Deutsch
プライバシー ポリシー 利用規約 © 2021 Fivetran Inc.