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

訳者まえがき

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

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年代とか大分古い話のようなので、現代にはさらに面白い研究結果が出ていそうである。

3級FP技能検定を受験した話

もういい大人なので社会制度やマニーの知識を付けようと思ったため、試験を受けた。

3級 試験範囲 | 日本FP協会

合格のボーダーラインが6割のところ、自己採点の結果は以下だったので、合格したでしょう。

学科: 44/60

実技: 19/20

書店で物色して下記の参考書と問題集を購入したのは Amazon によると 2016/11/24.

はじめてまなぶFP技能士3級テキスト〈’16‐’17受検対策〉

はじめてまなぶFP技能士3級テキスト〈’16‐’17受検対策〉

はじめてまなぶFP技能士3級問題集〈’16‐’17受検対策〉

はじめてまなぶFP技能士3級問題集〈’16‐’17受検対策〉

試験日が 2017/01/22 だったので大体二ヶ月くらい。平均してそのうち半分の日数で1-2時間程度勉強したとすると総勉強時間は30-50時間程度か。 参考書を一周、問題集を二周と後は適当にザッピングした。このような試験にありがちだが、過去問と類似の問題が多いので、過去問を一通り抑えて理解すれば合格出来る(ただし問題は二択とかなのでややニッチな問題も差し込まれている印象を受けた)。2級は、3級の内容をやや強化した問題でその選択肢数が増えるだけらしいので、同様の方法で合格できそう。

3級の合格率は70%くらいある。

【FP3級は楽勝!】たった2千円の投資で一日2時間・2週間の独学で楽々と200%合格できる勉強法 - ひかる人財プロジェクト

2級になると選択問題も四択になり、合格率は35%とかになる。

FP・ファイナンシャルプランナーの合格率・難易度は? | FP・ファイナンシャルプランナーの通信教育・通信講座ならフォーサイト

自己啓発に終始した試みだったが、まあ税制などは知っておくに越したことはないだろう。 この世で避けて通れないものは死と税金である。

2016年振り返りと2017年目標

2016年の振り返り

2016年の目標ははこんな感じだった。2015年振り返りと2016年目標 - satoshihirose

英語を使いこなせるようになる

  • 英語力向上については手探りで徐々に前へ進んでいるフェーズである。近所の英会話にトライしてみた結果、それはナチュラルな英会話の場だったのだが前職の帰宅時間と合わずに辞めてしまった(今なら継続できるかもしれない)。現職ではしっかりした英会話クラスが外注してあってそれを半期ごと福利厚生として社内で受けられるようになっている。その中でビジネス英会話のクラスを選択して週一で受講していた。受講して、あっ、あっ、自分は英語が出来ないとなっている。対人間の汎用コミュニケーションそのものが苦手なので流暢な英会話が望めるべくもなく、ただただ冷や汗を流しながら耐え忍んで受講し続けるだけなのだが、やっていくしかない。クラス受講当初よりは良くなっている気はする(何が)。三年間くらい今の環境で続けていけばある程度のものになるような気はする(長い)。現職で受講補助も出るTOEICもタイミングが合わず受けられ終いだったので来年は受けよう。無駄に高いTOEFLは海外の大学とか受けるなら必要なのだろうけれど今のところ予定は無いので未定。

OSSへのcommit

  • 成果なし。最近はめっきりコードも書いていない。エンジニアとしてコードを書ける人材ではあり続けたいなとは思うので引き続き課題として残しておく。何か良い対象を見つけられれば良いのだが。

identity reconstruction

  • 直近の趣味としては経済・金融の学習に落ち着いた。勉強しがいがある。
  • 株の取引手法も模索中で、現状は国内株式でスウィングトレードやアノマリー投資法みたいなのを手堅く試している。アービトラージもどれだけ可能か検証したい。
  • 本格的に取引し始めたこの半年の成績を確認したところ、売買益は税抜き13万円だった。来年は一桁上げたい。トランプ相場には乗れていない。

年収

  • 生活のために十分に満足のいく収入を現職で得られたので、本当に余裕が生まれた。余裕のある収入は精神や時間の余裕を生む。日々のしょうもない出費に対する決断に時間を取られることもなくなるし、生活の選択に幅も出ることで視野も広がる。余裕は善だ。日々ボール・ヴァレリーの「アイデアいっぱいの人は深刻化しない」を唱えよ。三年後にはここから年収を倍にする方法を検討すべし。
  • 一方で制限が力という側面もあるので、安穏としてもいられないという気持ち。

人生の進捗を出す

  • 2016年の可処分時間の大部分を費やしけじめを付けた結果、2017年度から同棲をして籍を入れる予定となった。めでたい。しかしながら、2016年末現在、依然として予断は許さない状況である。

その他

  • ジム通いにチャレンジしましたが生活のリズムと合わず2ヶ月で辞めました。筋力と体力があったほうが人生豊かになるという確信は引き続きあるので別な形でその内またチャレンジしたいと思います。

2017年の目標

何かこうやって書き下してみると英語・金融・ITみたいな感じで大前研一フォロワーっぽいですね。つまんない人間だな、おい。

英語をやっていく

  • 数値目標はTOEIC900かな特に意味は無いけど。社内英語クラス以外で何かしらアクティビティを発生させる。

コード書く

  • OSSとは言わずとも、何らか社内ツールにでもコミット出来れば良いな。

資格

  • フィナンシャルプランナーの資格を取る。1月に3級、5月に2級。
  • 詳細は調べていないけれど AWSビッグデータ系の上級資格が出来たらしいので適当なタイミングで受ける。(FPの3級が終わった後か)

金融・株

  • 今後の人生で何にどうお金を使うかフィナンシャルをプランする(計画は変わるものである)

旅行

  • 暫く海外旅行行っていないので行きたいな。米国。サンフランシスコかニューヨークかシアトルとかその辺。オーロラも見たい。
  • 30歳頃に南極旅行をすると言っていた準備をする。

大学

  • 30歳になったら大学でも戻るかって言の可能性がどれほどのものか検証する。

安定した家庭を築く

  • 安定した家庭とは。幸福とは。人生とは。