企業がデータエンジニア向けのツールを選択し、すべてをテクノロジー動物園に変えるのではない方法：PROFI.RUの経験

Netologyの編集者は、Profi.ru Pavel SayapinのBIチームのチームリーダーと、データエンジニアがチームで解決するタスク、そのために使用するツールの種類、データの問題を解決するための適切なツールの選択方法について話しました。非定型を含む。Pavelはデータエンジニアコースの教師です。 

Profi.ruでデータエンジニアが行うこと

Profi.ruは、さまざまな分野のクライアントとスペシャリストが出会うのを支援するサービスです。サービスデータベースには、700種類のサービス（チューター、修理工、コーチ、ビューティーマスター、アーティストなど）の90万人を超えるスペシャリストが含まれています。毎日1万件以上の新規注文が登録されています。これにより、1日あたり約1億件のイベントが発生します。この量のデータを整理することは、専門のデータエンジニアなしでは不可能です。  



理想的には、データエンジニアは、企業が追加の収益を生み出したり、コストを削減したりするのに役立つデータ文化を開発します。チームで作業し、開発者からレポートのビジネスコンシューマーまで、さまざまな参加者間の重要なリンクとして機能することにより、ビジネスに価値をもたらします。ただし、企業ごとにタスクが異なる場合があるため、Profi.ruの例を使用して検討します。

— -, -,  

データは意思決定のために明確で、使いやすいものでなければなりません。説明を見つけたり、さまざまな要因を考慮した複雑なSQLクエリを記述したりするために努力する必要はありません。理想的な画像-ユーザーはダッシュボードを見て、すべてに満足しています。そして、ある面で十分なデータがない場合、それはデータベースに送られ、単純なSQLクエリの助けを借りて必要なものを取得します。





データウェアハウスの一般的な構造におけるデータ品質プロセスの配置データの操作に関する



説明文書は非常に重要です。これにより、データエンジニア（質問に気を取られない）とデータユーザー（自分の質問に対する答えを自分で見つけることができる）の両方の作業が簡素化されます。 Profi.ruでは、そのようなドキュメントは内部フォーラムに収集されます。



利便性には、データ取得の速度が含まれます。速度=ワンステップでの可用性、クリック-ダッシュボード。しかし実際には、すべてがもっと複​​雑です。 



ダッシュボードのエンドユーザーの観点からは、同じTableauですべての可能な寸法を表示することはできません。ユーザーは、ダッシュボード開発者によって作成されたフィルターに満足しています。これにより、次の2つのシナリオが作成されます。 

• 開発者はダッシュボードを何度もカットします⟶ページ数が大幅に増加します。これにより、データの可用性が低下します。何がどこにあるのかを理解することが難しくなります。 
• 開発者はキーカットのみを作成します。情報を見つけるのは簡単ですが、標準的なカットが少し少ない場合でも、データベースまたはアナリストのいずれかに行く必要があります。これはアクセシビリティにも悪影響を及ぼします。 

アクセシビリティは広い概念です。これは、適切な形式のデータの可用性、ダッシュボードの情報を取得する機能、および必要なデータカットです。

すべてのソースからのデータを1か所に蓄積する

データソースは内部または外部にすることができます。たとえば、誰かのビジネスは、外部ソースから収集および保存される気象レポートに依存しています。 



ソースを示した情報を保存し、データを簡単に見つけられるようにする必要があります。Profi.ruは、自動化されたドキュメントの助けを借りてこの問題を解決します。YMLファイルは、内部データソースのドキュメントとして使用されます。

ダッシュボードを作成する

データの視覚化は、Tableauなどの専門的なツールで行うのが最適です。 



ほとんどの人は感情的に決定を下します-可視性と美学が重要です。ちなみに、視覚化のための同じExcelはあまり適していません。それは、データユーザーのすべてのニーズをカバーしているわけではありません。たとえば、製品マネージャーは数字を掘り下げるのが好きですが、それは便利な方法です。これにより、彼は自分の問題を解決することができ、情報を取得してメトリックを収集する方法について考える必要がなくなります。

高品質のデータ視覚化により、意思決定がより簡単かつ迅速になります。

 

人の位置が高いほど、電話で手元に集計データを用意する必要性が高まります。トップマネージャーは詳細を必要としません-全体として状況を管理することが重要であり、BIはこれに適したツールです。





製品ダッシュボードProfi.ru（シートの1つ）の例。機密保持の目的で、メトリックと軸の名前は非表示になっています

実際のタスクの例 

タスク1-ソース（オペレーティング）システムからデータウェアハウスまたはETLにデータを転送する

