ビッグデータアーキテクトとして成功するためのETL活用術

ビッグデータのブームは、あらゆるレベルのデータ専門家に対する無尽蔵の需要を生み出しています。アナリスト、DBA、engineers、セキュリティコンサルタントなど、雇用主は適切なスキルと経験を持つ人材を求めています。これらの専門家の中で最も求められているのは、おそらくビッグデータアーキテクトでしょう。

ビッグデータアーキテクトとは?
なぜビッグデータアーキテクトにとってETLが重要なのか？
ビッグデータアーキテクトはETLをどう使うのか？
ビッグデータアーキテクトにはXplentyを

ビッグデータアーキテクトとは?

建築の世界では、建築家は施主と技術者の橋渡し役です。施主は夢の家のスケッチを持っているかもしれませんが、エンジニアは詳細な設計図があって初めて仕事を始めることができます。建築家は、クライアントのスケッチを手に取り、家のための機能的な設計図を作成します。

データアーキテクトもまったく同じように仕事をしています。企業の利害関係者は、データベースの技術的な知識がなくても、企業がデータから何を必要としているかを知っています。アーキテクトはこれらの利害関係者の前に立ち、次のような質問を投げかけます。

どういったデータソースが利用可能か？
誰がデータを利用するのか？
いつデータを使用するのか？
どのようなデータ処理を行うのか？
どのリポジトリにデータを保存するのか？

要件が明確になると、アーキテクトは次のようなものをカバーする青写真を作成します。

データエンティティとその関係
異なる別々のシステム間のパイプラインを含むデータ処理モデル
ビジネスニーズに応じたデータ処理に必要なコンポーネント（加工処理内容）

ビッグデータアーキテクトは、より複雑な問題の数々に直面していることを除けば、リレーショナルデータアーキテクトと同じように仕事をしています。ビッグデータアーキテクトは、単にデータが大きいということだけではありません（一般的には数桁大きいのですが）。

非構造化データを大規模に処理する
分散ファイルシステムから高速な結果を得る
革新的なデータリポジトリ構造との連携
データ品質の維持とデータスワンプ（沼）の解消

ビッグデータに強いスキルを持っていて、それに適したツールを持っていれば楽になりますが、それでも並大抵のことではありません。

なぜビッグデータアーキテクトにとってETLが重要なのか？

ETL（Extract、Transform、Load）は、データアーキテクチャの基礎となるツールです。70年代に初めて登場したETLプロセスには、3つの重要なステップがあります。

抽出：ETLプロセスでは、本番用のデータベースやクラウドサービスなど、異なるソースからデータを抽出します。
変換：データは変換プロセスを通過します。例えば、ETLはリレーショナルデータベースのテーブルを別のテーブル構造に変換します。
ロード：データが標準化されたフォーマットになると、ETLプロセスはデータウェアハウスなどのターゲットリポジトリにデータをロードします。

70年代以降、データは進化し、ETLプロセスも進化してきました。データアーキテクトは現在、いくつかの方法でデータを移動させることができる洗練されたクラウドベースのETLプラットフォームにアクセスすることができます。ビッグデータアーキテクトにとって、ETLはツールキットの中の1つのツールに過ぎないかもしれません。しかし、ETLは不可欠なツールです。

Integrate Your Data Today!

Try Xplenty free for 14 days. No credit card required.

ビッグデータアーキテクトはETLをどう使うのか？

ビッグデータといえば、ほとんどの人がELT (Extract, Load, Transform)を思い浮かべますが、これはデータレイクに非構造化データを投入するものです。ビッグデータアーキテクトがELTを使用する場合もありますが、ETLが正しい選択肢となるユースケースもいくつかあります。

データパイプライン

データ戦略は、しばしば単純な問題に行き着きます。AからBへデータを取得する最も効率的な方法は何か？答えは、一般的にETLのバリエーションです。データを抽出し、統合プロセスを経て、目的地に届けます。

古いバージョンのETLでは、スケジュールされたCronジョブによるバッチインポートなど、手動または半自動化されたプロセスを使用していました。現代のクラウドベースのETLソリューションにより、アーキテクトは完全に自動化されたパイプラインを構築できるようになりました。これにより、変換が行われるステージング・データベースを介してソースからデスティネーションにデータをプッシュします。

クラウドベースのETLのもう一つの利点は、多くの場合、統合ライブラリが付属していることです。つまり、ビッグデータアーキテクトは、ハンドコード化された統合の開発とテストにリソースを割く必要がないということです。その代わりに、ETLソリューションがサポートされているサービスに自動的に接続することを信頼することができます。さらに良いことに、APIに変更があった場合、ホストはこれらの統合を更新します。

データレイクハウス

ETLの欠点の1つは、構造化データしかサポートしていないことです。ビッグデータアーキテクトの多くは、データレイクなどの非構造化リポジトリを扱っています。そのため、多くのアーキテクトは、オンデマンド変換スキーマを備えたELT（Extract, Load, Transform）に頼っています。

