データのボトルネックを回避—スターシップのデータメッシュ| TaaviPungas著| スターシップテクノロジーズ| 2021年5月

by PCJISAKUTECH
0 comment


Taavi Pungas

食料品の袋のギガバイトのデータ。 これは、ロボットによる配信を行うときに得られるものです。 それは大量のデータです—特にそれを繰り返す場合 100万回以上 私たちが持っているように。

しかし、うさぎの穴はさらに深くなります。 データも非常に多様です。ロボットセンサーと画像データ、アプリとのユーザーインタラクション、注文からのトランザクションデータなどです。 また、ディープニューラルネットワークのトレーニングからマーチャントパートナー向けの洗練された視覚化の作成まで、その間のすべてのユースケースも同様に多様です。

これまでのところ、一元化されたデータチームでこの複雑さのすべてを処理することができました。 今では、継続的な指数関数的成長により、ペースを維持するための新しい働き方を模索するようになりました。

データメッシュパラダイムが最善の方法であることがわかりました。 以下では、スターシップのデータメッシュに対する考え方について説明しますが、最初に、アプローチの概要と、それを採用することにした理由について説明します。

データメッシュとは何ですか?

データメッシュフレームワークは 最初に説明された ZhamakDehghaniによる。 パラダイムは次のことに基づいています コアコンセプト:データ製品、データドメイン、データプラットフォーム、およびデータガバナンス。

データメッシュフレームワークの主な目的は、大規模な組織がデータエンジニアリングのボトルネックを解消し、複雑さに対処できるようにすることです。 したがって、データ品質、アーキテクチャ、セキュリティからガバナンスや組織構造に至るまで、企業環境に関連する多くの詳細に対応します。 現状では、 いくつかの会社 データメッシュパラダイムの順守を公に発表しました—すべての大規模な数十億ドル規模の企業。 それでも、中小企業にもうまく適用できると思います。

Starshipのデータメッシュ

データは、情報を生成または消費する人々の近くで機能しますか

世界中でハイパーローカルロボット配信マーケットプレイスを運営するには、さまざまなデータを価値のある製品に変える必要があります。 データは、ロボット(テレメトリ、ルーティング決定、ETAなど)、マーチャントと顧客(アプリ、注文、オファリングなど)、およびビジネスのすべての運用面(簡単なリモートオペレータータスクからスペアのグローバルロジスティクスまで)から受信されます。部品およびロボット)。

ユースケースの多様性が、データメッシュアプ​​ローチに私たちを惹きつけた主な理由です。私たちは、情報を生成または消費する人々の非常に近くでデータ作業を実行したいと考えています。 データメッシュの原則に従うことで、中央監視を適度に軽く保ちながら、チームの多様なデータニーズを満たすことを望んでいます。

Starshipはまだエンタープライズ規模ではないため、データメッシュのすべての側面を実装することは現実的ではありません。 代わりに、私たちは現在私たちにとって意味があり、将来への正しい道に私たちを置く単純化されたアプローチに落ち着きました。

データ製品

データ製品とは何かを定義します—それぞれに所有者、インターフェース、ユーザーがいます

製品思考をデータに適用することは、アプローチ全体の基盤です。 他のユーザーやプロセスにデータを公開するものはすべて、データ製品と見なします。 BIダッシュボード、Kafkaトピック、データウェアハウスビュー、予測マイクロサービスからの応答など、あらゆる形式でデータを公開できます。

Starshipのデータ製品の簡単な例は、サイトの取引量を追跡するためのサイトリードのBIダッシュボードです。 より複雑な例は、ロボットからデータレイクにあらゆる種類の運転情報を送信するためのロボットソフトウェアエンジニア向けのセルフサービスパイプラインです。

いずれにせよ、データウェアハウス(実際にはDatabricksレイクハウス)を単一の製品としてではなく、相互接続された多数の製品をサポートするプラットフォームとして扱います。 このようなきめ細かい製品は通常、専任の製品マネージャーではなく、データサイエンティスト/エンジニアが所有し、それらを構築および保守します。

製品の所有者は、ユーザーが誰であり、製品でどのようなニーズを解決しているのかを知ることが期待されます。それに基づいて、製品の品質に対する期待を定義し、それに応えます。 おそらく結果として、使いやすさには不可欠であるが変更が面倒なコンポーネントであるインターフェースに、より前もって注意を払うようになりました。

最も重要なことは、ユーザーと各製品がユーザーにもたらしている価値を理解することで、アイデア間の優先順位付けがはるかに簡単になることです。 これは、迅速に行動する必要があり、すべてを完璧にする時間がないスタートアップのコンテキストでは重要です。

データドメイン

会社の組織構造を反映するドメインにデータ製品をグループ化します

データメッシュモデルに気付く前は、次の形式を使用することに成功していました。 軽く埋め込まれたデータサイエンティスト スターシップでしばらくの間。 事実上、一部の主要なチームには、データチームのメンバーがパートタイムで協力していました。これは、特定のチームで意味することは何でもです。

組織構造に合わせてデータドメインの定義を進めましたが、今回は会社のあらゆる部分をカバーするように注意しました。 データ製品をドメインにマッピングした後、各ドメインをキュレートするデータチームメンバーを割り当てました。 この担当者は、ドメイン内のデータ製品のセット全体を管理する責任があります。その一部は同じ担当者が所有し、一部はドメインチームの他のエンジニアが所有し、一部は他のデータチームメンバーが所有します(リソース上の理由など)。 。

