エンジニアはETLを書くべきか？ - 効率的なアルゴリズム/データサイエンス部門の構築方法を教えます

[[174647]]

序文

多くのインターネット企業のアルゴリズム関連部門（検索、レコメンデーション、広告など）には、「アルゴリズムワーカー」と「エンジニアリングワーカー」の2種類の職種があります。この一見自然な分業方法は正しい方法なのでしょうか? これについては議論があるようです。

この記事は、協力モデルで現在よく見られる問題について説明しており、翻訳者はそれが要点を非常によく突いていると感じています。さらに重要なことに、著者はこれらの問題を解決できる可能性のある、より優れたコラボレーション モデルも提案しています。

事前に説明しておく必要があるのは、この記事で言う「データ サイエンティスト」とは、よくアルゴリズム指向のエンジニアと呼ばれるものと理解でき、この記事で言う「エンジニア」または「データ エンジニア」とは、よくエンジニアリング指向またはアーキテクチャ指向のエンジニアと呼ばれるものと理解できるということです。

本文開始

「あなたのチームとデータサイエンティストとの関係はどのようなものですか[1]？」これは間違いなく、データプラットフォームエンジニアに面接するときに最もよく聞かれる質問です[2]。これは面接プロセス中の通常の質問であり、求職者が新しい機会を評価するプロセスの一部です。そして私はいつもこの質問に喜んでお答えします。しかし、この質問の背後には疑念と恐怖があるため、答える必要がないことを願っています。

なぜでしょうか? シリコンバレーのテクノロジー企業のデータサイエンス部門やアルゴリズム開発部門の求人広告を読むと、データ サイエンティストとエンジニアの関係は、非常に協力的で、有機的かつ創造的であると思われるかもしれません。

しかし、業界の現実はそうではありません。ほとんどの場合、両者の関係は存在しない状態[3]から非常に機能不全の状態までの範囲にあります。

典型的なデータサイエンス部門

ほとんどの企業では、データ サイエンス部門を次の 3 つのグループに分けています。

データ サイエンティスト: 統計学者よりもエンジニアリングが得意で、エンジニアよりも統計が得意な人たちです。それが「考える人」と呼ばれるものです。

データ エンジニア: データ パイプラインを構築し、データ サイエンティストにデータを供給し、データ サイエンティストのアイデアを取り入れて実装します。それがいわゆる「実行者」（Doer）です。

インフラストラクチャ エンジニア: Hadoop クラスターやその他のビッグ データ プラットフォーム アーキテクチャを管理します。 「配管工」とも呼ばれる[4]。

データ サイエンティストは、エンジニアによるアルゴリズムの実装のペースが遅いことや、ワークフロー、ロードマップ、動機が同期されていないことにイライラすることがよくあります。彼らのアイデアのバージョン 1 が ABTest に入った時点で、バージョン 2 と 3 がすでに準備されていました。彼らの失望と不幸は、とても理解できるものです。

データ エンジニアがしばしば不満に思うのは、データ サイエンティストが提供するコードが常に非効率で見苦しく、保守性やエンジニアリングの問題をほとんど考慮していないことです。また、データ エンジニアは非現実的な機能要件を提示するため、エンジニアリング実装計画が台無しになるだけでなく、メリットも得られません。このような質問は他にもたくさんありますが、問題がどこにあるのかはすでにご理解いただけたと思います。

アーキテクチャ エンジニアは、クラスターが常にタスクでいっぱいになり、ハード ドライブがデータでいっぱいになるため、これに不満を抱いています。また、彼らはデータ サイエンティストやエンジニアから遠く離れていることが多く、クラスターがどのようなシナリオでどのように使用されているか、またはクラスターがどのようなビジネス上または技術的な問題を解決するために使用されているかを知ることができません。これにより、彼らは現在の不幸な状況から抜け出すことが難しくなります。そのため、彼らの対応はクラスターにさらに厳しい制限を課すことであり、その結果、他の全員が彼らに腹を立て始めます。

これは明らかに悪循環です。

何が悪かったのでしょうか?

これが間違っていることは誰もが知っているのに、なぜ修正しないのでしょうか? なぜすべてのデータ サイエンス部門とアルゴリズム開発部門が、この機能不全のモデルに陥っているように見えるのでしょうか?

私はこの問題の原因を 2 つに絞って考えており、ここでいくつかの観察結果を示しながら説明します。