しかし、データレイクにも欠点がないわけではありません。クエリの処理オーバーヘッドがあり、データレイクプラットフォームの中には事実上読み取り専用のものもあります。これら2つの構造の間の妥協点として、データレイクハウスがあります。

このアプローチの利点は、高速なELTプロセスを使用してレイクにデータを投入し、その後、クレンジングされ統合されたデータで個々のデータウェアハウスを満たすことができることです。これをどのように行うのでしょうか？答えは、レイクから直接抽出し、必要なスキーマを適用し、データウェアハウスにロードするETLプロセスです。

ETLT

データアーキテクチャにおける主な課題の1つは、ストレージを処理から切り離すことです。例えば、従来のELTプロセスでは、すべての変換はステージングデータベース上で行われます。例えば、ターゲットリポジトリに保持されているデータでJOIN文を実行する必要がある場合、これはリソースの無駄遣いになるかもしれません。

ETLTアプローチでは、変換処理の負荷をETLTプロセス全体に分散させます。最初の変換は、ETLプロセス内で行われ、データの検証、強化、調合などのタスクが含まれる場合があります。一部変換されたデータは、データウェアハウスなどのリポジトリに送られます。その後、リポジトリの処理リソースを使用して、入力データを既存のデータと統合することができます。

ETLTは、ETLとELTの間の有効な妥協案です。このアプローチを使用して、すべてのデータをETLに通し、メタデータなどの要素を変換することができます。その後、さらなる操作はリポジトリ側で行うことができます。

ストリーミング

企業のアナリティクスへの依存度はますます高まっています。リーダーや管理者は、顧客から物流に至るまで、あらゆることを360度見渡すことができるリアルタイムのダッシュボードへのアクセスを必要としています。データアーキテクチャの観点からは、ビジネスに不可欠なすべてのデータを一元化する必要がありますが、それを可能な限り迅速かつ効率的に行う必要があります。

そこでクラウドETLサービスが役立ちます。ETLのようなプラットフォームは、ソースデータベースとターゲットリポジトリ間の伝送サービスとして機能し、効果的なデータ転送を可能にします。例えば、管理者がERP上で注文を作成した場合、注文データはすぐにデータパイプラインに入り、データリポジトリに反映されます。そこから、それはビジネスユーザーに適切なビジネスインテリジェンスツールへのアクセスを与えるだけです。

リアルタイムとニアリアルタイムの間には大きな違いがあります。高速で応答性が高く、トリガーイベントを見逃さないデータパイプラインを構築する必要があります。また、インジェストの前にどの程度の前処理を行うかというバランスの判断も必要です。複雑な変換はストリーミング分析の速度を低下させる可能性がありますが、より良い扱いやすい結果セットにつながるでしょう。

クラウドセキュリティ

データが輸送中に最も脆弱な状態になるため、ビッグデータアーキテクトは常にセキュリティを第一に考えたアプローチを取らなければなりません。オンプレミスのネットワークがほとんど残っていない時代には、この課題はさらに難しくなっています。ほとんどの組織は、クラウドをベースにしているか、一般的にはクラウドとオンプレミスのコンポーネントを組み合わせたハイブリッド・スタックを採用しています。

クラウドETLは、データの転送元がどこであっても、データを転送する際にセキュリティの追加レイヤーを追加します。送信元のデータソースは、ETLプラットフォームと1対1の接続を持っています。この接続はモジュール化されているため、1つのソースで問題が発生しても、他のソースに影響を与えることはありません。ETLプラットフォーム自体も、データリポジトリと1対1の関係を持っています。この関係は、ソースに依存することなく設定することができます。

変換の段階では、ETL ホストはセキュリティの責任を負います。セキュリティのレベルはプロバイダによって異なりますが、言い換えれば、最適なパッケージを持っているプロバイダーを探して買うことができることを意味します。

メタデータとマスターデータマネジメント

おそらくビッグデータアーキテクトにとって最大の課題は、構造化されていないデータを構造化することです。企業全体のデータで埋め尽くされているリポジトリに、どのようにして秩序をもたらすのでしょうか？

その答えは、メタデータとマスターデータです。優れたアーキテクトは、堅牢なメタデータポリシーを設計します。これにより、企業全体に一貫性が生まれ、カタログ化や検索が容易になります。マスターデータの管理も重要な戦略です。これにより、顧客や製品などのデータ・エンティティに対して、一元性（SVOT）を担保することができます。そして、SVOTを使用してレイクのコンテンツを検証することができます。

メタデータとマスターデータは、多くの場合、リレーショナルデータベースのテーブルに格納するのに適しています。つまり、メタデータやマスターデータを抽出するデータパイプラインを意味します。そしてETLは、中央のデータウェアハウスに移動する前に、このデータをクリーンアップして調合します。