データエンジニアの日常業務の1つ。 



これには次のものを使用できます。

• cronによって実行されるか、AirflowやPrefectなどの特別なオーケストレーターを使用して実行される自作のスクリプト。 
• オープンソースETLソリューション：Pentaho Data Integration、Talend DataStudioなど。
• 独自のソリューション：Informatica PowerCenter、SSISなど。
• クラウドソリューション：Matillion、Panoplyなど。 

単純なバージョンでは、20行のYMLファイルを書き込むことでタスクが解決されます。所要時間は約5分です。 



最も難しいケースでは、新しいソース（新しいデータベースなど）を追加する必要がある場合、最大で数日かかることがあります。 



Profiでは、この単純なタスク（プロセスが合理化されている）は、次の手順で構成されています。

• 必要なデータとその場所を顧客から調べます。
• このデータにアクセスできるかどうかを理解します。
• アクセスできない場合は、管理者に問い合わせてください。
• Jira発行コードを使用してGitに新しいブランチを追加します。
• インタラクティブなPythonスクリプトを使用して、アンカーモデルにデータを追加するための移行を作成します。
• ロードファイル（データがどこから取得され、どのテーブルに書き込まれるかを記述したYMLファイル）を追加します。
• スタンドでテストします。
• データをリポジトリにアップロードします。
• プルリクエストを作成します。
• コードレビューを実行します。
• コードレビューに合格すると、データはマスターブランチにアップロードされ、自動的に本番環境（CI / CD）にロールインされます。

タスク2-ダウンロードしたデータを便利に配置する

もう1つの一般的なタスクは、ロードされたデータを配置して、エンドユーザー（またはBIツール）が快適に操作でき、ほとんどのタスクで不要な移動を行う必要がないようにすることです。つまり、Dimension Data Store（DDS）を構築または更新します。 



これには、ETLプロセスでもあるため、最初のタスクのソリューションを適用できます。最も単純な形式では、DDSはSQLスクリプトを使用して更新されます。

タスク3-非定型タスクのカテゴリから

ストリーミング分析はProfiで生まれました。製品チームから多数のイベントが生成されます-ClickHouseに記録します。ただし、レコードを1つずつ大量に挿入することはできないため、レコードをバッチに結合する必要があります。つまり、直接書き込むことはできません。中間ハンドラーが必要です。



ApacheFlinkベースのエンジンを使用しています。これまでの手順は次のとおりです：エンジンはイベントの着信ストリームを処理します⟶ClickHouseにバッチで追加します⟶オンザフライでイベントの数をカウントします⟶サービスに転送し、異常があるかどうかを判断します-3か月の深さで同じ15分間の値と比較します⟶存在する場合は、Slackに通知を送信します。





フロントエンド分析スキーマ（ダウンロード部分）



Apache Flinkフレームワークは、少なくとも1回の配信を保証します。ただし、重複する可能性があります。RabbitMQの場合、これは相関IDを使用して解決できます。その後、単一の配信⟶データの整合性が保証されます。



Apache Flinkを使用してイベントの数を再度カウントし、NodeJSで記述された自作のダッシュボード+ ReactJSの前面に表示します。クイック検索では、同様の解決策は得られませんでした。そして、コード自体は単純であることが判明しました-書くのにそれほど時間はかかりませんでした。



監視はかなり技術的です。早期の問題を防ぐために、異常を調べます。ストリーミング分析の方向性は形成段階にあるため、会社のいくつかの重要なグローバルメトリックはまだ監視に含まれていません。

エッセンシャルデータエンジニアツール

データエンジニアのタスクにより、多かれ少なかれ明確になり、それらを解決するために使用されるツールについて少し説明します。もちろん、さまざまな企業のツールは異なる可能性があります（そして異なるはずです）-それはすべて、データの量、受信速度、および異質性に依存します。それはまた、スペシャリストがそれを扱い、それをよく知っているという理由だけで、ある特定の楽器に対するスペシャリストの偏見に依存する可能性があります。Profi.ruはそのようなオプションに落ち着きました→

データ視覚化の場合-Tableau、Metabase

Tableauは長い間選ばれました。このシステムを使用すると、コストのかかる実装を必要とせずに、大量のデータをすばやく分析できます。私たちにとって、それは便利で美しく、なじみ深いものです-私たちはしばしばそれで働きます。



Metabaseについて知っている人はほとんどいませんが、プロトタイピングには非常に適しています。 



視覚化ツールから、Airbnbのスーパーセットについても言うことができます。その特別な機能は、多くのデータベース接続と視覚化機能です。ただし、通常のユーザーにとっては、メタベースほど便利ではありません。テーブルを結合することはできません。このため、個別のビューを作成する必要があります。 