「ビッグデータ」を持っていないかもしれない

データを処理するためのツールと技術は、過去 5 年間で劇的に進歩しました。数ペタバイトのデータを処理していなければ、または 1 日に数千億のイベントを処理する必要がない限り、ほとんどのテクノロジーは必要な規模に簡単に拡張できます。

これらのテクノロジーの限界をテストする必要がない限り、それらの上にソリューションを構築するために、高度に専門化されたプロのエンジニアのチームはおそらく必要ありません。こういう人を雇ったら、彼らは退屈してしまうでしょう。彼らが退屈したら、あなたを離れて、Google や Facebook など、彼らの専門知識がより役立つ他の場所へ移ります。退屈していないのであれば、彼らのスキルはおそらく非常に平凡なものである。平凡なエンジニアが最も得意とするのは、巨大で、過度に複雑で、使い物にならないゴミを作り、それを「ソリューション」と呼ぶことです。一方、ゴミの場合は、より多くのメンテナンス作業が必要になることがよくあります。

誰もが「考える人」になりたい

なぜなら、その方がかっこいいからです。一日中そこに座って、物事をより良く行う方法について考え、そのアイデアを、それを実現したいと熱望するエンジニアに押し付けることができます。誰もがこの職に就きたいはずです。データ サイエンティスト、特にこの仕事に就いたばかりで業界についてあまり知らない人は、このような職に就くのが特に楽しみでしょう。

これらは私たちのガイダンスの結果ですが、特にビッグデータ流行以前からデータ インテリジェンス部門をすでに持っていた一部の大企業は、これにさらに大きな責任を負っています。

