株式会社primeNumberでChief Product Officerを務めている小林寛和と申します。

私は新卒から今までデータエンジニアとしてキャリアを歩んできました。新卒で入った事業会社ではデータ分析基盤の新規構築をリードし、現在ではtroccoというデータエンジニアのためのサービスを立ち上げてプロダクトの責任者を務めています。

キャリアの大半をデータエンジニアとして過ごし、さらに現在ではそれらの方に向けてサービスを提供している立場として、これからデータエンジニアになろうとしている方に最初に学んでほしい3つのポイントをまとめてみました。

なお、本記事では以下のような方を想定しております。

• これからデータエンジニアになろうとしている
• これからデータ分析基盤を新規に立ち上げようとしている

データエンジニアリングの必修科目とは

データエンジニアリングの必修科目を考えるために、まずはどのようなデータ分析基盤を作ることになるのかをイメージしてみます。

その中で、最初に学ぶべきものと、あえて最初は学ばないものを区別します。ここは筆者の経験により判断していますが、「⁠学ばない」判断をしたものについても一切学ばなくてよいというわけではなく、あくまで注力するもの・しないものという意味合いで捉えていただけますと幸いです。

そして学ぶべき3つの技術要素については記事の後半で詳細に実装方法などをご紹介していきます。

データ分析基盤のアーキテクチャイメージ

まず、最小構成でデータ分析基盤を構築した際に必要な技術をまとめたイメージを作ってみました。

もちろん用途や目的によってアーキテクチャは大きく変わってくるとは思います。この図では、弊社がtroccoを提供していく中で見えてきた、一般的な事業会社でデータ分析基盤を作った場合に必要となる技術スタックを組み合わせてアーキテクチャ図としています。

左から、社内に分散している分析データソースが各種あり、それらをETLジョブでDWH製品（図1ではBigQuery）にロードし、SQLを用いてデータを整備（データモデリング）し、BIツールでの可視化やリバースETLなどを利用してデータ分析・ビジネス活用していくというものです。

最初に学ぶべき3つの技術＝ETL（データ統合）＋データモデリング＋ワークフロー

2023年時点で、データエンジニアの必修科目を3つ挙げるとしたら、それはETLとデータモデリングとワークフローだと考えます。

1つ目の理由としては、先ほどのアーキテクチャ（図1）の中で、この3つは比較的高い専門性を求められることが挙げられます。それぞれの仕組みを理解して技術的な専門性を獲得し、他社の事例からベストプラクティスを学び、その上で自社のニーズに合わせた技術選定・設計・実装を行う必要があるためです。

2つ目の理由としては、今後データ分析基盤の利用が進んでいった場合、この3つの箇所は最も追加・変更が多い箇所だからです。基盤の進化とともに多くの作業が発生するため、単純に専任の担当者を付けないと回らないと言った事情があります。

また、作業をこなせるだけでは意味がなく、将来的な拡張を見据えた仕組み化にも取り組む必要があります。例えば、開発の効率化のためにCI/CDの仕組みを考えたり、提供品質を担保するためにメンテナビリティを上げる努力をしなければなりません。ここではソフトウェア開発と同じレベルの専門性を求められるでしょう。

一方、前章のアーキテクチャ図の中に出現したBIツールやDWHについては「最初に学ぶべきこと」としては除外しています。

DWHとBIツールは、最初に学ばなくて良い理由

DWHとBIツールに関しては、あえてデータエンジニアが最初に学ばなくて良い項目として挙げさせていただきました。

DWH製品は一昔前まではサーバー（ノード）の稼働時間に対して課金が発生し、なおかつマネージドな対象範囲が少なく運用・保守工数が一定発生していました。

それゆえにエンジニアがチューニングやメンテナンスを行う必要があり、エンジニアはその領域で専門性を獲得する必要がありました。

ところがBigQuery、Snowflake、Redshift Serverlessなど、マネージドの範囲が広い製品が増えてきたため、2023年現在ではDWHの管理についてはほとんど専門性を要求されないレベルまで来ていると考えています。

もちろん基盤が成長してデータ量が増えた場合にパーティショニング・クラスタリングなどを考える必要はありますが、少なくとも基盤立ち上げ期における優先順位は下がってきていると考えます。DWH自体の管理よりも、その中でどうデータをモデリングするかが重要になってきていると感じます。

BIツールについては、そもそも製品の種類が多く、比較検討が大変だと思います。そういった意味では知識量を要求されるのですが、どちらかというと学ぶというより、しっかりと利用者のニーズを汲み取って意見をまとめるプロジェクトマネジメント的なスキルが必要とされます。また、高機能な製品も多く存在する一方で、Looker StudioやRedashといった初級者にもおすすめの製品を検討すると良いかと思います。まずはそういったシンプルな機能のものからスモールスタートし、基盤の成長とともに利用者のニーズに合わせたツールを選ぶのが良いように思えます。

