現在、Business Intelligence(BI)製品への注目度は非常に高く、様々な企業および部署レベルで「データ活用」の重要性が認知され、製品の導入が進んできています。

BIを利用する上で、データソースからデータを加工せずにダッシュボードやレポートで見るというケースはまれで、ほとんどのデータが何かしらの加工処理が行われ、分析に利用されています。最近では、BI製品でも簡単な加工を行うことができ、ETL製品を利用せず、BI製品のみを利用しているユーザーも増えてきています。

しかしながら、BI製品に付属の簡易ETL機能をお使いのユーザーであれば、以下のような問題に直面し、困った経験があったり、現在でも困っているという方も多いかと思います。

  1. リソースの不足(データ変換処理が重くてデータ提供に遅延が生じている)
  2. データのインクリメンタルアップデート(差分更新)機能がない
  3. スケジュール実行やワークフローといった機能がないため、タスク間の依存関係を設定することができない。(データの不整合や最新データの一部が欠落するなどの問題が発生し、データ活用に支障をきたすことがある。)

こうした問題は、ETLプラットフォームを利用することにより解決することが可能です。

今回のブログでは、BI製品を利用していく上で、「ETLプラットフォームを導入するメリット」について、運用していく中で直面するであろう課題に焦点を当てて、紹介したいと思います。

Table of Contents

1.属人化の排除

2.データ連携

3.障害対応時の柔軟性

1. 属人化の排除

最近のBI導入プロジェクトでは、比較的短期間での導入を目指すことが多く、プロジェクトスケジュールも非常にタイトです。納期を守るために、データエンジニアが必死に働いた結果、そのエンジニア以外は、仕様を把握している人間がおらず、エンジニアがプロジェクトを抜けたり、退職した後、誰も引き継げずに困ったという経験はないでしょうか?

このような問題は、ETLツールを使うことで解決することが可能です。ETL製品の多くは、ビジュアル化されたパイプラインにより簡単に処理内容を把握でき、データ間の関係性やタスクとタスクの依存関係についても、ひと目で把握することが可能です。また、ドラッグ&ドロップベースでパイプラインが作成できるので、あらかじめ用意された豊富な変換機能を使うことで、SQLやプログラミングによる変換処理を極力排除することができます。

また、BIのためのデータ準備プロセスが複雑であればあるほど、そのデータ処理プロセスは属人化しやすい傾向にあります。設計書などのドキュメントである程度は詳細を補足できますが、BIは常にビジネスニーズに即してアップデートされていくため、設計書やドキュメントの内容と実際のモノが違うという経験は、誰しもが直面したことがあるかと思います。

メンテナンスや仕様変更の際、処理内容の解読や仕様変更による影響範囲の洗い出しなどの工数は、無視できないほど大きな負担となります。また、実施の有無は別として「こんなことなら、作り直した方が早いのでは?」といった考えが頭をよぎることも多々あるかと思います。

ビジュアル化されたETLであれば、処理内容の把握や影響範囲の調査にかかる時間、およびその後のメンテナンスや変更にかかる時間を削減できます。またドラッグ&ドロップベースで開発されたパイプラインを使えば、パイプラインの構築およびメンテナンスについて、SQLやプラグラミング経験が必要といったリソースの制約事項も不要になります。

2.データ連携

社内のファイルサーバーなどのファイルについては、データ抽出のルールを決めてしまえば、ある程度はカンタンに開発できますが、クラウドにあるSaaSアプリやDBもしくはストレージサービスとなると、そうは行きません。

というのも、そういったサービスとのデータ連携機能を開発しようにも、それぞれのサービスが提供しているデータ提供手段や提供されているデータ仕様について理解する必要があります。クラウドサービスのほとんどは、Rest APIによる連携が前提となるため、認証方法やAPI仕様、さらには取得されるデータの特性を理解した上で初めて開発が可能になります。経験やノウハウのないサービスとのデータ連携部分を開発するのは、データ準備担当にとっては一番悩ましく、プロジェクトスケジュールやプロジェクトの遅延リスクも含めて、最もプロジェクトで気を使うところだと言えます。

最近のETLおよびBI製品の多くは、様々なデータソースからのデータ取得をサポートしています。ただし、取得したデータをそのまま使えない、分析のために加工が必要といったケースでは、連携の可否だけではなく、パフォーマンスや加工要件の可否といった観点から考える必要があります。データアーキテクチャを検討する際は、「朝8時までに、データ準備処理を終わらせないといけない」、「二年後には数十億件のデータを洗い替え処理する必要がある」など必要なパフォーマンス要件と「複雑な加工処理にも対応できる」といった機能要件について柔軟に対応できるETLプラットフォームを選択してください。

3.障害対応時の柔軟性

朝出社した時もしくは通勤電車の中で、「データが更新されてない、一部データがおかしい」といったビジネスユーザーからの問い合わせによって、朝からその対応に追われる日々を過ごされた経験はないでしょうか?

多くの企業内のデータエンジニアが、日々のタスクとは別にお守りに時間を割かれる日々を過ごしていたりします。

ETLプラットフォームは、日々の障害対応時にも大きなメリットを発揮してくれます。

  1. パイプラインがビジュアルで管理されているため、問題の要因調査、特定が容易である
  2. 問題が起こることを事前に想定し、リトライ処理やエラーになった場合の分岐処理を実装できるワークフローがある
  3. 障害によるデータ更新エラーをその時点で初めて把握するのではなく、ジョブ実行結果のメール通知機能やSlackとの連携、さらにはインシデント管理システムと連携することでリアルタイムでのジョブ監視が可能となる。
  4. データリカバリにかかる時間を短縮するために、スケーラブルにデータ処理能力を上げることができる。

最後に

現在、日本では「データ分析」はもちろんですが「データ準備」というキーワードが非常に注目を集めるようになってきました。データ準備の目的はBIだったり、AIだったり様々ですが、データ活用のためにデータを整備、整形して提供するためのプロセスが「データ準備」と呼ばれています。

データ準備」というキーワードが一般的になった背景として、日本でもビジネス部門でのデータ活用が進み、データ準備を担うことのできる人材採用のニーズが多くなったのと同時に、企業内でそういったプロフェッショナルな人材の必要性が認知されてきたことが、理由として挙げられます。また、業務において課題感を持つデータエンジニアのコミュニティが活性化し、組織を横断したナレッジやノウハウのシェアが促進されていることも大きな理由だと思います。

Xplentyはデータエンジニアの抱える様々な問題を支援する、パワフルなデータ統合プラットフォームです。企業内でデータ準備に多大な労力をかけているデータエンジニアは、パイプライン作成の効率化や自動化により労力を削減することができます。

また、簡単なパイプラインであれば、ビジネスユーザーでもドラッグ&ドロップで作成することができるため、エンジニアのリソース不足という課題に対しても1つの解決策となります。

この機会に是非、2週間の無償トライアルで操作感を体験してみてください。