同じメタベースで、テーブルを結合できます。さらに、データベーススキーマを考慮して、サービス自体が結合します。そして、Metabaseのインターフェースはよりシンプルで優れています。



たくさんのツールがあります-あなたのものを見つけてください。

データストレージの場合-ClickHouse、Vertica

ClickHouseは、食料品のイベントを保存するための無料の高速ツールです。その上で、アナリスト自身が個別の分析を行うか（十分なデータがある場合）、データエンジニアが集計を取得し、Verticaに再アップロードしてストアフロントを構築します。



Verticaは、エンドストアディスプレイ向けのクールでユーザーフレンドリーな製品です。 

データフローの制御と計算用-Airflow

コンソールツールを介してデータをロードします。たとえば、MySQLに付属しているクライアントを使用すると、結果が速くなります。 



コンソールツールの利点は速度です。データは、同じPythonプロセスのメモリを介してポンプされません。マイナス面のうち、あるデータベースから別のデータベースに転送されるデータに対する制御は少なくなります。

主なプログラミング言語はPythonです

Pythonのエントリのしきい値ははるかに低く、会社はこの言語での能力を持っています。もう1つの理由は、AirflowではDAGがPythonで記述されていることです。これらのスクリプトはダウンロードの単なるラッパーであり、ほとんどの作業はコンソールスクリプトを介して行われます。 



リアルタイムの分析開発にはJavaを使用しています。

データツールを選択するためのアプローチ-テクノロジー動物園を繁殖させないために何をすべきか

市場には、外観から出力、取締役会のダッシュボードまで、あらゆる段階でデータを操作するための多くのツールがあります。当然のことながら、一部の企業には、関連のないソリューション、いわゆるテクノロジー動物園がいくつかある場合があります。



ハイテク動物園は同じことをするツールです。たとえば、メッセージングの場合はKafkaとRabbitMQ、視覚化の場合はGrafanaとZeppelinです。 





データとAIの分野におけるテクノロジーと企業のマップ-重複するソリューションがいくつあるかがわかります



また、個人的な目的の多くは、さまざまなETLツールを使用できます。 Profiでは、これはまさに状況です。メインのETLはAirflowにありますが、誰かが個人的なアップロードにPentahoを使用しています。彼らは仮説をテストし、エンジニアを通してこのデータを実行する必要はありません。基本的に、セルフサービスツールは、製品開発の新しい方法を模索する研究活動に従事する経験豊富なスペシャリストによって使用されます。分析のための彼らのデータのセットは、主に彼らにとって興味深いものであり、さらに、それは絶えず変化しています。したがって、これらの負荷をメインプラットフォームに追加することは意味がありません。 



動物園に戻ります。多くの場合、重複するテクノロジーの使用は人的要因に関連しています。個別の内部チームは、別のチームが使用できない可能性のある1つまたは別のツールを使用することに慣れています。また、特別な問題を解決する唯一の方法が自律性である場合もあります。たとえば、R＆Dチームは、特定のツールを使用して何かをテストする必要があります。これは便利なこと、チームの誰かがすでに使用していること、または別の理由があります。システム管理者のリソースがこのツールをインストールして構成するのを待つのは長い時間です。同時に、思慮深く細心の注意を払った管理者は、これが本当に必要であることを証明する必要があります。そのため、チームはツールを仮想マシンにインストールし、特定のタスクを解決します。

, . , . 

新しいツールが登場するもう1つの一般的な理由は、標準がまだ形成されていないか、実証済みのガイドラインがない、かなり新しい領域で未知の製品を試したいという願望です。開発者のようなデータエンジニアは、現在の問題に対するより良い解決策を見つけること、または市場が提供するものに遅れないようにすることを期待して、常に新しいツールを研究する必要があります。



新しいツールを試してみたいという誘惑は本当に素晴らしいです。しかし、正しい選択をするためには、まず第一に自己規律が必要です。研究の衝動に完全に専念するのではなく、新しいツールのインフラストラクチャをサポートする会社の能力を考慮に入れるのに役立ちます。 

テクノロジーのためにテクノロジーを使用しないでください。質問に実際的にアプローチするのが最善です。タスクは、このタスクを解決できるツールのセットです。

 そして、それらのそれぞれを評価し、最良のものを選択します。たとえば、このツールは問題をより効率的に解決できますが、その能力がなく、このツールの効果はやや劣りますが、会社にはこのツールの操作方法を知っている人がいます。このツールは有料ですが、保守と使用が簡単で、ファッショナブルなオープンソースですが、それをサポートするには管理者のスタッフが必要です。そのような二分法は、解決するためにクールな頭を必要とするようになります。

