(翻訳) データエンジニアリングビギナーズガイド 第二部

訳者まえがき

原著者の Robert Chang の許可を得て以下の記事を翻訳・公開しました。

medium.com

第一部の翻訳はこちら。

satoshihirose.hateblo.jp

以下から翻訳内容です。

データエンジニアリングビギナーズガイド 第二部 データモデリング、データパーティショニング、Airflow、ETLのベストプラクティス

https://cdn-images-1.medium.com/max/2000/1*BC9-kpfjCPtY-w-GOjPBDA.png イメージクレジットマドリード(CortesíadeIñaquiCarnicero Arquitectura)のHangar 16で改装された現代の倉庫

復習

データエンジニアリングビギナーズガイド 第一部では、組織の分析能力はレイヤー状に構築されることを説明しました。そして、生データの収集とデータウェアハウスの構築から機械学習の適用まで、これらの分野すべてでデータエンジニアリングが重要な役割を果たす理由を知りました。

データエンジニアの最も強く求められるスキルのひとつに、データウェアハウスの設計、構築、および保守の能力があります。そこで、データウェアハウスとは何かを明確にし、ETLという名前の由来となる抽出、変換、およびロードの3つの一般的な要素について説明しました。

ETLプロセスに馴染みがない人向けにLinkedIn、PinterestSpotifyなどの企業によって作られたオープンソースフレームワークをいくつか紹介し、AirbnbオープンソースツールのAirflowを紹介しました。最後に、データサイエンティストがSQLベースのETLパラダイムを使用することで、データエンジニアリングをはるかに効果的に学べると述べました。

第二部概要

第一部の議論はやや抽象的でした。第二部(この記事)では、優れたデータパイプラインを構築する方法に関する技術的な詳細を紹介し、ETLのベストプラクティスを見ていきます。議論では主にPython、Airflow、SQLを使用します。

まず、ビジネスメトリックとディメンションを捉えるためのテーブルスキーマとデータの関連性を注意深く定義する設計プロセスであるデータモデリングの概念を紹介します。そして、より効率的なクエリとデータのバックフィルを可能にする方法であるデータパーティショニングについて学習します。この章を終えれば、読者はデータウェアハウスとパイプライン設計の基礎を理解するでしょう。

その後の章では、Airflowジョブの詳細な構造を解説します。読者は、抽出、変換、およびロードの概念を操作するために、センサー、オペレーター、およびトランスファーをどのように使用するかを学習します。 Airbnb、Stitch Fix、Zymergenなどの実例をもとに、ETLのベストプラクティスを紹介します。

この記事の最後で、読者はAirflowの多才さとConfiguration as Codeの概念を理解するでしょう。実際、Airflowにはこれらのベストプラクティスの多くが既に組み込まれていることがわかります。

データモデリング

https://cdn-images-1.medium.com/max/2000/1*dJApyGzVLr99OAUBh1DcPw.png イメージクレジット:スタースキーマを正しく使用すると、現実の空と同じくらい美しくなります。

あるユーザーがMediumのようなサービスを使うと、その自身のアバター、保存された投稿、閲覧回数などの情報はすべてシステムに保存されます。これらの情報を正確かつ時間通りにユーザに提供するためには、オンライントランザクション処理(OLTP)のための本番データベースを最適化することが重要です。

オンライン分析処理システム(略してOLAP)を構築する場合は、目的はかなり異なります。設計者は洞察を生むことに対して焦点を当てる必要があります。つまり、分析推論を簡単にクエリに変換し、統計を効率的に計算しなければいけません。この分析ファーストなアプローチには、データモデリングと呼ばれる設計プロセスが多くの場合に必要となります。

データモデリング、正規化、およびスタースキーマ

設計上の意思決定の例を示すために、どのテーブルを正規化するかその範囲を決定する必要性がよく発生します。一般に、正規化されたテーブルは、スキーマが単純で、標準化されたデータが多く、冗長性が少ないものです。しかし、小さなテーブルが増えると、データの関連性を追跡するには努力する必要が増え、クエリパターンはより複雑になり(JOINが増えます)、メンテナンスするETLパイプラインが増えます。

一方で、すべてのメトリックとディメンションがすでに事前結合されているような非正規化されたテーブル(別名ワイドテーブル)に問合せを行う方がはるかに簡単です。ただし、サイズが大きい場合は、ワイドテーブルのデータ処理は遅くなり、より上流の依存関係が必要となります。それに伴い、作業単位がモジュール化されず、ETLパイプラインのメンテナンスがより困難になります。

このバランスを取ろうとする数多くのデザインパターンの中で、最も一般的に使用されるパターンの一つであり、Airbnbで使用されるパターンにスタースキーマと呼ばれているものがあります。スタースキーマで編成されたテーブルは星のような型に視覚化することができるため、この名前が生まれました。この設計では、特にファクトテーブルとディメンションテーブルなどの正規化されたテーブルの構築に重点を置いています。必要に応じて、これらの小さな正規化されたテーブルから非正規化テーブルを構築することができます。この設計は、ETLの保守性と分析の容易さの両立を目指しています。

https://cdn-images-1.medium.com/max/800/1*keaNlycSUfgMGHawlcWnzw.png 星のような型に構成されたスタースキーマは、中心にファクトテーブルがあり、ディメンションテーブルに囲まれています。

ファクトテーブルとディメンションテーブル

ファクトテーブルとディメンションテーブルから非正規化テーブルを作成する方法を理解するには、それぞれの役割についてさらに詳しく説明する必要があります。

  • ファクトテーブルには通常、ポイントインタイムのトランザクションデータが含まれています。テーブルの各行は非常にシンプルで、多くの場合トランザクションの単位として表されます。シンプルさのために、ビジネスメトリクスを導出するための「信頼できる唯一の情報源」となることがよくあります。たとえば、Airbnbでは、契約、予約、変更、キャンセルなどのトランザクション同様のイベントを追跡するさまざまなファクトテーブルがあります。

  • ディメンションテーブルは一般的には、緩やかに変化する特定のエンティティの属性を含み、その属性は階層構造で編成されることがあります。ファクトテーブルで使用可能な外部キーが存在するかぎり、これらの属性は多くの場合「ディメンション」と呼ばれ、ファクトテーブルと結合できます。 Airbnbでは、ユーザー、リスティング、マーケットなどのさまざまなディメンションテーブルを作成しており、データの分割、区分に役立っています。

以下は、ファクトテーブルとディメンションテーブル(どちらも正規化されたテーブル)を結合し、各マーケットで過去一週間に何回の予約が発生したかなどの、基本的な分析に関する質問に答える方法の簡単な例です。追加のメトリックm_a, m_b, m_cおよびディメンションdim_x, dim_y, dim_zが最後のSELECT句に投影されるとどうなるか、正規化されていない表をこれらの正規化された表から簡単に作成できることを鋭いユーザーはなら分かるでしょう。

正規化されたテーブルは、アドホックな質問への回答、もしくは非正規化テーブルの構築に使用することができます。

データのパーティショニングと履歴データのバックフィル

https://cdn-images-1.medium.com/max/2000/1*74QUEUyBvqauoROtoVppqQ.png

データストレージコストが低く、計算コストが低い時代においては、企業は過去のデータをすべて捨てるのではなく、ウェアハウスに保存する余裕があります。このようなアプローチの利点は、企業が新しい変化に対応して履歴データを適切に処理し直すことができることです。

データスタンプによるデータのパーティショニング

非常に多くのデータを安易に利用すると、クエリの実行と分析の実行は時間の経過とともに非効率になります。 「早期および頻繁にフィルタリング」、「必要なフィールドのみを射影する」などのSQLベストプラクティスに従うことに加え、クエリのパフォーマンスを向上させる最も効果的な手法の一つは、データをパーティショニングすることです。

データのパーティショニングの背後にある基本的な考え方はどちらかというと単純です。すべてのデータをひとかたまりに格納するのではなく、独立し自己充足なかたまりに分割します。同じかたまりのデータには同じパーティションキーが割り当てられます。つまり、データのサブセットを極めてすばやく検索できます。この手法で、クエリのパフォーマンスは大幅に向上します。

特に、よく使用するパーティションキーは、日付スタンプ(datestamp)dsと略される)であり、それにはきちんとした理由があります。第一に、S3のようなデータストレージシステムでは、生データはしばしば日付スタンプによって編成され、時間によりラベルされたディレクトリに保存されます。さらに、バッチETLジョブの作業単位は通常一日です。つまり、毎日の実行ごとに新しい日付パーティションが作成されます。最後に、多くの分析に関する質問には、指定された時間範囲内で発生したイベントのカウントが含まれるため、日付スタンプによるクエリは非常に一般的なパターンです。 日付スタンプはデータパーティショニングにおけるよくある選択肢です!

dsでパーティション化されたテーブル

履歴データのバックフィル

パーティションキーとして日付スタンプを使用するもう一つの重要な利点は、データのバックフィルの容易さです。 ETLパイプラインが構築されると、メトリックとディメンションが過去にではなく未来にむかって計算されます。たびたび、過去の傾向や動きを再確認したいと思うかもしれません。そのような場合は、過去のメトリックとディメンションを計算する必要があります。この処理のことをデータのバックフィルと呼びます。

バックフィルは非常に一般的です。Hiveは動的パーティションの機能を組み込みました。これは、多数のパーティションで同じSQL操作を実行し、複数の挿入を一度に実行する機能です。動的パーティションの有用性を示すために、各マーケットにおける予約数をearliest_dsからlatest_dsまでダッシュボードにバックフィルする必要があるタスクを考えてみましょう。その際にはこのような感じにするでしょう:

