変化は唯一の不変要素です。ツールや技術はもちろん、ビジネスニーズも変化を避けることはできません。これはつまり、分析の元となるデータソースのスキーマや、分析のためのデータモデルも変化することを意味します。以下では、こうした変化への新たな対処方法をご紹介します。
これまでの努力を台無しにするスキーマの変更
スキーマの変更は、手作業による報告書の作成や従来のETL手順に基づく作業など、お客様のあらゆる
ワークフローの重大な妨げとなります。
データパイプラインを手作業で構築したことがある方なら、データソースのAPI端末やファイルが変更されるたびにデータ取り込みコードを書き直さなければならない苦労をご存知のはずです。
従来のETL工程を導入している企業の場合、社内のデータエンジニアは、データソースの定期的な更新だけでなく、ETL工程の「トランスフォーメーション（変換・加工）」段階の修正にも対処しなければなりません。アナリストやデータサイエンティストにより新しいデータモデルが要求されるたびにこの作業を行い、変化するビジネスニーズに対応する必要があります。
この作業に関する最も苛立たしい点は、解決しようとしている問題や分析内容とはまったく関係のない
データフィールドにも変更の影響が及び、それらへの対処も求められることです。
Fivetran独自の手法
Fivetranでは、こうしたスキーマの変更に関する問題を、2つの方法で解決しています。
１つ目は、データソースのスキーマの変更を自動的・漸進的・包括的にデータウェアハウスに伝えることで、データソースの継続的な変更に対応する方法です。当社はこれを、状況によりいくつかの異なる方法で実現しています。
- データソースに新しい列が追加されると、Fivetranが変更を検出し、必要に応じてデータのバックフィルを実行しながら同じコラムをウェアハウスに追加します。
- データソースの列が削除された場合、データウェアハウスから列を完全に削除する代わりに、
それ以降の記録を無効にし、参照用の履歴データとして保管されます。 - コラムのデータタイプが変更された場合、Fivetranは古い列を維持しながら新しいデータタイプの列を作成することで、旧・新両方のデータをできる限り破損なく取り込みます。これにより作成された表からのビューの作成が可能になります。
- データソースに新しい表が追加された場合、Fivetranにより同期が開始されます。
- データソースから表が削除された場合でも、ウェアハウスの表はそのままの状態で保管されます。
スキーマの変更に関する問題への２つ目の対処方法は、「トランスフォーム（変換）」段階をETLプロセスの最後に移行させることで、アナリストにより使用されるスキーマのリファクタリングを、ウェアハウスへの格納後に限定する方法です。この方法の利点は、業務ニーズの変化に伴うパイプライン再設計の負担を解消し、パイプライン全体を強化できる点にあります。アナリストがSQLを用いてデータモデルを構築するほうが、これらをハードコードとしてエンジニアにプログラミングさせるよりよっぽど効率的です。当社のお客様の中には、Lockerやその他のBIツールを臨時のトランスフォーメーション層として利用されている企業様もいらっしゃいます。
痛みなくしても得るものあり
スキーマの変更は、データ移動を麻痺させるには至らないものの、苛立たしさを伴いうるものです。当社の目標は、解決済みであるべき問題に対処する負担を解消することです。これはつまり、分析内容とは直接関係ない上流データの変更に多くの時間と労力を費やし対処する代わりに、実際のデータ分析により多くの時間を費やせられるようになることを意味します。
スキーマの変更への対処にうんざりされている方は、ぜひFivetranをお試しください。