フルスクラッチ vs OSS vs SaaS

このあとはETL・データモデリング・ワークフローについて、もう少し詳しく説明をしていきます。

それぞれの技術について触れていく中で、具体例を挙げていきますが、大きく分けて以下の3種類に分けられると思います。

• フルスクラッチ開発
• OSS利用
• SaaS利用

以下に特徴をまとめてみました。選定の際の参考になれば幸いです。

※1 利用自体にエンジニアは不要だが、サービス自体がエンジニアレベルの専門性を必要としていることもある

どれが最適な選択かは、組織のリソース状況やフェーズによるかと思います。一方でデータエンジニア初学者の方は、学ぶべきことがそもそも多いため、ここはSaaSを選択して「実装しない」という選択を取り、その他の専門性を高めることに注力するのがおすすめです。

ETL（データ統合）詳細

ETLとは

ETLはExtract Transform Loadの略ですが、類似語として以下のようなものがあります。

• データローダ、データロード
• データ統合、データ集約
• データ転送

これらは概ね同じ意味を示しており、要するに組織内に分散している分析データソースを、1ヵ所（DWH製品）に集めることを目的としています。

また、「⁠Extract」「⁠Transform」「⁠Load」のそれぞれのプロセスをもう少し詳細に見ていくと、以下の図2のような処理になります。

Extractでは、分析データソース側のAPIを利用してデータを取得します。この際APIから渡されるデータは、データソース側に依存しているため、ファイル形式や圧縮形式は、データソースによって異なる点に注意です。

Transformのプロセスは最も複雑で、まずはExtractで取得されたデータをETLシステムで扱える形式に変換します。データが圧縮されていたら解凍し、CSVやJSONのデータをETLシステムで扱えるフォーマットに変更します。変更するフォーマットは、なんのETLシステムを採用するかによって変わります。PySparkを選定したのであればPythonのDataFrameにしますし、フルスクラッチ開発するのであれば、利用しているプログラミング言語で扱える行列形式のデータ型に変換する必要があるでしょう。

次に、データ変換処理を行います。行や列の絞り込みや、値の変更、集計処理を実施します。

その後、Load処理を行うためにデータのフォーマットや圧縮を行います。どのようなフォーマット・圧縮形式を選ぶかは、転送先のDWH製品によって変わるでしょう。

最後にLoadですが、DWH製品のAPIをコールし、Transformプロセスで生成されたデータをアップロードします。

最近のトレンドはELT？

また、昨今ではETLではなくELTというアプローチが主流になりつつあります。

ETLとELTの違いを図にすると図3のようになります。

分析データソースからデータを取得し、DWH製品に集約するという点ではどちらも共通していますが、その過程が異なります。特にTransformの過程が大きく異なる点に注目です。

ELTパターンでは、データソースのデータをそのままの形で変換せずにDWH製品に取り込みます。この時に生成されるDWH上のテーブルを「データレイク層」と呼びます。

そしてTransform処理はDWH製品上で、SQLを用いて行います。

SQLを用いて変換を行うため、実装難易度が低い点がメリットになります。そのためアナリストの方でも実装ができたり、Transformのためのシステムを必要としません。

その一方で、SQLで表現するのが難しい処理には向いていないというデメリットも存在します。たとえば、外部APIをコールするような処理や、複雑な文字列変換などです。

詳しくは私が執筆したQiitaの記事でも解説しているので良かったら参考にしてください。

ETLの実装方法紹介（OSS/SaaS）

ETLを実現するための技術は数多く存在しており、ここではほんの一部ではありますが、ピックアップしてご紹介します。

データモデリング詳細

データモデリングとは

データモデリングとは、分析データの整備方法を考えることです。DWH製品上にあるデータを、高品質かつビジネス活用しやすい形で整備することです。データモデリングをもう少し要素分解すると、以下の2つの項目をそれぞれ考える必要があります。

• モデリングの設計
• モデリングの実装

モデリングの設計では、最終的にどのような粒度・構成でテーブルを管理するかのルールを決定します。具体的には、テーブル内での列の正規化の話や、データセット・スキーマの切り方などです。

また、0ベースで考えるのではなく、3層構造・スタースキーマ・スノーフレークスキーマ・Data Vault 2.0といったフレームワークを利用して考えると良いと思います。

モデリングの実装の話では、モデリングの設計に基づき、実際にどうやってテーブルを作るかを検討します。

DWH製品上でSQLを実行することによってテーブルを作るという点ではどの手法も共通しているのですが、その抽象度や提供形態（OSS/SaaS）が異なるため、組織に適した技術を選定する必要があります。

これらはデータ分析基盤を立ち上げたタイミングである程度考える必要があると考えます。

データモデリングの実装に必要な構成要素

データモデリングを実装する際、まずはじめに検討すべきは、シンプルにSQLのみを利用してすべて実装する方法です。DWH製品はSQLを実行するためのAPIを提供していますし、管理画面からSQLを実行する方法を提供していることも多く、もっとも簡単な実装方法と言えるでしょう。