上記の操作は、同じクエリを何度も実行しているが異なるパーティションで実行しているので、やや退屈です。時間範囲が広い場合、すぐに繰り返しの作業となります。ただし、動的パーティションを使用すると、この作業を一つのクエリとして大幅に簡素化できます。

SELECT句とGROUP BY句に追加されたdsWHERE句の展開された範囲におけるPARTITION(ds = '{{ds}}')からPARTITION(ds)への構文の変化に注目してください。動的パーティションの美しさは、GROUP BY dsで必要とされているのと同じ作業をすべてラップし、その結果を関連するdsごとのパーティションに一度に挿入することにあります。このクエリパターンは非常に強力で、多くのAirbnbのデータパイプラインで使用されています。後のセクションでは、Jinjaを使用してバックフィルロジックを組み込んだAirflowジョブのコントロールフローをどのように記述できるかを示します。

Airflowパイプラインの詳細

https://cdn-images-1.medium.com/max/2000/1*Oyvj7KeD-VdlcM2nNb2htw.png

ファクトテーブル、ディメンションテーブル、日付パーティションの概念、データのバックフィルを行うことの意味について学んだので、これらの概念を具体化し、実際のAirflow ETLジョブに入れてみましょう。

Directed Acyclic Graph (DAG)の定義

以前の記事で述べたように、ETLジョブは、抽出、変換、ロードの3つの部品の上に構築されています。概念的に聞こえるほど単純かもしれませんが、現実のETLジョブは複雑で、E、T、Lタスクの大量の組み合わせから構成されています。その結果、グラフを使用して複雑なデータフローを視覚化することは多くの場合に有効です。視覚的には、グラフのノードはタスクを表し、矢印はタスクの依存関係を表します。データがタスクで一度だけ計算される必要がありその後順次進められるものの場合、グラフは方向性があり非周期的です。このため、Airflowジョブは一般に「DAG」(Directed Acyclic Graphs)と呼ばれます。

https://cdn-images-1.medium.com/max/800/1*sTUUer1dRmEeHuc1h0023g.png 出典Airbnbの実験レポートフレームワーク用のDAGのスクリーンショット

Airflow UIに関する巧妙なデザインの一つは、コードを設定として使用して、どのユーザーもグラフビューでDAGを視覚化できるということです。データパイプラインの作成者は、タスクを可視化するためにタスク間の依存関係の構造を定義する必要があります。この仕様は、多くの場合、Airflowジョブの構造を示すDAG定義ファイルと呼ばれるファイルに記述されます。

演算子:センサー、オペレーター、およびトランスファー

DAGはデータパイプラインが実行される方法を記述する一方で、演算子はデータパイプラインが何をするかを記述します。通常、演算子には3つの大きなカテゴリがあります。

  • センサー:特定の時間、外部ファイル、または上流のデータソースを待機する

  • オペレーター:特定のアクション(たとえば、bashコマンドの実行、Pythonの関数実行、Hiveクエリの実行など)をトリガーする

  • トランスファー:データをある場所から別の場所に移動させる

鋭い読者は、これらの演算子のそれぞれが、前述した、抽出、変換、およびロードの各ステップにどのように対応しているのかが分かるでしょう。センサーは、一定時間が経過した後、または上流のデータソースで発生するデータが使用可能になった後に、データフローのブロックを解除します。 Airbnbでは、ほとんどのETLジョブにHiveクエリが含まれていることから、NamedHivePartitionSensorsを使用して、Hiveテーブルの最新パーティションがダウンストリーム処理に使用可能かどうかを確認することがよくありました。

オペレーターはデータの変換をトリガします。これは変換ステップに対応します。 Airflowはオープンソースなので、コントリビューターはBaseOperatorクラスをextendして、適切なカスタムオペレーターを作成できます。 Airbnbでは、HiveOperator(Hiveクエリを実行する)が使用される最も一般的なオペレーターですが、PythonOperatorPythonスクリプトを実行するなど)やBashOperator(たとえばbashスクリプトを実行する、または思いつきのSparkジョブを実行するなど)も使用しています。ここでは可能性は無限大です!

最後に、ある場所から別の場所へデータをトランスファーする特別な演算子もあります。この演算子は、多くの場合ETLのロードステップに変換されます。 Airbnbでは、MySqlToHiveTransferまたはS3ToHiveTransferを使用する頻度はかなり高いですが、これは主にデータインフラストラクチャやデータウェアハウスの場所に強く依存します。

簡単な例

以下は、DAG定義ファイルを定義し、AirflowのDAGをインスタンス化し、上で説明したさまざまな演算子を使用してそれに対応したDAG構造を定義する方法を示す簡単な例です。

DAGがレンダリングされると、次のグラフビューが表示されます。

https://cdn-images-1.medium.com/max/800/1*OMp-WLUdleDWVlBImO4OJA.png

DAGのグラフビューの仮想的な例

従うべきETLのベストプラクティス

https://cdn-images-1.medium.com/max/2000/1*LSvoTalvZTyMU3qi07bgrg.png

イメージクレジット:あなたの技術を磨くには練習が必要であり、そのためにはベストプラクティスに従うことが賢明です

あらゆる技術と同様に、簡潔で読みやすくスケーラブルなAirflowのジョブを書くには練習が必要です。私の最初の仕事では、ETLは私がやらなければならなかった一連の日々の機械的な仕事に過ぎませんでした。それを技術として捉えたり、ベストプラクティスを知ることをしませんでした。 Airbnbでは、ベストプラクティスについて多くのことを学び、良いETLとその美しさを理解し始めました。以下は、網羅的ではありませんが、良いETLパイプラインが従うべき原則の一覧です。

  • データテーブルのパーティショニング:前述したように、データのパーティショニングは、長い履歴を持つ大規模なテーブルを処理する場合に特に役立ちます。データが日付スタンプを使用してパーティショニングされるとき、動的パーティションを活用することでバックフィルを並列化できます。
  • データをインクリメンタルにロードする:この原則により、特にファクトテーブルからディメンションテーブルを作成する場合に、ETLはモジュール化し、管理しやすくなります。各実行では、ファクトテーブルの履歴全体をスキャンするのではなく、以前の日付パーティションのディメンションテーブルに新しいトランザクションを追加するだけです。
  • 冪等性を強制する:多くのデータサイエンティストは、実績分析を実行するためにポイントインタイムスナップショットを頼ります。これは、基礎となるソーステーブルが時間の経過とともに変更可能であってはならないことを意味します。そうでなければ、異なる回答が得られることになってしまいます。同一のビジネスロジックと時間範囲に対して実行された同じクエリが同じ結果を返すように、パイプラインを構築する必要があります。この性質には、冪等性という奇抜な名前があります。

  • ワークフローをパラメータ化する:テンプレートがHTMLページの構成を大幅に簡略化するように、JinjaはSQLと組み合わせて使用​​できます。前述のように、Jinjaテンプレートの一般的な使用法の一つは、バックフィルロジックを典型的なHiveクエリに組み込むことです。Stitch Fixは、このテクニックをETLにどのように使用するかを要約したとても良い記事です。

  • 早期および頻繁にデータをチェックする:データを処理する場合、ステージングテーブルにデータを書き込み、データ品質をチェックしてから、ステージングテーブルを最終的な本番テーブルと交換する方法は有用です。Airbnbでは、これをステージ・チェック・エクスチェンジのパラダイムと呼んでいます。この三ステップのパラダイムでのチェックは、重要な保護機構です。レコードの総数が0より大きい場合や、見えないカテゴリや異常値をチェックする異常検出システムなど複雑な場合に、単純なチェックが可能です。

ステージ・チェック・エクスチェンジ操作の骨組み(データパイプライン用の「ユニットテスト」とも呼ばれる)

  • 有用なアラートと監視システムを構築する:ETLジョブは実行に時間がかかることが多いため、DAGの進行状況を常に監視しなくてもすむように、アラートを追加して監視すると便利です。さまざまな企業がDAGを多様で創造的な方法で監視しています。Airbnbでは、規則的にEmailOperatorsを使用して、SLAを逸したジョブのアラートメールを送信しています。他のチームは、実験の不均衡を警告するためにアラートを使用しています。もう一つの興味深い例に、ZymergenがSlackOperatorでR-squaredなどのモデルパフォーマンスメトリクスをレポートしているといったものがあります。

これらの原則の多くは、経験豊かなデータエンジニアとの会話、Airflow DAGの構築経験、Gerard ToonstraによるAirflowを使用したETLのベストプラクティスなどの全てからインスピレーションを受けています。好奇心旺盛な読者のために、私はMaximeの次のトークを強く勧めます:

出典:Airflowの原著者、Maxime、ETLベストプラクティスについて語る

第二部のまとめ

シリーズ二つ目のこの記事では、スタースキーマとデータモデリングについてさらに詳しく説明しました。ファクトテーブルとディメンションテーブルの区別を学び、特にバックフィル用に、パーティションキーとして日付スタンプを使用する利点を確認しました。さらに、Airflowジョブの詳細な構造を分析し、Airflowで利用できるさまざまな演算子を具体的に確認しました。また、ETLを構築するためのベストプラクティスを紹介し、JinjaとSlackOperatorsを組み合わせて柔軟なAirflowジョブを実行する方法を示しました。可能性は無限大です!

