Sber.DS は、コードがなくてもモデルを作成および実装できるプラットフォームです

他にどのようなプロセスを自動化できるかについてのアイデアや会議が、さまざまな規模の企業で毎日生まれています。 ただし、モデルの作成に多くの時間が費やされることに加えて、モデルを評価し、得られた結果がランダムではないことを確認することにも時間を費やす必要があります。 導入後は、どのモデルも監視し、定期的にチェックする必要があります。

これらは、規模に関係なく、どの企業でも完了する必要があるすべての段階です。 ズベルバンクの規模とレガシーについて話している場合、微調整の数は大幅に増加します。 2019 年末までに、Sber はすでに 2000 を超えるモデルを使用していました。 単にモデルを開発するだけでは十分ではなく、産業システムと統合し、モデルを構築するためのデータ マートを開発し、クラスター上での動作を確実に制御する必要があります。

私たちのチームは Sber.DS プラットフォームを開発しています。 これにより、機械学習の問題を解決し、仮説をテストするプロセスをスピードアップし、原理的にはモデルの開発と検証のプロセスを簡素化し、PROM 内のモデルの結果を制御することもできます。

皆さんの期待を裏切らないように、この投稿は入門的なものであることをあらかじめ言っておきます。まず、基本的に Sber.DS プラットフォームの内部にあるものについて説明します。 モデルの作成から実装までのライフサイクルについては、別途お話します。

Sber.DS はいくつかのコンポーネントで構成されており、主要なものはライブラリ、開発システム、モデル実行システムです。

このライブラリは、モデルを開発するというアイデアが浮かんだ瞬間から、PROM での実装、監視、および廃止に至るまで、モデルのライフ サイクルを制御します。 ライブラリの機能の多くは、トレーニングおよび検証サンプルのレポート作成や保存など、規制当局の規則によって決まります。 実際、これは当社のすべてのモデルの登録です。

開発システムは、モデルと検証手法を視覚的に開発できるように設計されています。 開発されたモデルは初期検証を受け、ビジネス機能を実行するために実行システムに提供されます。 また、ランタイム システムでは、モデルの動作を監視するための検証手法を定期的に起動する目的で、モデルをモニター上に配置することもできます。

システムにはいくつかのタイプのノードがあります。 さまざまなデータ ソースに接続するように設計されているものもあれば、ソース データを変換して強化 (マークアップ) するように設計されているものもあります。 さまざまなモデルを構築するためのノードと、それらを検証するためのノードが多数あります。 開発者は、任意のソースからデータをロードし、中間データを変換、フィルタリング、視覚化し、それを部分に分割できます。

プラットフォームには、設計領域にドラッグ アンド ドロップできる既製のモジュールも含まれています。 すべてのアクションは、視覚化されたインターフェイスを使用して実行されます。 実際、コードを XNUMX 行も書かずに問題を解決できます。

組み込みの機能が十分でない場合、システムは独自のモジュールを迅速に作成する機能を提供します。 に基づいて統合開発モードを作成しました。 Jupyterカーネルゲートウェイ 新しいモジュールを最初から作成する人向け。

Sber.DS のアーキテクチャはマイクロサービスに基づいて構築されています。 マイクロサービスとは何かについては多くの意見があります。 モノリシックなコードをいくつかの部分に分割するだけで十分だと考える人もいますが、同時に同じデータベースにアクセスします。 マイクロサービスは、REST API を介してのみ別のマイクロサービスと通信する必要があります。 データベースに直接アクセスする回避策はありません。