しかし、この方法ではSQLやテーブルの管理に悩まされることになります。実際にデータ分析基盤を提供してみると、ETLで作られたデータレイク層よりもSQLによって変換・生成されたテーブルの比率が圧倒的に高くなります。さらにデータ活用が進むと数は指数関数的に増えていくことになり、課題感も強くなっていきます。

そこで昨今では、dbtやDataformといったデータモデリングツールが注目を浴びています。データモデリングツールは、こういった悩みを解決するために、以下のようなSQLを管理しやすくするための仕組みを提供しています。

• SQLの可読性・再利用性を高めるテンプレートエンジン・マクロ機能
• SQLから生成されるデータの品質を担保するためのテスト機構
• SQL・テーブルの依存関係を解決するための仕組み

データモデリングをリードできるエンジニアがいる場合や、アナリストが積極的にデータを活用し始めたタイミングでこういったツールを検討するのが良いでしょう。

データモデリングの実装方法（スクラッチ開発/OSS/SaaS）

以下に、データモデリングを実装する際に利用できる技術をまとめました。

最低限の要件としては、SQLを定期的ないしイベント駆動で実行できる仕組みです。

ワークフロー詳細

ワークフローとは

ワークフローも類似語として以下のようなものがありますが、概ね同じ意味を持っています。

• （ワークフロー）オーケストレーション
• ワークフローエンジン
• ジョブ管理
• 依存関係
• DAG

このセクションまでにETLとデータモデリングについて触れてきましたが、これらの技術を「実行する方法」がワークフローの関心事項です。

ETLやデータモデリングを動かす際に、大きく分けて以下2通りの方法があります。

• ETL・データモデリングツール側の実行機能を使う
• ETL・データモデリングツールをAPIでキックし、実行制御は外部ツールを使う

ETLやデータモデリングのツールは、それぞれのツールで定期実行の仕組みが提供されていることが多くありますが、データ分析基盤が大きくなってくると、後者の方法を使わざるを得なくなります。

これは、ETL→データモデリングは処理の連動関係があることが多いためです。例えば前日分の広告データをETLし、ETLが終わってからデータモデリング（SQL変換）を行う必要があるといった要件が生まれるからです。

このような連動関係のことを依存関係といい、依存関係を解決するための仕組みがワークフローです。

ちなみにこの依存関係の中には、「⁠処理がエラーになったらSlack通知を行う」といった業務フロー・外部連携の話もありますし、「⁠エラーになったら1時間おいてから再実行する」といった制御フローの話も含まれます。

また、ワークフローを作った後は実行・トリガー方法を考える必要があります。こちらも大きく分けて以下3つの方法があるでしょう。

• 定期実行
• トリガー実行（イベント駆動⁠）⁠-- Pub/SubやSNSをSubscribeする-- 外部システムからワークフローをAPI経由でキックする
• アドホックな実行

定期実行はその名の通り、決められたスケジュールに沿って実行する方法です。

トリガー実行も一部の用途で必要となることが多く、例えばS3にファイルが置かれたらS3 Event＋SNS＋Lambda経由でワークフローを動かすなどの連携はよく見かけます。

アドホックな実行は、システム移行などの目的で単発で実行する場合や、エラー時の再実行・リカバリ用途で使うことが多そうです。

ワークフローの実装方法（スクラッチ開発/OSS/SaaS）

以下に、ワークフローを実装する際に利用できる技術をまとめました。

ワークフローに求められる要件としては、DAG（有向非巡回グラフ）を構築できることと、データエンジニアリング系サービスへのコネクタを有することとしています。

この先に学ぶべきこと

そもそもデータエンジニアが学ぶべき技術領域が非常に多岐に及ぶということは、前回の記事にて説明してまいりました。

今回ご紹介したETL、データモデリング、ワークフローは、最初の1歩として学ぶべき技術領域としてご紹介してきましたが、まずは実際にデータ分析基盤を作ってみてください。大小は問いませんので、データを分析できる環境を作り、ビジネスに活用する部分を実践してみていただきたいです。

するとデータ分析基盤で「こういうデータも入れてみたい」だったり「営業の人もSQLを書いて分析してみたい」といったような新たなニーズが生まれるはずです。

そうして広く使われるデータ分析基盤に成長してくると、「⁠攻め」のデータ活用だけでなく「守り」のデータマネジメントの重要性に気づくはずです。

たとえば以下のような課題領域です。

• データの民主化（メタデータの蓄積、データカタログの構築）
• データの品質を担保する（データオブザーバビリティ、データ品質モニタリング）

ここで学べる技術は非常に専門性が高く、なおかつビジネスドメインに依存しにくい汎用的なものです。

重い一歩かもしれませんが、踏み出してみる価値があるのではないでしょうか。