シリーズの最後の記事では、いくつかの先進的なデータエンジニアリングパターン、具体的には、パイプラインの構築からフレームワークの構築へどうやって移るかについて説明します。動機付けの例としてAirbnbで使用したいくつかのフレームワークの例を再び使います。

この記事が役に立った場合は、第一部をみながら第三部を楽しみにしていてください。

貴重なフィードバックを提供してくれたJason GoodmanとMichael Mussonに感謝します。

(翻訳) データエンジニアリングビギナーズガイド 第一部

訳者まえがき

原著者の Robert Chang の許可を得て以下の記事を翻訳・公開しました。

medium.com

原著者は、Airbnb で Data Scientist をしています。

以下から翻訳内容です。

データエンジニアリングビギナーズガイド 第一部 データエンジニアリング: データサイエンスの似た従兄弟

https://cdn-images-1.medium.com/max/2000/1*gjgczPgeWlqWEVHtKYpJUg.png イメージクレジット:IñaquiCarniceroが建築したマタデロマドリードの美しい元屠殺場/倉庫

記事を書いた動機

データサイエンティストとしての経験を経るほど、データエンジニアリングはデータサイエンティストのツールキットの中で最も重要かつ基礎的なスキルの1つであると確信しています。この考えは、プロジェクトや就職機会に対する評価、そして個人の職務領域の広がりの両方に当てはまります。

以前の記事では、データを価値のあるものに変換するデータサイエンティストの能力は、自社のデータ・インフラストラクチャーの段階とデータウェアハウスの成熟度と大きく関連していると指摘しました。これは、データサイエンティストが、自分のスキルが企業の段階と必要性に揃っているかを慎重に評価するために、データエンジニアリングについて十分に知っておく必要があることを意味します。さらに、私が知っている偉大なデータサイエンティストの多くはデータサイエンスに強いだけでなく、そうでなければ到達できないより大きく野心的なプロジェクトを行うための隣接する分野としてデータエンジニアリングを活用することに対して戦略的でもあります。

その重要性にもかかわらず、データエンジニアリングに対する教育は限られていました。生まれたばかりの分野であることもあり、多くの点でデータエンジニアリングの訓練を受ける唯一の実現可能な道は仕事上で学ぶことであり、時には遅すぎることもあります。私はこの科目を忍耐強く教えてくれたデータエンジニアと一緒に働いていたことは大変幸運です。しかし、誰もが同じ機会を得られるわけではありません。その結果として、私はこのビギナーズガイドを書き、そのギャップを埋めるために学んだことをまとめることにしました。

このビギナーズガイドの構成

私の議論の範囲は決して網羅的ではなく、Airflowバッチデータ処理、およびSQL-like言語を中心にするつもりです。つまり、読者がデータエンジニアリングの基本的な理解を得るのを妨げないでしょう。この急速に成長しつつある新しい分野についてもっと学ぶために興味をそそられることを願っています。

  • 第一部(この記事)は、高度な入門記事として作成されています。個人的な逸話と専門家の洞察を組み合わせて、データエンジニアリングが何であるか、それがなぜ難しいのか、それがどのようにしてあなたやあなたの組織が拡大するのを助けることができるのかを具体的に説明します。この記事の主な読者は、就職の機会を評価するための基礎を学ぶ必要のある野心のあるデータサイエンティスト、もしくは最初のデータチームを構築しようとしている初期段階の創業者です。

  • 第二部は本質的な技術に関するものです。この記事は、ワークフローをプログラムで作成、スケジュール、および監視するためのAirbnbオープンソースツールであるAirflowに焦点を当てています。具体的には、AirflowHiveバッチ・ジョブを作成する方法、スター・スキーマなどの手法を使用してテーブルのスキーマを設計する方法、最後にETLを構築するためのベスト・プラクティスについて説明します。この記事は、データエンジニアリングスキルを磨こうとしている初期段階のデータエンジニアおよびデータエンジニアに適しています。

  • 第三部ではこのシリーズの最後の記事となる予定しです。ここでは、高度なデータエンジニアリング・パターン、より高いレベルの抽象化、およびETLの構築をより簡単かつ効率的にする拡張フレームワークについて説明します。これらのパターンの多くは、難解な方法を学んだAirbnbの経験豊富なデータエンジニアから教えを受けたものです。これらの洞察は、ワークフローをさらに最適化しようとしている経験豊富なデータサイエンティストやデータエンジニアにとって特に役立ちます。

現在私が隣接する分野としてデータエンジニアリングを学ぶことについて影響力を持った支持者であることを考えると、数年前は正反対の意見であったことに驚くかもしれません。私が最初の職に就いていた間には動機付けや感情的な奮闘がありました。

大学院を出た私の最初の仕事

大学院を出た直後、私はワシントンポストに所属する小さなスタートアップで最初のデータサイエンティストとして雇われました。無限の願望と共に、最も洗練されたテクニックを使用して最も難解なビジネス問題に取り組むための分析に準備されたデータが提供されると確信していました。

仕事を始めてすぐ、私の主な責任は想像したほど魅力的ではないことを知りました。代わりに、私の仕事はより基礎的なものでした。自分のサイトにアクセスしたユーザーの数、各ユーザーがコンテンツの閲覧に費やした時間、およびユーザーが記事をライク、リツイートした頻度を追跡するという重要なパイプラインを維持することでした。質の高いコンテンツを無料で提供してくれる代わりに、私たちが所属する出版社に読者に関わる洞察を伝えたので、確かに重要な仕事でした。

公にはしていませんでしたが、私は近い将来にその仕事を完了させることで、ここで説明するように、次は素晴らしいデータ製品を作る仕事に移れるようになることをいつも願っていました。結局のところそれがデータサイエンティストに期待されていることだ、と自分に言い聞かせていました。チャンスが巡ってくることはなく、数ヶ月後、私は失望と共に会社を辞めました。残念なことに、私の個人的な体験は、新しい労働市場で経験の浅い初期のスタートアップ(需要側)または新米のデータサイエンティスト(供給側)に馴染みが薄い人々すべてには共感されないかもしれません。

https://cdn-images-1.medium.com/max/1600/1*a-gxXI6hPZe9uuRYl1MYWQ.png イメージクレジット:ETLパイプラインを一生懸命に構築している私(真ん中の青い男性)

この経験の結果、私の不満は現実世界のデータプロジェクトが実際にどのように機能しているかをほとんど理解していないことに根ざしていることに気付きました。私は生データのワイルド・ウェストに放り出されました。あらかじめ処理され整頓された.csvファイルが存在する快適な土地とは程遠いものでした。それが平常状態である環境においては、私はなすすべがなく、居心地の悪さを感じていました。