従来のデータ インテリジェンス部門には、ETL エンジニア、レポート開発者、DBA の 3 つの役割が含まれます。 ETL エンジニアはデータをデータ ウェアハウスに転送します。レポート エンジニアの主な仕事は、特定のツール (MicroStrategy など) でレポートを設計することであり、レポート エンジニアはその分野の専門家です。すべてをスムーズに実行するのは DBA (およびその他のツール管理チーム) の仕事です。 36 ビッグデータ (http://www.36dsj.com/)

ここで問題となるのは、ETL エンジニア、レポート エンジニア、DBA がすべて実行者であるということです。そのため、10 年前に「ビッグ データ」や「データ サイエンティスト」という用語が初めて登場したとき、これらの従来の BI 部門は実行者が多すぎることと思考者が不足しているという問題に直面しました。そこで彼らは「考える人」という役職を創設したのです。私たちはデータ サイエンティストに、データに取り組んで世界を変えることができると約束しました。しかし、そうではありません。これらのデータ サイエンティストは、クールで便利なソリューションを作成することがありますが、ほとんどの場合、レポート エンジニアよりも優れた成果を上げることはできません。

しかし、このポジションは魅力的に思えますし、採用するのも比較的簡単です。こうして、データ サイエンティスト (以前はレポート エンジニア、現在は「考える人」)、データ エンジニア (以前は ETL エンジニア、現在は「実行者」)、アーキテクチャ エンジニア (以前は DBA、現在は「配管工」) からなる、現代の伝統的なデータ サイエンス部門が誕生しました。

ハハ、データ インテリジェンス (BI) 部門はまったく変更されていないようです。Hadoop クラスターを追加して、名前を変更しただけです。 36 ビッグデータ (http://www.36dsj.com/)

本当にそんなに悪いんですか？

この質問は私たちの目的が何であるかによって異なります。上記の見解に同意するのであれば、BI の登場以来、多くの企業が長年にわたってこのモデルを使用してきたことを認めなければなりません。しかし、データ サイエンス チームに PowerPoint プレゼンテーション以上のものを作成させたい場合、これは非常に非効率的なモデルだと思います。

上記の「考える人」+「実行する人」モデルが成功するための基本的な前提は、自分自身の魂を持たず、「考える人」のアイデアを積極的に実行するだけの優れたエンジニアのグループが必要であるということです。しかし、そのようなエンジニアは優秀なエンジニアとなるでしょうか?

このモデルでは、実行者は他の人のアイデアの実装と失敗に対して責任を負い、一方で思考者は成功に対して報酬を得ます。これがチーム内の議論や不和の核心です。

データ エンジニアリングの職に優秀な人材を採用したい場合、彼らの仕事が他人のアイデアを無慈悲に実装するだけにならないように、彼らが解決すべき、より大きく、より驚くべき問題が必要です。必要なのはビッグデータによって実現される大規模な問題ですが、問題はビッグデータがないことです。

つまり、平凡なエンジニアしか雇えないのです。彼らは大きな混乱を引き起こし、問題をさらに悪化させ、あなたを下降スパイラルに陥れるでしょう。最終的には、革新的で堅牢なデータ プラットフォームのサポートが不足しているため、データ サイエンティストは従来のレポート エンジニアと比べてそれほど優れているとは言えません。さらに、彼らをレポートエンジニアとして位置付けると、データ サイエンティストは逃げてしまいます。結局のところ、彼らは「考える人」であり、「実行する人」ではないのです。

異なる種類のデータサイエンス部門

この問題に関しては、大企業の慣行を盲目的に従うのではなく、このモデルを革新する方法を見つける必要があります。より速い馬を設計しようとするのはやめましょう[5]…

これがまさに私が数年前にStitch Fixに参加した理由です。 Stitch Fix では、アルゴリズムと分析において世界最高を目指しています。私たちのアプローチは、単に結果を知らせるのではなく、アウトプットを通じて業界をリードすることです[6]。したがって、目標を達成するためには、現在のモデルが間違っていることを心の底から信じ、より良い新しいモデルを作成することに専念する必要があります。

過去 2 年間、私たちの部門が成長し、発展するのを見てきましたので、自信を持って皆さんと共有できます。私たちの目的は、伝えることではなく、成果によって導くことなので、データ サイエンス部門を編成するためのより良い方法について、私が考えることを共有したいと思います。これは完全に「自律的な」役割であり、最初から最後まで責任と所有権を持ち、結果に対して説明責任を負います。これは、急速に成長し、反復している企業に適したアプローチです。

誰もが最高になれるように

伝統的な役割を忘れて、仕事の何が本当に楽しいのかを考えてみましょう。

役割に関係なく、平均的な人と優れた人との間の最大の違いの 1 つは、革新に対する欲求と能力です。優れた人材は、普通の人には解決できない問題を特定し、創造的に解決することができ、自律性、所有権、集中力のある環境に適しており、そのような環境を強く望んでいます。

データ サイエンティストからエンジニアへのパイプラインは、この環境とは正反対です (実際、データ サイエンティストは「実行者」にそれほど依存することを好みません)。したがって、重要なのは、全員に十分な自律性、所有権、集中力のある環境を作り出すことです。

しかし、データ サイエンティストとエンジニアが興奮するものはまったく異なることに注意することが重要です。

データサイエンティスト

データ サイエンティストは、ビジネスに密接に関連し、その取り組みを通じてプロジェクトや組織の成功または失敗に直接影響を与える可能性のある問題を好みます。何かまたはプロセスを最適化したり、ゼロから何かを作成したりします。これらは非常に的を絞った質問なので、その解決策は似たものになります。これらのソリューションには、さまざまなビジネス ロジック、運用プロセスに関する詳細な検討、そして多くの創造性が組み合わされています。したがって、ビジネス ロジックの特定の部分に対する深い理解と、ビジネス プロセスへの徹底した垂直的な参加が必要になります。

エンジニア

エンジニアは、問題を抽象化して一般化し、エレガントで効果的な解決策を見つけるのが得意です。データ サイエンティストが関心を持つ問題とは異なり、これらの問題は一般に横断的であり、つまり、広く適用可能な場合に最も役立ちます。これには、ビジネス運用プロセス全体に対する深い理解が必要です。これらのソリューションは非常に抽象的であるため、エンジニアはビジネスの特定の部分について非常に深い理解と関与を必要としません。

ハイブリッド思考者と実行者

データ エンジニアが最も恐れていることは、JD が非常に優れているにもかかわらず、実際に採用したいのは ELT エンジニアであるということです。

まだ気づいていないのなら言っておきます。データ パイプラインや ETL を単純に記述して保守することを好む人は誰もいません。これはこの業界で一番ホットな話題です。そうであれば、この職位が凡庸な人材の温床となっているのも不思議ではない。

エンジニアは ETL を書くべきではありません。これは専用のポジションではありません。決して使用しない ETL の束を記述、変更、保守、サポートすることほどイライラすることはありません。

代わりに、従業員に仕事の全体的なエンドツーエンドの所有権を与えます。データ サイエンティストにとって、これは ETL の所有権、分析および最終出力の所有権を意味します。データ サイエンティストの仕事の最高の成果は、人間指向ではなく、機械指向であるべきです。 *** の出力は PPT やレポートではなく、ビジネスを変更するために呼び出すことができるアルゴリズム API です。自律性とはコードの所有権も意味します。開発開始から生産開始まで。アプリケーションを独自に展開し、そのパフォーマンス、性能、およびその他のサポートに責任を持つ必要があります。

しかし、データ サイエンティストは一般的にソフトウェア開発の専門家ではなく、せいぜい資格がある程度です。そのため、エンジニアリングの面で大きな混乱が生じる可能性があります。そのため、データの ETL とアルゴリズムの開発は通常、専門のエンジニアに引き継がれます。これらのタスクは本質的に垂直方向に焦点を当てていますが、優秀なエンジニアはアプリケーションを水平方向に拡張するのが得意な場合が多いです[7]。

では、このシナリオにおけるエンジニアの責任は何でしょうか? 一般的に、エンジニアは、データ サイエンティストがアイデアを迅速に開発して独自に展開できるように、プラットフォーム、サービス、フレームワークを展開する必要があります。これらの取り組みは、レゴ ブロックの構築に例えられます。エンジニアがレゴ ブロックを設計し、データ サイエンティストがこれらのブロックを組み立てることで新しいアイデアを実現します。これを実行することの利点は明らかです。

エンジニアの仕事は完全に水平化されました。これにより、複数のアルゴリズム アプリケーションにまたがるテクノロジの設計と開発に集中できるようになります。そうすることで、エンジニアリング技術の成果を最大化することができます。

エンジニアは、抽象化、一般化、効率的でスケーラブルな技術ソリューションの構築という、最も得意とする分野に集中できます。

エンジニアは自律的に作業できます。このように活動するエンジニアリング チームは魔法のように機能します。データ サイエンティストが期待し、必要とするものはすべて事前に予測でき、スケーラビリティと堅牢性はすべて、エンジニアの仕事であるプラットフォーム、サービス、フレームワークに委ねられます。

このメカニズムが適切に機能するためには、ほとんどの場合、エンジニアがデータ サイエンティストのニーズを予測し、事前にいくつかの手順を開発する必要があります。

これは明らかに、才能あるエンジニアやデータ サイエンティストにとって非常に興味深いものです。

では、すべての作業はデータ サイエンティストによって行われるのでしょうか?

全くない。むしろ、このシステムでエンジニアが担う責任は、従来のアプローチよりも困難で、より必要とされており、データ サイエンティストについても同様です。私たちの仕組みは効率を最適化することではなく、自律性を重視することです。この一連のメカニズムの結果、明確な自律性と結果に対する明確な説明責任が生まれます。

これは起業家にとって非常に魅力的です。急速な発展と破壊的イノベーションへの扉を開きます。しかし、それはある程度の専門性、つまり一定の効率性を犠牲にすることになります。

私たちは、データ サイエンティストが突然優秀なエンジニアになることを期待しているわけではありませんし、エンジニアがビジネス ロジックをまったく理解せず、垂直方向に深く進む意欲を失うことも望んでいません。実際、このモデルを機能させる鍵はチームワークです。エンジニアは、自らを「アイアンマンの仕立て屋」と考えるべきです。その使命は、強力な鉄のスーツを作り、データ サイエンティストがスケーラブルでも信頼性も低いソリューションの罠に陥らないようにすることです。

非常に困難な道

これを見ると、本当にそのような仕組みが構築できるのか疑問に思うかもしれません。しかし、そうすることで得られるメリットは、リスクに見合うだけの価値があります。このプロセスを妨げたり、逆転させたりする可能性のある問題をいくつか挙げます。

人々は変化を望まない。人々は慣れ親しんだ環境を再現する傾向があり、それが伝統的な思考者・実行者モデルに戻る傾向につながる可能性があります。新入社員は新しい組織構造に慣れやすくなります。 API が失敗したり、アルゴリズムがうまく機能しなかったりするなど、何か問題が発生した場合は特に注意してください。

人々はエンジニアに責任があると主張するでしょうが、彼らは問題そのものではなく症状を説明していることが多いのです。エンジニアがすべきことは、プラットフォームに対してより優れたサポート、視覚化、抽象化、堅牢性を提供することです。同時に、エンジニアは物を壊してしまう可能性があることを認識する必要があります。誰も間違いを犯さない、何も壊さないと保証することはできません。 36 ビッグデータ (http://www.36dsj.com/)

プラットフォーム エンジニアはデータ サイエンティストよりも先を行く必要があります。チームには、データ サイエンティストが必要とするサービス、フレームワーク、機能を予測できる、非常に洞察力のあるエンジニアが必要です。データ サイエンティストが自分のアイデアをエンジニアに渡して実装しなくなった結果、エンジニアはデータ サイエンティストのニーズに応えられなくなり、事前に予測できるようになる必要があります。

エンジニアはレゴブロックを組み立てますが、データ サイエンティストはそれを組み立てるということを覚えておいてください。データ サイエンティストが適切なビルディング ブロックを持っていない場合、他の解決策を見つけることになります。彼らは間違ったブロック（丸い穴の中にある四角いブロック）を使うか、独自のブロックを作るかのどちらかです。一般的に言えば、車輪の再発明のプロセスには体系的かつ全体的な考慮が欠けており、混乱が生じます。一度このような混乱が生じると、後始末が難しく、諺にあるように、こぼした水は元には戻らない。

効率の問題を恐れない

データ サイエンティストに非常に幅広いタスクを引き受けるよう奨励することの 1 つの結果として、データ サイエンティストはプロのエンジニアほど専門的かつ効率的にコードやソリューションを作成できなくなる可能性があります。私たちは効率性よりもスピードと自律性を重視しています。この複雑なトレードオフを認識することは非常に重要です。

しかし同時に、このエンドツーエンドの自律性には、あまり目立たない効率性もいくつかあります。データ サイエンティストは実装する分野の専門家であるため、テクノロジーのニーズとコストの間でトレードオフを行うことができます。たとえば、適切な場合にはサンプリング データや近似法を使用することを決定したり、実装や保守にコストがかかりメリットが限られている一部の機能を削除することを決定したりする場合があります。こうしたことは、基本的に従来の思考者・実行者モデルでは決して起こりません。また、起こったとしても、繰り返しのコミュニケーションと交渉を犠牲にして起こります。

全体として、この自律性によってもたらされる効率性と革新性が、データ サイエンティストの「フルスタック開発」によってもたらされる非効率性の一部を上回ることを期待しています。

未来

データ サイエンス部門を編成する最善の方法を発見した、あるいはこれがあなたの組織にとって最善の方法であると主張するつもりはありません。しかし、これは決して「より速い馬」を作ろうとする試みではなく、私たちにとってははるかに良いアプローチだと思います。

私たちの試みを共有することで、他の非伝統的なデータ サイエンス部門にも同じ試みをするよう促し、新しい部門を構築しているリーダーに既成概念にとらわれず伝統に挑戦するよう刺激を与え、従来の組織構造によって「傷ついた」エンジニアやデータ サイエンティストに、機能する他のモデルや環境があることを伝えることができることを心から願っています。

参考文献:

[1] この記事における「データサイエンティスト」は、中国でより一般的に使用されている「アルゴリズムエンジニア」または「アルゴリズム研究者」の役割に相当します。

[2] この記事で言う「エンジニア」、「データエンジニア」または「データプラットフォームエンジニア」は、中国でより一般的に使用されている「エンジニアリング指向」または「アーキテクチャ指向」のエンジニアの役割に対応します。

[3] 面接官（データプラットフォームエンジニア）に、データサイエンティストがどこにいるか知っているか尋ねます（またはその逆）。知らないなら逃げろよ…

[4] なぜなら、これらの人々の主な仕事は、配管工と同じように、データチャネルが妨げられていないことを確認することだからです。

[5] フォード・モーター社の創設者であるフォードはかつてこう言った。「（自動車が発明されたときに）人々に何が欲しいかと尋ねたら、彼らはもっと速い馬が欲しいと答えただろう。」古いルールを守りながら、既存の枠組みの中で改善を加えることの比喩。

[6] ここでの「知らせる」という言葉は、伝統的な業界ではBIは分析結果を業務部門に伝えるか通知するだけであることが多いが、その結果を採用するかどうかは依然として業務部門が決定しているという事実を指しています。これは、伝統的なBI部門のやや厄介な立場を反映しています。

[7] 「水平」とは、スケーラブルで再利用性の高いアプリケーションやコンポーネントを開発することを指します。