ドメインの設定について、私たちが気に入っている点はたくさんあります。 何よりもまず、今では会社のすべての領域にデータアーキテクチャの世話をする人がいます。 すべてのドメインに固有の微妙さを考えると、これは私たちが作業を分割したためにのみ可能です。

データ製品とインターフェースに構造を作成することも、データの世界をよりよく理解するのに役立ちました。 たとえば、データチームのメンバーよりもドメインが多い状況(現在は19対7)では、現在、私たち一人一人が相互に関連する一連のトピックに取り組んでいることを確認するためのより良い仕事をしています。 そして、増大する苦痛を軽減するために、ドメインの境界を越えて使用されるインターフェースの数を最小限に抑える必要があることを理解しました。

最後に、データドメインを使用することのより微妙なボーナス:私たちは今、あらゆる種類の新しい状況に取り組むためのレシピを持っていると感じています。 新しいイニシアチブが登場するたびに、それがどこに属し、誰がそれを実行する必要があるかがはるかに明確になります。

いくつかの未解決の質問もあります。 一部のドメインは主にソースデータを公開することに傾倒し、他のドメインはそれを消費して変換することに傾倒しますが、両方のドメインがかなりあるものもあります。 それらが大きくなりすぎたときに、これらを分割する必要がありますか? それとも、より大きなサブドメイン内にサブドメインを含める必要がありますか? 今後、これらの決定を下す必要があります。

データプラットフォーム

一元化せずに標準化することで、データ製品を構築する人々に力を与えます

Starshipのデータプラットフォームの目標は単純明快です。1人のデータ担当者(通常はデータサイエンティスト)がドメインをエンドツーエンドで処理できるようにします。つまり、中央のデータプラットフォームチームを1日のうちに締め出すことができます。今日の仕事。 そのためには、ドメインエンジニアとデータサイエンティストに、データ製品用の優れたツールと標準的な構成要素を提供する必要があります。

データメッシュアプ​​ローチには完全なデータプラットフォームチームが必要だということですか? あんまり。 私たちのデータプラットフォームチームは、ドメインに組み込まれた時間の半分を並行して費やしている単一のデータプラットフォームエンジニアで構成されています。 データプラットフォームエンジニアリングに非常に傾倒できる主な理由は、データプラットフォームのコアとしてSpark + Databricksを選択したことです。 以前の従来のデータウェアハウスアーキテクチャでは、データドメインが多様であるため、データエンジニアリングに大きなオーバーヘッドがかかりました。

プラットフォームの一部であるコンポーネントと他のすべてのコンポーネントをデータスタックで明確に区別すると便利であることがわかりました。 データプラットフォームの一部としてドメインチームに提供するもののいくつかの例:

  • 作業環境および多用途のコンピューティングプラットフォームとしてのDatabricks + Spark;

一般的なアプローチとして、私たちの目的は、現在のコンテキストで意味のある範囲で標準化することです。私たちが知っているビットでさえ、永遠に標準化されたままになることはありません。 それが現在の生産性に役立ち、プロセスのどの部分も一元化されていない限り、私たちは満足しています。 そしてもちろん、いくつかの要素は現在プラットフォームから完全に欠落しています。 たとえば、データ品質保証、データ検出、およびデータ系統のためのツールは、私たちが将来に残したものです。

データガバナンス

フィードバックループによってサポートされる強力な個人所有権

人とチームの数を減らすことは、実際にはガバナンスのいくつかの側面における資産です。たとえば、意思決定がはるかに簡単です。 一方、私たちの重要なガバナンスの質問は、私たちの規模の直接的な結果でもあります。 ドメインごとに1人のデータ担当者がいる場合、すべての潜在的な技術的側面の専門家であると期待することはできません。 ただし、ドメインを詳細に理解しているのは彼らだけです。 ドメイン内で適切な選択を行う可能性を最大化するにはどうすればよいでしょうか。

私たちの答え:チーム内の所有権、議論、フィードバックの文化を介して。 経営理念から惜しみなく借りてきました Netflixで そして、以下を栽培しました:

  • (自分の製品とドメインの)結果に対する個人的な責任。

また、品質への取り組み方、ベストプラクティス(命名規則を含む)などについて、いくつかの具体的な合意を行いました。しかし、ガイドラインを実現するための重要な要素は、優れたフィードバックループであると考えています。

これらの原則は、このブログ投稿の焦点となっているデータチームの「構築」作業以外にも適用されます。 明らかに、 もっとたくさんあります データサイエンティストが会社でどのように価値を創造しているかにデータ製品を提供するよりも。

ガバナンスに関する最終的な考え—私たちは自分たちの働き方を繰り返し続けます。 物事を行うための単一の「最良の」方法は決してありません。私たちは、時間をかけて適応する必要があることを知っています。

最後の言葉

これだよ! これらは、Starshipで適用された4つのコアデータメッシュの概念でした。 ご覧のとおり、機敏な成長段階の企業として私たちに適したデータメッシュへのアプローチを見つけました。 あなたの文脈でそれが魅力的に聞こえるなら、私たちの経験について読むことがお役に立てば幸いです。

私たちの仕事に参加したい場合は、を参照してください 私たちのキャリアページ 募集中のポジションのリストについては。 またはチェックアウト 私たちのYoutubeチャンネル 世界をリードするロボットデリバリーサービスの詳細をご覧ください。

ご不明な点やご意見がございましたら、お気軽にお問い合わせください。



Source link

You may also like

Leave a Comment