データエンジニアリング：初心者のためのフォーミュラ1にインスパイアされたガイド
データエンジニアリングを学ぶ：初心者向けにフォーミュラ1から学ぶガイド
データエンジニアリング初心者のためのユースケース付き用語集
現代のデータインフラストラクチャについて知りたいデータエンジニア初心者の皆さん、この記事は必読です！
このガイドでは、データエンジニアリングがF1に出会うことになります。しかし、私たちはシンプルに保ちます。
導入
私は強く、概念を例を使って説明するのが最善の方法だと信じています。大学の教授たちはよく言っていましたが、「それを説明するために例が必要なら、あなたはそれを理解していないということです」と。とにかく、私は大学の授業中に注意を十分に払っていませんでしたし、今日は例を使ってデータのレイヤーを説明します。
ビジネスシナリオとデータアーキテクチャ
次の年、新しいチームRed Thunder Racingが私たち（はい、私とあなた）に新しいデータインフラストラクチャの設定を依頼してくると想像してください。
現代のF1では、20年や30年前と比べてデータが重要です。レーシングチームは、驚異的なデータ駆動のアプローチでパフォーマンスを向上させ、ミリ秒単位で改善を行っています。
ラップタイムに関するだけではありません。F1は数十億ドルのビジネスです。ファンエンゲージメントの向上は単なる楽しみではなく、スポーツをより魅力的にすることもドライバーの楽しみではありません。これらの活動は収益を生み出します。堅牢なデータインフラストラクチャはF1ビジネスで競争するために欠かせません。
データレイク、データウェアハウス、データマートという3つの基本的なレイヤーから始めて、レーシングチームをサポートするデータアーキテクチャを構築します。
データレイク
データレイクは、さまざまなソースから生成される未加工の非構造化データのリポジトリとして機能します。例えば、車からのテレメトリデータ（秒ごとのタイヤの圧力、スピード、燃料消費量など）やドライバーの設定、ラップタイム、天候条件、ソーシャルメディアのフィード、チケット販売、マーケティングイベントへの登録されたファン、商品の購入記録など。
あらゆる種類のデータを統合されたデータレイクに格納できます：非構造化データ（オーディオ、ビデオ、画像）、半構造化データ（JSON、XML）、構造化データ（CSV、Parquet、AVRO）。
すべてを1つの場所に統合および統合する際に最初の課題に直面します。マーケティングツールからレコードを抽出するバッチジョブを作成し、リアルタイムのストリーミングテレメトリデータにも対応します（その際、非常に低いレイテンシー要件があります）。
統合するシステムはたくさんありますし、それぞれが異なるプロトコルやインターフェースをサポートしています：Kafka Streaming、SFTP、MQTT、REST APIなど。
このデータ収集には私たちだけではありません。幸いなことに、市場にはデータ統合ツールがあり、統合パイプラインを1か所で構成および維持するために採用できます（アルファベット順に: Fivetran、Hevo、Informatica、Segment、Stitch、Talend、…）。Pythonスクリプトをcrontabで定期的にスケジュールしたり、Kafkaのトピックからのデータストリーミングをカスタムプロセスで処理する代わりに、これらのツールを使用して、これらのすべてのプロセスを簡素化、自動化、オーケストレーションする助けになります。
データウェアハウス
私たちは統合する必要のあるデータストリームを定義して数週間が経ち、現在はさまざまなデータをデータレイクに取り込んでいます。次のレイヤーに移る時がきました。
データウェアハウスは、データレイクからの処理済みデータをクリーン化、構造化、保存し、分析と報告のための構造化された高パフォーマンス環境を提供するために使用されます。
この段階では、データの取り込みについてではなく、ますますビジネスユースケースに焦点を当てていきます。私たちは、次のような定期的に更新される構造化データセットを提供するためにデータが同僚によってどのように利用されるかを考慮する必要があります：
- 車のパフォーマンス：テレメトリーデータをクリーンアップ、正規化、統合して統一されたビューを提供します。
- 戦略とトレンドレビュー：過去のレースデータを使用してトレンドを特定し、ドライバーのパフォーマンスを把握し、特定の戦略の影響を理解します。
- チームのKPI：ピットストップの時間、ピットストップ前のタイヤの温度、車の開発における予算管理など。
データ変換と正規化に専用のパイプラインが多数あります。データ統合の場合と同様に、市場ではデータパイプラインを簡素化し効率的に管理するための製品が数多く提供されています。これらのツールは、データプロセスを効率化し、運用コストを削減し、開発の効果を増大させることができます（アルファベット順に並べると、たとえば：Apache Airflow、Azure Data Factory、DBT、Google DataFormなど）。
データマート
データウェアハウスとデータマートの間には薄い境界線があります。私たちは、多岐にわたる分野で関与する数千人の従業員を抱えるRed Thunder Racingという大企業で働いていることを忘れてはいけません。データは特定のビジネスユニットの要件に合わせてアクセス可能でなければなりません。データモデルはビジネスのニーズに基づいて構築されます。
データマートは、特定のビジネス機能に焦点を当てたデータウェアハウスの専門的なサブセットです。
- 車のパフォーマンスマート：RnDチームは、エンジンの効率性、空力、信頼性に関連するデータを分析します。エンジニアは、さまざまなレーストラックのために車のセットアップを最適化したり、天候条件に基づいて最適な車の構成を理解するためにこのデータマートを使用します。
- ファンエンゲージメントマート：マーケティングチームは、ソーシャルメディアのデータ、ファンの調査、視聴者の評価を分析してファンの嗜好を理解します。マーケティングチームは、このデータを使用してターゲットとしたマーケティング戦略、商品開発、Fan360の知識の向上などを実施しています。
- 付け記録分析マート：財務チームもデータを必要としています（たくさんの数字がありますね！）。レーシングチームは予算制限や規制に対処しなければならなくなりました。予算配分、収益、総合的なコストの概要を追跡することは重要です。
さらに、機密データが承認されたチームのみがアクセスできるようにすることがしばしば要件とされます。たとえば、研究開発チームは、テレメトリ情報への排他的なアクセスを必要とし、そのデータを特定のデータモデルを使用して分析できるようにする必要があります。しかし、彼らは財務報告にアクセスすることが許可されないか、関心がないかもしれません。
私たちのレイヤードデータアーキテクチャは、Red Thunder Racingがデータの力を最大限に活用し、車のパフォーマンス最適化、戦略的意思決定、強化されたマーケティングキャンペーンなど、さまざまな用途に活かすことを可能にします！
それで終わり？
全くそんなことはありません！データアーキテクチャの一端にしか触れていません。考慮すべき統合ポイントはおそらく他にも数百あり、さらに、データ変換、データモデリングに言及するだけでなく、データサイエンス、データガバナンス、データオブザーバビリティ、データセキュリティなどについては触れていません。
しかし、「ローマは一日にして成らず」と言われるように、私たちの今日の予定はすでにかなり充実しています。その中には、データアーキテクチャの最初のドラフト（以下に示す）も含まれます。
結論
データエンジニアリングは魔法の領域であり、それに捧げられた多くの本が存在します。
この旅を通じて、データエンジニアは無制限の統合ツールや、上記に挙げた1つまたは複数のレイヤーをカバーすることを目指すさまざまなデータプラットフォーム（例：AWS Redshift、Azure Synapse、Databricks、Google BigQuery、Snowflakeなど）、ビジネスインテリジェンスツール（例：Looker、PowerBI、Tableau、ThoughtSpotなど）、データパイプラインツールと関わるでしょう。
Red Thunder Racingでのデータエンジニアリングの旅は始まったばかりであり、ツールキットには柔軟性の余地を残すべきです！
データレイヤーはしばしば組み合わせられ、場合によっては単一のプラットフォームで実現されます。データプラットフォームやツールは日々新しい機能をリリースしながら、基準を高め、ギャップを縮めています。この市場は競争が激しいです。
- 常にデータレイクを持つ必要がありますか？それは状況によります。
- データの保存ができるだけ早く（ストリーミングやリアルタイム処理とも呼ばれる）行う必要がありますか？それは状況によります。ビジネスユーザーのデータの新鮮さの要件は何ですか？
- データパイプラインの管理に常にサードパーティのツールに依存する必要がありますか？それは状況によります。
<他に質問がある場合は、プレースホルダーをご利用ください>？それは状況によります。
質問や提案がある場合は、お気軽にLinkedInで私に連絡してください。私は「それは状況によります」という以外の回答を約束します。
この記事で表現されている意見は私個人のものであり、私の雇用者の意見を反映しているものではありません。特に注記されていない限り、すべての画像は筆者によるものです。
この記事に描かれている話、名前、出来事は架空のものです。実在の場所、建物、製品との関連性は意図されておらず、推測されるべきではありません。
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