多くのデータサイエンティストは、キャリアの早い段階で同様の道のりを経ていました。上級者たちは、この現実とそれに関連する課題を迅速に理解していました。私自身も、ゆっくりと徐々にこの新しい現実や仕事に適応しました。時間がたつにつれて、計装のコンセプトを発見し、マシン生成のログと奮闘し、多くのURLとタイムスタンプをパースしました。その中で最も重要なのは、SQLを学習したことです(気になっている読者用に。最初の仕事に先立ってSQLへの私の唯一触れたJennifer Widomの素晴らしいMOOCはこちら

現在では、私は、慎重かつ思慮深く計測することが分析が主に対象としていることであることを理解しています。このタイプの基礎的作業は、生まれ続ける流行語やハイプで満たされた世界に住んでいるときには特に重要です。

分析の階層

退屈なデータサイエンスの一面とメディアが時に切り出すバラ色の描写との間に矛盾があることを指摘した多くの提唱者の中で、特にモニカ・ロガティ氏はAIを採用しようとしている企業に対して警告しました。

人工知能欲求のピラミッドの頂点と考えてください。もちろん自己実現(AI)は素晴らしいですが、まずは食料、水、シェルター(データリテラシー、データ収集、データインフラストラクチャー)が必要です。

このフレームワークは物事を大局的に捉えさせてくれます。企業がビジネスをより効率的に最適化したり、データ製品をより賢く構築したりするには、基礎的作業のレイヤーを最初に構築する必要があります。このプロセスは、将来的に自己実現する前には食糧や水のような生存の必需品を気にすなければならないという道のりに似ています。このルールは、企業がニーズの順番の通りにデータ人材を雇うべきであることを意味します。スタートアップ企業において災害を引き起こす原因の1つに、最初のデータ人材としてデータモデリングに特化し、他のすべての前提条件である基礎レイヤーを構築する経験がほとんどない人材を雇うことがあります(私はこれを「不適当な採用順序問題」と呼んでいます)。

https://cdn-images-1.medium.com/max/1600/1*2XybEH3eav63pBIu-tlRlw.png 出典:モニカ・ロガティの素晴らしいミディアム上の記事「AIにおける欲求の階層」

残念なことに、多くの企業では、既存のデータサイエンストレーニングプログラムのほとんどは学術的または専門的であり、ピラミッドの知識の頂点に集中する傾向にあることに気付きません。パブリックAPIを使用して生データをスクレイプし、用意、またはアクセスすることを学生に奨励する最新のコースでも、ほとんどの場合、テーブルスキーマを適切に設計する方法やデータパイプラインを構築する方法を学生に教えるわけではありません。その結果、現実のデータサイエンスプロジェクトの重要な要素の一部が翻訳で失われました。

幸いなことに、ソフトウェアエンジニアリングが職業としてフロントエンジニアリング、バックエンドエンジニアリング、サイト信頼性エンジニアリングに区別されているように、私たちの分野も同様により成熟したものになると予測しています。人材構成は時間が経つにつれてより専門化し、データ集約型アプリケーションの基礎を構築するスキルと経験を持つ人材が増えるでしょう。

この将来の眺望はデータサイエンティストにとって何を意味するでしょう?私は、すべてのデータサイエンティストがデータエンジニアリングの専門家になる必要があるとまでは主張はしません。しかし、私は、すべてのデータサイエンティストが、能力と問題の一致を最大化するために、プロジェクトと雇用機会を評価するために十分に基礎を知っているべきだと考えています。解決に興味のある問題の多くが更なるデータエンジニアリングスキルを必要としていることがわかったら、データエンジニアリングの学習にもっと投資するのに遅すぎることはありません。これは実際に私がAirbnbで取ったアプローチです。

データ基盤とウェアハウスの構築

データエンジニアリングを学ぶ上での目的や興味のレベルにかかわらず、データエンジニアリングが何であるかを正確に知ることが重要です。AirflowのクリエーターであるMaxime Beauchemin氏は、彼の素晴らしい記事「The Rise of Data Engineer」(訳注: 拙訳「データエンジニアの始まり」)でデータエンジニアリングを特徴づけました。

データエンジニアリング分野は、ソフトウェアエンジニアリングから多くを受け継いだBIデータウェアハウスの上位集合と考えられるかもしれません。この学問は、拡張されたHadoopエコシステム、ストリーム処理、および大規模計算に関する概念とともに、いわゆる「ビッグデータ」分散システムの運用周りの専門性を統合しています。

データエンジニアが行うたくさんの価値ある仕事の中で、とても求められるスキルの1つは、データウェアハウスの設計、構築、および保守の能力です。小売倉庫のように消耗品がパッケージ化されて販売されているのと同様に、データウェアハウスは生データが変換され、クエリ可能な形式で格納される場所です。

https://cdn-images-1.medium.com/max/1600/1*tcDY4JKmvgfR0x_x0gpS_Q.png 出典:UC Berkeley CS 194コースからのJeff Hammerbacherのスライド

多くの点において、データウェアハウスは、高度な分析、ビジネスインテリジェンス、オンライン実験、機械学習などを可能にするエンジンであり、燃料でもあります。以下は、さまざまな段階の異なる企業のデータウェアハウスの役割を強調する具体的な例です。

  • 500pxにおける分析環境の構築:この記事では、Samson Huが500pxが製品市場の範囲を超えて成長しようとした際に直面した課題について説明します。同氏は、データウェアハウスをどのようにゼロから構築したかを詳しく説明しています。

  • Airbnbの実験プラットフォームの拡張Jonathon Parksは、Airbnbのデータエンジニアリングチームが、実験レポートフレームワークのような内部ツールにパワーを供給する専門的なデータパイプラインを構築した方法を説明しています。この仕事は、Airbnbの製品開発文化の形成と拡大に不可欠です。

  • Airbnbで家の価値を予測するための機械学習の利用:私自身によって書かれたものですが、なぜバッチ学習を構築するのか、なぜオフラインスコアリングの機械学習モデルは前もって多くのデータエンジニアリング作業を必要とするのかにつちえ説明しています。特に、特徴量エンジニアリング、構築、および学習データのバックフィルに関連する多くのタスクは、データエンジニアリングの仕事に似ています。

これらの基礎的なウェアハウスがなければ、データサイエンスに関連するすべての活動は高価になるか、またはスケーラビリティに欠けます。たとえば、適切に設計されたビジネスインテリジェンスウェアハウスがなければ、データサイエンティストは、よく尋ねられる同じ基本的な質問に対して異なる結果を報告することがあります。最悪の場合、誤って本番データベースに直接問い合わせをし、遅延やシャットダウンを引き起こします。同様に、実験レポートパイプラインがなければ、深い調査が必要な実験は甚だ手作業を繰り返し行うことになるでしょう。最終的にはラベル収集または特徴量計算をサポートするデータインフラストラクチャがなくても、トレーニングデータの構築には非常に時間がかかるかもしれません。

ETL:抽出、変換、およびロード

上で参照したすべての例は、Extract、Transform、およびLoadを表すETLという共通のパターンに従います。これらの3つの概念的なステップは、ほとんどのデータパイプラインがどのように設計され、構造化されているかを表しています。生データが分析可能データに変換される方法の青写真として機能します。このフローをより具体的に理解するために、Robinhoodのエンジニアリングブログから引用した次の画像が非常に有用であることに気づきました。

https://cdn-images-1.medium.com/max/800/1*Uo56hrm9r5L_5fmPsY7I9A.png 出典Vineet GoelのMedium上の記事「RobinhoodがAirflowを使用する理由」

  • 抽出:センサが上流のデータソースが到着するのを待つステップです(上流のソースは、マシンまたはユーザが生成したログ、リレーショナルデータベースのコピー、外部データセットなどです)。利用可能になると、ソースの場所からさらなる変換に向けてデータを転送します。

  • 変換:これがETLジョブの中心です。このステップではビジネスロジックを適用し、フィルタリング、グルーピング、および集計などのアクションを実行して、生データを分析可能データセットに変換します。このステップには、多くのビジネスの理解とドメインの知識が必要です。

  • ロード:最後に、処理されたデータをロードして最終的な目的地に転送します。多くの場合、このデータセットはエンドユーザーによって直接消費されるか、別のETLジョブの上流の依存性として処理され、いわゆるデータ系列を形成します。

すべてのETLジョブはこの共通のパターンに従いますが、実際のジョブそのものは使用方法、効用、および複雑さの点においてかなり異なるでしょう。これは、Airflowのジョブの非常にシンプルで簡単な例です:

出典:DataEngConf SF 2017のArthur Wiedmerのワークショップ

上記の例は、実行日時になってから1秒後に毎日bashで日付を出力するだけですが、現実のETLジョブははるかに複雑になる可能性があります。たとえば、本番データベースから一連のCRUD操作を抽出し、ユーザーの非アクティブ化などのビジネスイベントを導出するETLジョブがあるかもしれません。別のETLは、いくつかの実験設定ファイルを取り込み、その実験に関連するメトリックを計算し、最後にUIでp値および信頼区間を出力して、製品の変更がユーザーの解約を妨げているかどうかを知らせることができます。さらに別の例としは、数日​​後にユーザーが解約するかどうかを予測するために、機械学習モデルのための特徴を日次計算するバッチETLジョブがあります。可能性は無限大です!

ETLフレームワークの選択

ETLの構築に関しては、さまざまな企業が異なるベストプラクティスを採用する可能性があります。長年にわたり、多くの企業がETLを構築する際の共通の問題を特定する上で大きな進歩を遂げ、これらの問題をよりエレガントに解決するためのフレームワークを構築しました。

バッチデータ処理の世界では、いくつかの明白なオープンソースの競合があります。いくつか例を挙げると、Linkedinがオープンソース化したAzkabanは、Hadoopのジョブ依存関係を簡単に管理できるようにします。Spotifyが2014年にオープンソース化したPythonベースのフレームワークLuigi、同様に2015年にPinterestがPinballを、AirbnbがAirflow(こちらもPythonベース)をオープンソース化しました。

異なるフレームワークにはそれぞれ長所と短所があり、多くの専門家がそれらを幅広く比較しています(こちらこちらを参照ください)。採用するフレームワークにかかわらず、いくつかの機能を検討することが重要です。

https://cdn-images-1.medium.com/max/800/1*WszG7tFQbuQrYAHnNzxnlg.png 出典:Marty TrencseniのLuigi、Airflow、およびPinballの比較

  • 設定:元来ETLは複雑であり、データパイプラインのデータフローを簡潔に記述できる必要があります。その結果として、ETLがどのように作成されるかを評価することが重要となります。 UI、ドメイン固有の言語、またはコードで設定を行いますか?今日では、「Configuration as Code」の概念は普及し続けています。なぜなら、ユーザーがプログラム可能、カスタマイズ可能なパイプラインを表現できるよう構築できるためです。

  • UI、モニタリング、アラート:ジョブ自体にバグがない場合でも、長時間実行されるバッチ処理は必然的にエラー(クラスタ障害など)に陥る可能性があります。その結果、長時間実行されているプロセスの進行状況を追跡するには、監視とアラートが不可欠です。フレームワークは仕事の進捗状況に関してどんな視覚的情報を提供しますか?適時かつ正確にアラートや警告は表示されますか?

  • バックフィル:データパイプラインが構築されたら、時間を遡って過去のデータを再処理する必要があることがよくあります。理想的には、過去のデータをバックフィルするためのジョブと現在または将来のメトリックを計算するジョブの2つの別々のジョブを構築することは理想的ではありません。フレームワークはバックフィルをサポートしていますか?標準化され、効率的でスケーラブルな方法でこれを行うことができますか?これらはすべて重要な検討事項です。

私は、もちろんAirbnbで働く人としてAirflowを楽しんでいて、データエンジニアリングの仕事で遭遇した多くの一般的な問題に見事に対処してくれることを本当に感謝しています。デファクトのETLオーケストレーションエンジンとしてAirflowを正式に使用している120社以上の企業があることを考えると、Airflowは新世代のスタートアップ企業向けのバッチ処理の標準となる可能性があると主張するまであるかもしれません。

2つのパラダイムSQL中心のETL v.s. JVM中心の ETL

上記からわかるように、企業ごとにETLを構築するためのツールとフレームワークは大幅に異なるため、新しいデータサイエンティストとしてどのツールに投資するかを決定するのは非常に混乱することがあります。

Washington Post Labsでは、ETLは主にCronで最初にスケジュールされ、ジョブはVerticaスクリプトとしてまとめられていました。 Twitterでは、ETLジョブはPigで構築されていましたが、最近はTwitterの独自のオーケストレーションエンジンScaldingによって書かれ、スケジュールされています。 Airbnbでは、データパイプラインは主にAirflowを使ってHiveで書かれています。

最初の数年間、私はデータサイエンティストとして働いていましたが、組織が選んだものをそのまま受け取り、従っていました。私がJosh Willの話に出会った後に、ETLのパラダイムは2つあり、データ・サイエンティストは会社に入社する前にどちらのパラダイムが好むのかを真剣に考えなるべきだと気づきました。

https://cdn-images-1.medium.com/max/800/1*x1yKCJqTFFftEfn6G4jTlA.png ビデオソース:Josh WillsのKeynote @ DataEngConf SF 2016

  • JVM中心のETLは、通常JVMベースの言語(JavaScalaなど)で構築されます。これらのJVM言語のデータパイプラインに対するエンジニアリングは、しばしば命令的な方法でデータ変換を考えることを伴います(例えば、キーと値のペアなど)。ユーザー定義関数(UDF)の作成には、あまり苦労はしません。なぜなら、異なる言語で記述する必要がなく、同じ理由でテストジョブを簡単に行うことができるためです。このパラダイムはエンジニアにとって非常に一般的です。

  • SQL中心のETLは、通常、SQL、Presto、またはHiveなどの言語で作成されます。 ETLジョブはしばしば宣言的な方法で定義され、ほとんどすべてがSQLとテーブルを中心としています。 UDFの作成は、異なる言語(JavaPythonなど)で記述する必要があるため、時には面倒であり、これによりテストがさらに難しくなる可能性があります。このパラダイムはデータサイエンティストに人気があります。

両方のパラダイムの下でETLパイプラインを構築したデータサイエンティストとして、私はもちろんSQL中心のETLが好きです。実際、私は、新しいデータサイエンティストとして、SQLパラダイムで操作するときに、データエンジニアリングについてもっと迅速に学ぶことができると主張しています。なぜでしょうか? SQLの学習はJavaScalaを習得するよりもはるかに簡単です(すでに慣れていない場合)。新しい言語の上に新しいドメインを構築するよりも、データエンジニアリングのベストプラクティスの学習に力を注ぐことができます。

ビギナーズガイドまとめ - 第一部

この記事では、分析がいくつかのレイヤーの上に構築されていることを学びました。そして、成長する組織をスケールさせるためには、データウェアハウスの構築などの基礎的な作業が不可欠です。 ETLを構築するためのさまざまなフレームワークパラダイムについて簡単に説明しました。しかし、学習することや議論することはまだまだあります。

このシリーズの二つ目の記事では、具体的な内容に触れ、AirflowでHiveバッチジョブを構築する方法をお見せします。具体的には、Airflowジョブの基本的な分析を学び、パーティションセンサやオペレータなどの構成要素を介してアクションの抽出、変換、ロードを確認します。スタースキーマなどのデータモデリング手法を使用してテーブルを設計する方法を学習します。最後に、非常に有用ないくつかのETLベストプラクティスについて説明します。

この記事が有用だと思ったら、第二部第三部をお楽しみに。

(翻訳) データエンジニアの没落

訳者まえがき

下記の翻訳記事と対になる、データエンジニアの役割についての記事を翻訳しました。

satoshihirose.hateblo.jp

オリジナルの記事は下記のリンク先のもので、原著者は上記記事と同様に、Apache Airflow や Apache Superset のクリエーターで現在は Lyft で Data Engineer をしている Maxime Beauchemin です。

medium.com

以下から、翻訳記事の内容です。

データエンジニアの没落(翻訳)

この記事では、データエンジニアリングを定義しようとした最近のブログ記事である「The Rise of the Data Engineer」(訳者注: 拙訳「データエンジニアの始まり」)をフォローアップし、この新しい役割がデータ空間において歴史的、現代的な役割にどのように関係しているかを説明します。 この記事では、データエンジニアを悩ませる課題とリスクを明らかにし、思春期を過ぎるに際しこの学問分野に対抗して働く力を列挙したいと考えています。

この記事のタイトルはセンセーショナルで、内容は非常に悲観的ですが、私はデータエンジニアリングを強く信じていることに留意してください。前の記事と対比的な強いタイトルが必要でした。その役割が直面している逆境を理解し明らかにすることは、解決策を見出すための第一歩です。

また、ここに記す意見は私自身のものであり、シリコンバレーの数十のデータチームの人々と会話をしながら観察した結果に基づいています。これらの見解は私の雇用主の見解ではなく、現在の私の立場に直接関係しています。

退屈 & コンテキストの切り替え

ペンキが乾くのを見ることは、Extract Transform and Load(ETL)ロジックを記述して維持することと比べ、エキサイティングです。ほとんどのETLジョブは実行に長い時間がかかり、エラーまたは問題は実行時に発生する傾向があり、実行後のアサーションとなりがちです。開発時間と実行時間の比率は通常低いため、高い生産性を保つことは複数のパイプラインを同時に処理することを意味し、本質的に多くのコンテキストの切り替えを実行することを意味します。あなたの5つの 「ビッグデータジョブ」のうちの1つが終了する頃には、何時間も前の精神空間に戻り、次のイテレーションを作り上げる必要があります。どのようにカフェインを摂取しているか、最後のイテレーションからどれぐらいの時間が経過しているか、あなたがどのくらい計画的かに依存しますが、短期記憶の中の完全なコンテキストを取り戻すことはできないでしょう。これは時間を無駄にする全体的で愚かなエラーにつながります。

イテレーションサイクルごとの待機時間を1時間ごとにカウントすることにより、「皿回し」状態を維持することに取り憑かれてしまいます。午後11時30分の5-10分の仕事により翌日の2-4時間が節約できる場合、不健全なワークライフバランスになりがちです。

コンセンサスの追求

旧来のデータウェアハウジングの概念が消えつつあるとあなた考えているかどうかにかかわらず、対応付けられたディメンションとメトリックを達成することの追求は、それまで通り関連があります。私たちの多くは、人々が依然として一日おきに「Single Source of Truth(信頼できる唯一の情報源)」と言っているのを聞いています。データウェアハウスはビジネスを反映する必要があり、ビジネスの分析方法を明確にする必要があります。異なる名前空間または「データマート」にわたる矛盾した命名法と矛盾したデータは問題となります。意思決定を支援するために信頼を構築したい場合は、一貫性整合性が最低限必要です。現代の大規模な組織では分析プロセスにおけるデータ生成に何百人もの人々が関与していますが、コンセンサスの追求は、直ちに不可能ではないにしろチャレンジングなものです。

歴史的に、さまざまなプラットフォームに散在する不均一な分析や一致しない参照用データに関する問題を名付けるために、人々は「データサイロ」という蔑称を使用しました。サイロはプロジェクトの開始に伴って自然に生まれ、データの取得が発生する際に必然的にチームは混乱します。Master Data Management(MDM)データ統合、野心的なデータウェアハウジングプログラムなどのコンセンサスを取り付けるための方法論を使用し、これらの問題を解決することがビジネスインテリジェンス(現在のデータエンジニアリング)チームのタスクです。近年、現代の変化のペースが早い企業において、サイロの問題は急速に拡大しています。そこでは、「ダークマター」という用語を使用して、起こっている混乱の拡大の結果を表現することができます。適任ではない人々の集団がことを始めると、パイプラインのネットワークはすぐに混沌とし、調和のない無駄なものとなる可能性があります。データエンジニアが「データウェアハウスの図書館員」だとしたら、彼らの使命は巨大なリサイクルプラントでの出版物の分類作業のようだと感じるかもしれません。

ダッシュボードのライフサイクルが数週間ごとに数えられるような世界では、コンセンサスは、ビジネスの変化率や転換に追いつかないバックグラウンドのプロセスになります。伝統主義者はデータ・スチュワードシップとオーナーシップ・プログラムの開始を提案していますが、一定の規模とペースにおいては、こうした努力は拡大には見合わない弱い勢力となっています。

変更管理

有用なデータセットが広く使用され、大規模かつ複雑な依存性の有向非循環グラフ(DAG)を使用した方法で生み出されるようになると、ロジックもしくはソースデータを変更により下流の構造を破壊および/または無効にしがちです。上流の変更を反映するために、派生データセット、レポート、ダッシュボード、サービスおよび機械学習モデルのような下流のノードは変更および/または再計算が必要です。一般にデータ系統に関するメタデータは、通常は不完全であるかコード中に埋め込まれており、選ばれし少数の人々のみが読むための能力と忍耐力を有しています。上流の変更は必然的に、下流のエンティティを複雑な方法で破壊し無効にします。組織がどの程度精度よりも安定性を評価するかによっては、変化は恐ろしいもので、パイプラインの便秘につながる可能性があります。データエンジニアのインセンティブが安定性と連動している場合、彼らは、何も壊さない最良の方法は何も変えないことである、と速やかに学ぶでしょうです。

パイプラインは一般的に大規模で高価なため、適切なユニットテストや統合テストの実施は多少なりとも比例的である可能性があります。ここでの要点は、サンプリングされたデータとドライランで検証できるのはごくわずかというです。そして、あなたが扱えないほど単一の環境が混乱していると思ったら、複雑で異なるコードとデータを使用する開発環境とステージング環境を捨てやったとしても、正常な状態にしてください!私の経験上、大規模データの世界では、まともな開発環境やテスト環境を見つけるのはまれです。多くの場合、あなたが見つけられる最高のものは、文書化されていなくとも人々が適切であるとするプロセスをサポートするために使用する、名前空間の「サンドボックス」です。

データエンジニアリングでは、「DevOpsのムーブメント」についてのボートを見逃してしまい、現代のエンジニアに提供される心の平安と平穏の恩恵を受けることはめったにありません。彼らは姿を表さなかったのでボートを逃したのではなく、貨物のためのチケットが高価すぎたのでボートを逃したのです。

テーブルの最悪の座席

現代のチームの動きは速いですが、組織がエンジニアリング駆動、PM駆動、デザイン駆動のいずれであっても、そしてデータ駆動型であると考えているかどうかに関わらず、データエンジニアはそれほど駆り立てられないでしょう。インフラストラクチャーの役割と考えるべきです。その役割は、人々が当然のことを考えるものであり、壊れているときや約束が満たされていないときに注意を集めるものです。

会話に参加しているデータエンジニアがいる場合は、おそらくデータサイエンティストとアナリストが必要としているデータを収集するのを手助けします。対象のデータがデータウェアハウスの構造化された部分でまだ利用可能でない場合、その機会はデータエンジニアがデータを適切に記録し最終的にそのデータをウェアハウスに運ぶのを助ける一方、アナリストは生データをクエリする短期的な解決策を進めることとなるでしょう。ほとんどの場合で回答はタイムリーに必要であり、新しいディメンションとメトリックがウェアハウスに埋め戻される頃には、すでに古いニュースであり、皆は他に移っています。アナリストはその洞察に対する名誉を得て、その他の皆はこの新しい情報をウェアハウスに統合する時間のかかるバックグラウンドプロセスの必要性について疑問を呈するかもしれません。

従業員の業績レビューでは「インパクト」(速度と混乱を意味する)が最も求められていますが、データエンジニアリングは小さな短期間のインパクトであり、時間のかかるバックグラウンドプロセスであると責められます。データエンジニアたちは、「目立った変化を起こす」人から取り除かれた等級に位置します。

運用負荷

運用負荷は、自らが構築するシステムをサポートする専門職にとっては難しい現実です。 Q/Aチームは、「自らで構築したものは自らでサポートする」というモットーとこのアイデアに集まった現場の人々に大部分が置き換えられました。このアプローチは、技術者の意識を高め、技術的負債の蓄積に責任をもたせる適切な方法とみなされています。

データエンジニアリングには通常メンテナンスにかなりの負担がかかりますので、運用負荷は早く現れ、エンジニアを雇うよりも早くエンジニアを武装解除させます。もちろん、現代的なツールは人々の生産性を向上させますが、それはおそらくパイプラインビルダーが一度に多くの円盤を回転させることを可能にする機械に過ぎないでしょう。

さらに、運用負荷によって従業員の転職率が高くなる可能性があり、最終的には品質が低く一貫性がなく、維持できないめちゃくちゃなものとなってしまいます。

本当のソフトウェアエンジニアか?

この分野の人々は、データエンジニアが「本当のソフトウェアエンジニア」であるのか、異なるクラスのエンジニアであるのかについての議論を聞いています。一部の組織では、役割は異なり、異なる(低い)給与バンドを持っているかもしれません。カジュアルな観測では、コンピュータサイエンスの学位を持つデータエンジニアの割合は、ソフトウェアエンジニアリング全体のそれよりも著しく低いようです。

この記事で述べた理由により、その役割は悪循環を生む悪評判を被る可能性があります。

しかし、待って - まだ希望がある!

まだ立ち去らないでください!データが重要な競争優位性を持つという大きなコンセンサスは存在しており、企業はこれまで以上に分析に投資しています。 「データ成熟度」は予測可能な成長曲線に従い、それは最終的にはデータエンジニアリングが非常に重要であるという認識につながります。これまで示してきたように、何百もの企業が長期的なデータ戦略を倍増させ、データエンジニアリングに投資しています。その役割は存続しており、成長しています。

多くの企業がデータROIを安定水準に保ち、「データ運用の先端」に対する不満を感じると、今後のイノベーションがここで述べた苦労点に対処し、最終的にはデータ工学の新しい時代を創造することは間違いありません。

可能性のある方向性は非専門化であると言えます。適切なツールが揃うようになった場合、おそらく単純な作業を情報作業者に委ねることができます。継続的デリバリー技術と方法論が登場した一方でQ/A やリリースエンジニアに起こったことのように、より複雑なワークロードは共通のソフトウェアエンジニアリング作業の範囲となるでしょう。

いずれにしても、適切なツールと方法論によりその役割の方向性は定義され、この記事で述べられている懸念につながる根本原因の大部分は解決可能であると、私は期待しています。

私は今後「次世代のデータ対応型ETL」というタイトルのブログ記事を計画しています。ここでは、アクセシビリティと保守性が非常に重要となる新しいフレームワークの設計を提案します。このまだ構築されていないフレームワークには厳しい制約がありますが、代わりにベストプラクティスを強制することで強力な保証を提供します。乞うご期待!

(翻訳) データエンジニアの始まり

訳者まえがき

原著者 Maxime Beauchemin の許可を得て以下の記事を翻訳・公開しました。

medium.freecodecamp.org

原著者は、Apache Airflow や Apache Superset のクリエーターで、現在は Lyft で Data Engineer をしています。

データエンジニアの始まり(翻訳)

私は 2011 年にBIエンジニアとしてFacebookに入社しました。2013年に退職するときには、私はデータエンジニアでした。

昇進もしくは新しい役割に就いたわけではありません。そうではなく、Facebookは、私たちが行っていた仕事が伝統的なBIを超えていたことに気づいたのです。私たち自身のために作り出した役割は、まったく新しい専門分野でした。

私のチームはこの変革の最前線にいました。私たちは新しいスキル、新しいやりかた、新しいツール開発し、そして-- たいていの場合は--これまでの手法に背を向けていました。

私たちはパイオニアであり、データエンジニアだったのです!

データエンジニアリング?

学問分野としてのデータサイエンスは自己肯定や境界を定義する青年期を経ていました。同時期に、データエンジニアリングはやや若い兄弟でしたが、同様のものを経ていました。データエンジニアリングの学問はその兄弟に習う一方で、それ自身を対称的に位置づけ、アイデンティティーを見出していました。

データサイエンティストと同じく、データエンジニアはコードを書きます。彼らは高度に分析的で、データの可視化に関心があります。

データサイエンティストと異なり--ソフトウェアエンジニアリングという円熟した両親からの触発を受け--データエンジニアはツールやインフラストラクチャチーム、フレームワークやサービスを開発します。データエンジニアリングはデータサイエンティストよりもソフトウェアエンジニアに近いとも言えるでしょう。

過去から存在してるロールに関して言うと、データエンジニアリング分野は、ソフトウェアエンジニアリングから多くを受け継いだBIデータウェアハウスの上位集合と考えられるかもしれません。この学問は、拡張されたHadoopエコシステム、ストリーム処理、および大規模計算に関する概念とともに、いわゆる「ビッグデータ」分散システムの運用周りの専門性を統合しています。

小さな企業--データインフラストラクチャチームが正式に存在しないような--では、データエンジニアリングの役割は、組織のデータインフラの設定と運用に関する作業もカバーする場合もあります。これには Hadoop/Hive/HBase、Spark などのプラットフォームの設定や運用のようなタスクも含まれます。

小規模な環境では、人々はAmazonやDatabricksなどが提供するホスティングサービスを使用する、もしくはClouderaやHortonworksなどの企業からのサポートを受ける傾向にあります--基本的にはデータエンジニアリングの役割を他の企業に委託します。

大規模な環境では、データインフラストラクチャチームの必要性が高まるにつれて、このワークロードを管理するための専門化と正式な役割の作成が行われる傾向があります。これらの組織では、データエンジニアリングのプロセスの一部を自動化する役割は、データエンジニアリングチームとデータインフラストラクチャチームどちらともに委ねられており、これらのチームはより高いレベルの問題を解決するために協力することが一般的です。

その役割におけるエンジニアリングの側面は領域を拡大していますが、元のビジネスエンジニアリングの役割における他の側面は二次的になものとなっています。レポートやダッシュボードについてのポートフォリオの制作やメンテナンスなどの領域は、データエンジニアの主要な焦点ではありません。

現在私たちは、アナリストやデータサイエンティスト、一般的な「情報労働者」がデータに親しみ自律的にデータ消費を処理することの可能な優れたセルフサービスツールを持っています。

ETLの変革

私たちは、ドラッグ・アンド・ドロップ ETL(Extract Transform and Load)ツールから、よりプログラミング可能な方式への移り変わりも見てきました。Informatica, IBM Datastage, Cognos, AbInitio もしくは Microsoft SSIS などプラットフォームの製品知識は、現代のデータエンジニアの間では共有されておらず、Airflow, Oozie, Azkabhan, Luigi のような、プログラミング可能もしくは設定駆動なプラットフォームの理解とともに、より一般的なソフトウェアエンジニアリング技術により置き換えられています。

何故ドラッグ・アンド・ドロップツールを使用して複雑なソフトウェアのピースが開発されない理由は多数あります。それは、最終的にはコードがソフトウェアのための最良の抽象であるということです。このトピックで議論することは本記事の範囲を超えますが、その他のソフトウェアに当てはまるように、同様の理由が ETL を書くことにも当てはまると推測するのは簡単です。コードは、任意のレベルの抽象化を可能にし、慣れた方法で全ての論理操作ができ、ソース管理と上手く統合し、バージョン管理や共同作業も容易に行えます。ETLツールがグラフィカルインターフェースを触れさせるように進化したという事実は、データ処理の歴史における回り道のようなものであり、確かにそれ独自で興味深いブログ記事になるでしょう。

従来のETLツールによって公開された抽象化が的外れであるという事実を強調しましょう。もちろん、データ処理や演算処理、記憶装置の複雑さを抽象化する必要があります。しかし、解決策は ETL の基礎(ソース/ターゲット、集約、フィルタリングなど)をドラッグ・アンド・ドロップ方式で公開することではないと私は主張します。

例えば、現代のデータ環境で必要とされる抽象化の例として、A/B テストフレームワークにおける検証の構造があります。全ての試行は?関連している手法は何?どんな割合のユーザに公開する?各検証で影響がある期待される指標は何?いつその検証は効果を発揮しする?この例では、私たちは正確で高水準のインプットを受け取り、複雑な統計学的計算を実行し、計算結果をもたらすフレームワークを用います。私たちは新規の検証のためのエントリを追加することで余分な計算と結果を得られることを期待します。この例で注意する重要なことは、この抽象化のインプットパラメータは従来の ETL ツールにより提供されるものではなく、ドラッグ・アンド・ドロップインターフェースでそのような抽象化を行うのは、扱いやすくはありません。

現代のデータエンジニアにとっては、ロジックがコードにより表現出来ないため、従来の ETL ツールは大抵の場合使われません。結果として、必要な抽象化はそれらのツールで直感的に表現することは出来ません。現在、データエンジニアの役割は主に ETL を定義することからなり、完全に新しいツールセットや手法が必要とされていることは現在認識されており、それこそがその学問を根本から再構築させると言えるでしょう。新しいスタック、新しいツール、新しい制約、そして多くの場合、新しい個人の世代です。

データモデリングの変革

スタースキーマのような典型的なデータモデリングの技術は、一般的にデータウェアハウスに紐づく分析作業データモデリングに対する私たちのアプローチを定義しますが、かつてほど関連してはいません。データウェアハウスを構築するための従来のベストプラクティスは、スタックの移り変わりにより立場がなくなっています。ストレージや計算はこれまでより安価で、そして線形にスケールアウトする分散データベースの出現もあり、不足しているリソースはエンジニアリングの時間となっています。

以下は、データモデリング技術において見られる変化の一例です。

  • さらなる非正規化: ディメンションにおけるサロゲートキーのメンテナンスは扱いにくい可能性があり、ファクトテーブルをより読みにくくします。ファクトテーブルにおける人が判別可能なナチュラルキーやディメンションの属性の使用はより一般的になってきており、分散データベースで重く高コストなジョインの必要性を減らします。また、ParquetやORCのようなシリアライゼーションフォーマットやVerticaのようなデータベースエンジンでのエンコーディングと圧縮のサポートは、通常は非正規化に関連するパフォーマンスの損失のほとんどを埋め合わせます。これらのシステムは、独自にストレージ用のデータを正規化するようになっています。

  • ブロブ: 現代のデータベースはネイティブ型や関数を通じてブロブをサポートするものが多くなっています。これによりデータモデラーのプレイブックに新しい動きが生まれ、必要に応じてファクトテーブルに複数の性質のものを一度に保存できるようになります。

  • 動的スキーマ: MapRecue の誕生以来、ドキュメントストアの普及とデータベースにおけるブロブのサポートにより、DML(訳注: DDL?)を実行することなくデータベーススキーマを発展させることが容易になりました。これにより、ウェアハウスの構築に対して反復的なアプローチを取ることが容易になり、開発が始まる前に完全なコンセンサスや買い入れを行う必要性がなくなります。

  • 徐々に変化するディメンション(slowly changing dimension: SCD)を処理する一般的な方法として、計画的にディメンションのスナップショットを作成する(各ETLのスケジュールサイクルごとのディメンションの完全コピーは、通常は別個のテーブルパーティションに格納する)ことは、エンジニアリングの労力をほとんど必要としない単純で一般的なアプローチです。この方法は古典的アプローチと異なり、同等のETLやクエリーを書くときに容易に理解ができます。また、ディメンションの属性をファクトテーブルにて非正規化し、トランザクション発生の際にその値を追跡することは、簡単で比較的安価です。逆に、複雑なSCDモデリング手法は直感的ではなく、アクセシビリティを低下させます。

  • 対応付けられたディメンションとメトリックのような対応付けは現代のデータ環境では依然として非常に重要です。しかしながら、データウェアハウスの迅速な移行が必要であり、多くのチームや役割がこの作業に寄与するように求められるような状況では、緊急性は高くなく、それらはトレードオフとなります。分岐によるペインポイントが手に負えなくなった箇所では、合意と収斂がバックグラウンドプロセスとして生じる場合があります。

  • また、より一般的には、コンピューティングサイクルのコモディティ化と、以前と比べデータに精通している人が増えているため、結果を事前に計算してウェアハウスに保存する必要性は低いと言えるでしょう。たとえば、オンデマンドでのみ実行する複雑な分析を実行できる複雑なSparkジョブを作成し、ウェアハウスの一部としてスケジュールせずにおくことが可能です。

役割と責任

データウェアハウス

データウェアハウスは、クエリと分析用に特別に構成された、トランザクションデータのコピーです。 - ラルフ・キンボール  

データウェアハウスは、経営陣の意思決定プロセスを支援する、主題指向の、統合された、時系列で不揮発性のデータの集合です。 - ビル・インモン

データウェアハウスはそれまでそうだったようにただの関連性であり、データエンジニアはその構築と運用の多くの面を担当しています。データエンジニアの焦点はデータウェアハウスであり、その周りに重力を与えます。

歴史的に見たよりも現代のデータウェアハウスは公共機関のようであり、データサイエンティスト、アナリスト、ソフトウェアエンジニアがその構築と運用に参加することを歓迎しています。どのロールがそのフローを管理するかの制限を掛けるには、データは実際に会社の活動の中心に位置し過ぎているのです。これにより組織のデータニーズに合わせたスケーリングが可能になりますが、それはしばしば混沌とした安定しない不完全なインフラストラクチャをもたらします。

データエンジニアリングチームには、多くの場合、データウェアハウスにおいて高品質で公認の領域があります。たとえば、Airbnbでは、データ・エンジニアリング・チームによって管理される一連の「コア」スキーマがあります。それについて、サービス水準合意(SLA)は明確に定義・測定され、命名規則は厳格に適用されます。事業に関するメタデータドキュメンテーションは最高品質で、関連するパイプラインコードは、よく定義されたベストプラクティスのセットに従います。

また、データエンジニアリングチームの役割は、データオブジェクトの標準やベストプラクティスおよび認証プロセスを定義することを通じて、「卓越性の中心」となることです。チームは、他のチームがデータウェアハウスのより良い市民になるのを助けるために、コアコンピテンシーを共有する教育プログラムを共にするか導くように展開できます。たとえば、Facebookには「データキャンプ」教育プログラムがあり、Airbnbはデータエンジニアがセッションをリードし、データに習熟する方法を教えるよう同様な「データ大学」プログラムを開発しています。

データエンジニアは、データウェアハウスの「図書館員」でもあり、メタデータの登録と編成を行い、ウェアハウスからファイルを抽出またはファイルごとに行う処理を定義します。急速に成長・発展しているやや混沌としたデータエコシステムにおいて、メタデータ管理とツールは現代のデータプラットフォームの重要なコンポーネントになります。

パフォーマンスのチューニングと最適化

データがこれまで以上に戦略上重要なものになるにつれて、企業はデータインフラストラクチャにとって驚異的な予算を増やしています。これにより、データエンジニアがパフォーマンスのチューニングとデータ処理とストレージの最適化を繰り返していくことがますます合理的になります。この領域で予算が縮小することはめったにないため、リソース使用量とコストの指数関数的な増加を線形化しようとする、もしくは同じ量のリソースでより多くを達成するという視点から最適化が行われることがよくあります。

データエンジニアリングスタックの複雑さが拡大していることを知ることで、そのようなスタックやプロセスの最適化における複雑さがやりがいのある課題であるがわかります。少しの労力で大きな得を得られることが簡単な場合は、通常は収穫逓減の法則が適用されます。 データエンジニアは、会社と共に規模を拡大しリソースを常に意識したインフラストラクチャを構築することは間違いありません。

データ統合

データのやりとりを通じたビジネスとシステムの統合の背後にある実践であるデータ統合は重要であり、これまで同様に課題となります。 SaaS(Software as a Service)が企業の新しい標準的な運用の方法となるにつれて、システム間で参照データを同期させる必要性がますます高まっています。 SaaSは機能するために最新のデータを必要とするだけでなく、SaaSサイドで生成されたデータをデータウェアハウスに持ち込んで、残りのデータと共に分析できるようにしたいことがあります。確かにSaaSには独自の分析機能が提供されていますが、残りのデータが提供する視点が系統的に欠けてしまうため、この一部データを引き戻す必要がある場合もあります。

これらのSaaS製品が、共通のプライマリキーを統合や共有することなく参照データを再定義することは、犠牲を払って回避すべき災害です。誰も2つの異なるシステムで2つの従業員リストまたは顧客リストを手動で維持することは望んでおらず、最悪な場合にはHRデータをウェアハウスに戻す際にファジー・マッチングを行う必要があります。

企業の経営幹部はデータ統合の課題を本当に考慮せずに、SaaSプロバイダーと契約を交わすことがあり、それは最悪の状況です。統合作業はベンダーによって販売を促進するために計画的に軽視され、データエンジニアは帳簿外の感謝されるべき仕事の下に張り付いたままになります。言うまでもなく典型的なSaaS APIはしばしば設計が不十分であり、明確に文書化されておらず、「アジャイル」(断りもなく変更されるという意味)です。

サービス

データエンジニアは抽象度の高いレベルでの運用をしており、場合によっては、データエンジニア、データサイエンティスト、アナリストが手動で行う種類の作業を自動化するためのサービスとツールを提供することを意味します。

データエンジニアとデータインフラストラクチャエンジニアが構築・運用するサービスの例をいくつか示します。

  • データの登録:データベースの「スクレイピング」、ログのロード、外部ストアやAPIからのデータを取得するようなサービスとツール

  • メトリック計算:エンゲージメント、成長率またはセグメンテーション関連のメトリックを計算して要約するためのフレームワーク

  • 異常検出:データの消費を自動化して、異常なイベントが発生したときもしくは傾向が大きく変化したときに警告する

  • メタデータ管理:メタデータの生成と消費を可能にするツールにより、データウェアハウス内およびその周辺の情報を見つけやすくする

  • 実験:A / Bテストおよび実験フレームワークは、しばしば会社の分析の重要な部分であり、重要なデータエンジニアリングコンポーネントである

  • 計測:分析は、イベントとそのイベントに関連する属性を記録することから始まる。データエンジニアは高品質のデータが上流に取り込まれることを確実にすることに関心をおく

  • セッション化:ある時間の中での一連のアクションを理解するのに特化したパイプラインで、アナリストがユーザーの行動を理解できるにする

ソフトウェアエンジニアのように、データエンジニアは作業負荷を自動化し、複雑なはしごを登れるように抽象化を構築するよう常に気をつけなければなりません。自動化できるワークフローの性質は環​​境によって異なりますが、自動化の必要性は全面的に共通しています。

必要なスキル

SQLの熟達:英語がビジネスの言語だとしたら、SQLはデータの言語です。あなたが良い英語を話せないとしたら、ビジネスマンとして成功できるでしょうか?同世代の技術が時代遅れになる一方で、SQLはデータに関わる共通言語として未だに強力です。データエンジニアは、「相関サブクエリ」やウィンドウ関数などの手法を使用して、どんなレベルのSQLの複雑さでも表現することができます。 SQL / DML / DDLプリミティブは、データエンジニアにとって不思議なことがないほど単純です。 SQLの宣言的な性質以外にも、データベースの実行計画を読んで理解し、すべてのステップが何であるか、インデックスがどのように機能するか、さまざまなジョイン・アルゴリズム、および計画内の分散したディメンションを理解する必要があります。

データモデリング手法:データエンジニアにとって、実体関連モデルは正規化を明確に理解した上での認知的な思考様式でなければならず、非正規化とのトレードオフに対する鋭い直感をもつ必要があります。データエンジニアは、ディメンション・モデリングとそれに関連した概念やレキシカルフィールドに精通している必要があります。

ETL設計:効率的で弾力性のある「進化できる」ETLを書くことが鍵となります。私は今後のブログ記事でこのトピックを展開する予定です。

アーキテクチャーの推定:特定の専門分野の専門家と同様に、データエンジニアは、ツール、プラットフォーム、ライブラリおよびその他のリソースの大半を高いレベルで理解する必要があります。データベース、計算エンジン、ストリームプロセッサ、メッセージキュー、ワークフローオーケストラ、シリアライズフォーマット、およびその他の関連技術の異なる特色の背後にある特性やユースケースおよび細かな差異など。ソリューションを設計する際には、どのテクノロジーを使用するか良い選択ができなければならず、またどのようにそれらを連携させるかについてのビジョンを持てなければなりません。

何よりも大事なこと

過去5年間、シリコンバレーAirbnbFacebookYahoo! で働いていて GoogleNetflixAmazonUberLyft、あらゆる規模の企業数十社のデータチームと深く関わり、「データエンジニアリング」が何を進化させているかコンセンサスが増していることを観察することで、私の知見の一部を分かち合う必要があると感じました。

この記事がデータエンジニアリングのための何らかの声明の役目を果たすことができることを願っています。そして、関連分野で活動しているコミュニティからの反応を喚起することを願います!

分散システムについての学習

基本

まずはkumagi-sanのスライドを読む

www.slideshare.net

合意アルゴリズムとアプリケーション

2PC (Two Phase Commit), 3PC (Three Phase Commit)

Paxos

ZAB (ZooKeeper Atomic Broadcast)

  • Zookeeper (Google Chubbyのクローン?)
  • HBaseはZookeeperを使っている

Raft

めちゃくちゃこのページがよく出来ている。アニメーションやら解説スライドなど理解への導入が素晴らしい。 https://raft.github.io/

その他

FLP impossibility

Fail-Stop(非同期通信)より厳しい故障モデルでは「全ての壊れていないサー バが有限の時間で確実に合意に至るアルゴリズムは存在しえない」という 事を理論的に証明した論文があり、著者の頭文字を取ってその不可能性が命名されたもの

ちなみに上記は以下のブログ記事に対するコメント

Bitcoinは合意アルゴリズムではない – The Third of May

その他、

CAP定理

Takeru Ohtaさんによる証明論文の抄訳がとても分かりやすい

『Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services』の要約 · GitHub

ConsensusとQuorumの違い

  • Achieving consensus means that all the participants in the discussion agree (on a proposal/result/plan etc).
  • Achieving quorum means that a majority of the participants in the discussion agree.
  • Therefore - if there are N participants, if all N of them agree, a consensus is achieved. If (N/2 + 1) or more participants agree, a quorum is achieved.

What is the difference between a consensus and a quorum? - Quora

中田 敦『GE 巨人の復活 シリコンバレー式「デジタル製造業」への挑戦 』を読んだ

TLで複数の人がおすすめしていたので読了した。

著者は日経BPシリコンバレー支局の中田 敦氏

個人の感想

全体的な書評はhido-sanの記事が参考になる。

sla.hatenablog.com

重工産業は規模が大きいので 1 % の削減が大きなコスト圧縮になる。

燃料管理にFESを利用すれば、年間の燃料コストを最大で2%下げることができるはず。つまり、2014年に52.7億ドルの燃料を購入していたサウスウェスト航空ならば、毎年1億500万ドルの燃料経費削減の可能性があるということを示唆しています。

ビッグデータを活用した航空燃料コストの削減 | GE Reports Japan

GEは、自社の事業に適用してきた生産プロセスのデジタル化による効率化のノウハウを、PaaSとして提供することを推し進めているようだ。 しかしながら、デジタル製造業への展開の旗振り(その辣腕振りは書籍を参照)を行ったCEOイメルトは 2017/6 に退任しており、市場からは評価されていなかったようにも感じる。

イメルト氏退任、もはや「主流」でない米GEの現実 :日本経済新聞

イメルト氏の改革は成功事例として後世に残って貰いたいものである。

マイケル・ルイス「かくて行動経済学は生まれり」を読んだ

マイケル・ルイス氏のファンならば、と訳書が出たと聞いて読了した。

かくて行動経済学は生まれり

かくて行動経済学は生まれり

ダニエル・カーネマンとエイモス・トベルスキーの半生(人生)を描き、彼らが発展させた行動経済学について書かれていた。 マイケル・ルイス氏の著作はどれも対象のテーマ以上に関係者の人間ドラマが良く書かれていて読んでいて退屈しない。

ダニエル・カーネマン - Wikipedia

エイモス・トベルスキー - Wikipedia

ダニエル・カーネマンはファスト&スローで知っていたが、その著作は上巻で投げてしまっていた。読み始めた当時はその心理学的なアプローチが読んでいてもやもやしていて、コーナーケースを突く様な質問の結果、認知バイアスがあったとしても日常に何の影響があるんだみたいな気持ちだった気がする。けれども、この新作を読んで、彼らが明らかにしたかったことが何となくわかったような気がした。

彼らは人の判断や予測、意思決定に関わる原理について研究をしていた。人間が合理的な判断をいつも出来る気はしないが、それがどのような理由で合理から離れてしまっているかを紐解こうとしていた。本の中ではその調査に使ったアンケート用の質問も豊富に登場し、自身でその回答を行った理由を考えてみるのも面白い。確かに、自分は無意識に何らかの原則に基いて判断をしている。自分が陥りやすい認知バイアスの知識は今後の判断で役に立つこともありそうである(しかし、これも彼らが言う代表性の認知バイアスとして働きそうではある)。

彼らはイスラエルで交流を深め研究を行っていた。彼ら心理学者は戦時中の軍隊で重宝されており、彼らのような大学の教授が戦場に赴いていた事実は驚いた。人間の判断についての疑問は、人の命や国の命運に関わるような境遇から生まれた実際的なテーマであった。

ヒューリスティックス | 認知心理学

これらの研究は1970年代とか大分古い話のようなので、現代にはさらに面白い研究結果が出ていそうである。