私たちは、サービスが非常に大きくなり、扱いにくくならないように努めています。4 つのインスタンスが 8 ～ XNUMX GB を超える RAM を消費してはならず、新しいインスタンスを起動してリクエストを水平にスケーリングする機能を提供する必要があります。 各サービスは REST API 経由でのみ他のサービスと通信します (オープンAPI）。 サービスを担当するチームは、最後のクライアントが API を使用するまで API の下位互換性を維持する必要があります。

アプリケーションのコアは、Spring Framework を使用して Java で作成されます。 このソリューションは当初、クラウド インフラストラクチャに迅速に導入できるように設計されていたため、アプリケーションはコンテナ化システムを使用して構築されました。 Red Hat OpenShift (Kubernetes）。 このプラットフォームは、ビジネス機能の向上 (新しいコネクタ、AutoML が追加されています) と技術効率の両方の点で常に進化しています。

私たちのプラットフォームの特徴の XNUMX つは、ビジュアル インターフェイスで開発されたコードを任意の Sberbank モデル実行システム上で実行できることです。 現在、それらはすでに XNUMX つあります。XNUMX つは Hadoop 上に、もう XNUMX つは OpenShift (Docker) 上にあります。 私たちはそこにとどまらず、オンプレミスやクラウドを含むあらゆるインフラストラクチャ上でコードを実行するための統合モジュールを作成します。 ズベルバンクのエコシステムへの効果的な統合の可能性に関しては、既存の実行環境との連携もサポートする予定です。 将来的には、このソリューションは「すぐに使える」あらゆる組織のあらゆる状況に柔軟に統合できるようになります。

PROM の Hadoop 上で Python を実行するソリューションをサポートしようとしたことのある人は、Python ユーザー環境を準備して各データノードに配信するだけでは十分ではないことを知っています。 Python モジュールを使用する機械学習用の C/C++ ライブラリは膨大な数にあるため、安心することはできません。 新しいライブラリやサーバーを追加するときは、既に実装されているモデル コードとの下位互換性を維持しながら、忘れずにパッケージを更新する必要があります。

これを行う方法にはいくつかの方法があります。 例えば、よく使うライブラリをあらかじめいくつか用意してPROMに実装しておきます。 Cloudera の Hadoop ディストリビューションでは、通常、 小包。 Hadoopでも実行できるようになりました ドッカー-コンテナ。 いくつかの単純なケースでは、パッケージと一緒にコードを配信することが可能です Python.eggs.

この銀行は、サードパーティ コードを実行する際のセキュリティを非常に重視しているため、プロセスが分離された環境で実行される Linux カーネルの新機能を最大限に活用しています。 Linux 名前空間を使用すると、ネットワークやローカル ディスクへのアクセスなどを制限でき、悪意のあるコードの可能性が大幅に低下します。 各部門のデータ領域は保護されており、このデータの所有者のみがアクセスできます。 このプラットフォームは、ソースへのアクセスからターゲットの店頭へのデータの着陸までのすべての段階を制御するデータ公開プロセスを通じてのみ、あるエリアからのデータが別のエリアに到達できるようにします。

今年は、Hadoop 上で Python/R/Java で書かれたモデルを起動するという MVP を完了する予定です。 私たちは、プラットフォームのユーザーをいかなる形でも制限しないように、Hadoop 上でカスタム環境を実行する方法を学ぶという野心的な課題を自らに課しました。

さらに、多くの DS スペシャリストは数学と統計に優れ、クールなモデルを作成しますが、ビッグ データ変換にはあまり精通しておらず、トレーニング サンプルを準備するためにデータ エンジニアの助けを必要としていることが判明しました。 私たちは同僚を助け、Spark エンジン上のモデルの標準変換と機能の準備に便利なモジュールを作成することにしました。 これにより、データ エンジニアが新しいデータセットを準備するのを待たずに、モデルの開発により多くの時間を費やすことができます。

当社では、Linux と DevOps、Hadoop と Spark、Java と Spring、Scala と Akka、OpenShift と Kubernetes など、さまざまな分野の知識を持つ人材を雇用しています。 次回は、モデル ライブラリ、モデルが社内でライフサイクルをどのように通過するか、検証と実装がどのように行われるかについて説明します。

出所： habr.com