楽器を選ぶことは、信仰の半分の飛躍であり、個人的な経験の半分です。ツールが適合するという完全な確実性はありません。

たとえば、Profiでは、この楽器の専門知識を持っていたため、Pentahoから始めましたが、最終的には間違った決定であることが判明しました。プロジェクトが成長するにつれて、内部のPentahoリポジトリは非常に遅くなりました。ちなみに、データを保存するのに1分かかりましたが、常に作業を保存する習慣があると、時間が足りなくなってしまいました。これに、複雑な起動、スケジュールされたタスクが追加されました-コンピューターがハングしました。 



大規模なコミュニティで人気のあるツールであるAirflowに切り替えた後、苦しみは終わりました。 

複雑な問題を解決するには、ツールであるコミュニティサービスの存在が重要です。同僚にアドバイスを求めることができます。

会社が成熟していてリソースがある場合は、技術サポートの購入を検討するのが理にかなっています。これにより、問題をすばやくトラブルシューティングし、製品の使用に関する推奨事項を受け取ることができます。



選択へのアプローチについて話す場合、Profiは次の原則に従います。

• 一人で決断しないでください。人が何かを選ぶとき、彼は自動的に彼が正しいと確信します。強力な防御がなされたときに他の人を説得することは別の問題です。これは、機器の弱点を確認するのにも役立ちます。
• チーフデータオフィサーにアドバイスを求める（垂直対話）。これは、チーフデータエンジニア、BIチームの責任者になることができます。トップスは状況をより広く見ています。 
• 他のチームと通信する（水平方向の対話）。彼らはどのツールをどの程度使用していますか。おそらく、同僚のツールで問題を解決でき、解決策の動物園を手配する必要はありません。

外部サービスプロバイダーの効果的な代替としての内部能力

ツールの選択へのアプローチは、企業の内部能力の使用と見なすこともできます。 



多くの場合、ビジネスに困難なタスクがありますが、それを実装するための資金がありません。タスクは大きくて重要であり、良い意味で、関連する経験を持つ外部のサービスプロバイダーを関与させることが最善です。しかし、そのような機会（お金）がないため、問題を解決するために内部チームが割り当てられます。さらに、通常、企業は、従業員がすでにその有効性を証明している場合、その従業員をより信頼します。



このようなタスクの例は、従業員によって新しい方向性が開発されている場合、負荷テストの実行とデータウェアハウスの作成です。特にデータウェアハウスは、すべてのビジネスにとってユニークなストーリーです。ストレージは購入できません。内部チームのサポートを受けて構築する外部スペシャリストのみを雇うことができます。  



ちなみに、新しい方向性が進むにつれて、チームは外部サービスプロバイダーの必要性がなくなったことに気付くかもしれません。



Profiでは、BIの実装は社内で行われました。主な問題は、企業がBIを迅速に立ち上げたいということでした。しかし、そのようなプロジェクトを構築するには時間がかかりました。能力を構築し、データを入力し、便利なストレージスキームを構築し、ツールを選択してそれらを習得します。



すべてが構築され、結晶化されたメインのホットフェーズは、約1年間続きました。そして、プロジェクトはまだ発展途上です。 

企業のデータウェアハウスを構築するときは、高い基準を遵守し、自分の立場を守り、ビジネスを満足させるようなことをしないことが重要です。 



プロジェクトの大部分をやり直したのは大変な苦痛でしたが、それはすぐに実行しなければなりませんでした。

 ただし、迅速なアプローチが推奨される場合もあります。したがって、製品開発では、それが唯一の正しいものでさえあるかもしれません。迅速に前進し、製品の仮説をテストする必要があります。ただし、ストレージは堅固なアーキテクチャに基づいている必要があります。そうしないと、成長するビジネスに迅速に適応できず、プロジェクトが終了します。



この困難なプロジェクトでは、私たちのリーダーは、作業の進行を擁護し、私たちが行っていることを経営陣に説明し、リソースをノックアウトし、単に私たちを保護した多くの人を助けました。そのような支援がなければ、プロジェクトを立ち上げることができたかどうかはわかりません。



そのような話では、トップマネージャー、アナリスト、製品マネージャーの間で、いわゆるアーリーアダプター（新しいことを試す準備ができている人）が重要な役割を果たします。大雑把なトピックを取り上げるには、すべてが機能し、使いやすいことを確認するパイオニアが必要です。



上記の3番目の問題の解決策を誰かが共有したい場合-ようこそ:-)