Sberbank Technologiesの特別プロジェクト：銀行がHadoop、Spark、Kafka、その他のビッグデータを準備する方法

私たちは皆、おそらく銀行に住んでいるJavaの密な遺産を笑うのが大好きです。 この記事を読んだ後、このストーリーの別の側面を理解することができます。 特にSberbank Technologiesには、ビッグデータや機械学習など、画期的なテクノロジーや分野に関与する大規模な部門全体が存在することがわかりました。 さらに、まもなく、ほとんどすべてのコーヒーマシンにMachine Learningが組み込まれた世界に出会うかもしれません。 良くも悪くも、すべてのATMから千の目で私たちを見ているモノのインターネットは、この古いジョークのはるかに適切な読書です。



お気づきかもしれませんが、私はHabréで仮想マシン、OpenJDKの内部、JVM、その他のシステム開発について書いています。 銀行業ソフトウェアに関するこの記事はなぜですか？ かつてないほど関連性が高いからです。 想像してみてください。あなたは非常に白く、2倍のデータサイエンティストであり、4倍の重要なJITコンパイルの達人です。 次は？ 誰が今ここでこれをすべて必要としますか？ 多くの場合、「今、あなたはお気に入りのJavaをいじくり回しています。明日は誰もあなたを雇うことはありません」というトピックについての推論を耳にします。 これは非常に面白くて危険な誤解です。 この記事で説明するこのような仲間のおかげで、私たちは常に仕事をすることができます。



もちろん、誰も私の言葉を受け入れてはいけません。したがって、特にハブルにとって、私はモスクワに飛行機を取り、Sberbank Technologiesの特別プロジェクト開発部門の責任者と話をしました。 Vadim Surpinは私に1時間以上を費やしました、そしてこのインタビューでは私たちの会話から最も重要な考えだけがあります。 さらに、Vadimを説得してJBreak会議への参加を申請することができました。 さらに、Vadimは、Habrへの招待に値するように思われた最初の人物であるvadsu （招待はChromeDriverのハッキングに関する記事で正直に獲得されました）。




-Habréの読者にあなたのチームについて少し話していただけますか、あなたは何をしていますか？



-ビッグデータのコンピテンスセンターがあります。 したがって、Hadoop、それに近いもの、およびビッグデータの処理を可能にするものすべてに取り組んでいます。 Hadoopに加えて、これらはキーバリューリポジトリ、分散テキストインデックス、Zookeeperの補助コーディネーター、 ImpalaのようなHadoopの軌道からのMPPソリューションです（本格的なMPPと呼ぶことができる場合でも、そうであると主張しています）。 これは、もちろん、Spark、Kafka、その他の一般的なものです。 それは技術的にです。

理論的には、Hadoop for bankは、大量の内部および外部の銀行データを処理できるプラットフォームです。 会議では、彼らはしばしばSBSについて話します。これはトランザクションシステムです。 Hadoopは分析システムです。 PPRBはより多くの最新情報を処理し、Hadoop-情報の履歴量全体を蓄積します。 これはトランザクションデータであり、ある種のクライアントデータ、アカウント、オペレーションです。 これは個人および法人に適用されます。 たとえば、企業で使用するSpark Interfax、クレジット履歴のソースなど、多数の外部データがあります。 このデータはすべてHadoopに集約され、顧客プロファイルを構築し、マーケティングキャンペーンについて小売業者の意思決定を行い、顧客の流出の可能性を計算します。 ユニットの作業スケジュールなど、さまざまなスケジュールをインテリジェントに構築するため。 最近、Google Playのレビューに基づいてSberbankのモバイルアプリケーションの障害を特定できるモデルを構築しました。つまり、任意のテキストの分析を開始しました。 画像分析で実験しました-これは、ビデオまたはカメラからの写真によって銀行のクライアントをより適切に判断するために必要です。 銀行にはこれらの分野の多くがあります。



さらに、他の銀行システムと統合する必要がある場合、インフラストラクチャがハードコアになります。 WAY4、SmartVista、またはCENでリアルタイムモードで大量のデータをダウンロードする必要がある場合。 つまり、これはビッグデータと高負荷の組み合わせです。 これは興味深い純粋に技術的な問題を引き起こします。 通常、すべてのカンファレンスで、ビッグデータと機械学習はまったく同じものであると言うのであれば、ここではそうではありません。 エンタープライズプラットフォームを構築する過程で、多くの純粋に技術的な問題があり、それらはそのままではビッグデータの世界では解決されないことに気付きました。 特に、Hadoopで実際のデータのストリームを取得するのは簡単なタスクです。 しかし、1時間あたりわずか数テラバイトのサイズのストリームでは、単純なものから別の大きなタスクに変わります。 Hadoop上のデータへのリアルタイムアクセスの提供は、ターンキーソリューションではあまりカバーされていない別の領域です。



-待って。 Hadoopはもともとリアルタイム用ではありませんでした。 そのバッチ処理ではありませんか？



-ビッグデータは非常に興味深い発展を遂げました。 最初は、多数のサーバーにデータを分散するだけでした。 そして分析システム-建物プロファイルなど すべては検索、サイトのインデックス作成から始まり、本当にオフラインです。 現在、これは多くの出版物で見られるように、情報のストリーム処理にますます移行しています。 リアルタイムに近いです。 ビッグデータについて話すとき、ログの処理、つまりテキスト情報のトピックは常に浮かび上がりました。 Elastic、Solrなどの分散インデックスがあります。 これもビッグデータですが、リアルタイムです。 つまり、ビッグデータが必ずしもバッチであるとは言いません。



-うん。 そして、Hadoopでリアルタイムにどのように対処しますか？



-リアルタイムをストリーム処理とリアルタイムアクセスに分割します。 リアルタイムアクセスとはどういう意味ですか？ データをバッチで処理し、それらへのポイントアクセスを提供できます。 基本的に、これらはKey-Valueストレージであり、Elasticのような上記のテキストインデックスです。 これらは最終的な陳列ケースとして機能します。 全文検索の場合、このようなディスプレイケースへのアクセスは、事前に選択されたキーまたはキーセットによってのみ実行できることは明らかです。 ご存知のように、エンタープライズ環境では、多くのお客様がデータへの正確なSQLアクセスを求めています。



-/ *ため息が重い/ *



-はい。 さらに、このデータはNoSQLデータベースにある場合もあります。 そして、ここであなたはそれをする方法を考えなければなりません。 もちろん、これに対する完全な解決策はありませんが、メモリ内のさまざまなキャッシュのために、同じインデックスの編成のために、多かれ少なかれ一般化されたものを構築しようとしています。



-そして、結果はある種のフレームワークになりますか、それとも問題の場所でのアドホックなソリューションですか？



-それは、フレームワークを実行しようとするポイントです。 一般に世界で起こっていることを市場で見ると、一般に、 Strataのような大規模な会議で、人々が「ローカルに」決定を下すことは明らかです。 銀行では、DKAの存在下で...



-コーポレートアーキテクチャ学科？



-はい。 DKAの存在下では、何世紀もの間、石に彫りたいという欲求が常にあります。 したがって、多かれ少なかれ一般的な決定を下す方法を見つけなければなりません。 SQLとNoSQLの2つの異なる世界を横断することは常に可能というわけではありませんが、多少の一般的な決定をしようとしています。



-それはどれくらい生きますか？ 1年、2、3、10年？ あなたの計画は何ですか？



-質問は興味深いです。 私たちが話していることを見ています。 とにかく、ビッグデータ技術は非常に急速に進化しています。 データストレージ、バッチ処理に関連するものが多かれ少なかれ確立されているように思えます-それらはわずかに長い寿命を持っています。 より新しい方向、同じストリーム処理、リアルタイムに関連するすべて-ここでいくつかの乱れがあります。 これらの決定は、今後数年間でさらに手直しされる傾向があります。



-そして、どの正面が最も前進しているのでしょうか、やり直しますか？



-現在、「データクラウド」のプラットフォームに取り組んでいます。これは銀行のHadoopの名前です。 「クラウド」という名前は、私たち自身にとって最初は奇妙に思えたと言わなければなりません。 「クラウド」は、OpenStack、Amazonなどの有名なクラウドプラットフォームであるためです。 したがって、Hadoopは「クラウド」ではないようです。 さらに、Hadoopは当社のハードウェアで作成されています。 「AS Data Cloud」という名前は、「サービスとしてのデータ」と理解する必要があります。 インフラストラクチャ自体がクラウドではなく、データはクラウド内に存在し、サービスとして顧客に提供できます。 現在、ビジネス顧客にとって最も人気のある部分は、すべての銀行データを1つのプラットフォームで利用できることです。そのため、実験を実施し、データを扱うラボを持ち、データを統合することができます。 つまり、1つのクライアントに関するデータ、異なるソースからの1つのイベントに関するデータを比較します。 これは私たちにとって最も難しい仕事です。 データの取得とデータの統合は古典的なストレージタスクですが、Hadoopでも発生します。



次の前線。 データが十分な量になったら、そこから何らかのビジネス結果を抽出する必要があります。 これらはさまざまなパイロットとデータ実験です。 成功した実験に基づいて、Geomarketingなどの多くの自動化システムが開発されています。



-データのマッチングについて-それは迷宮ですか？



-いいえ、ラビリンスはグラフプラットフォームです。 事前にパッチされたデータのグラフ表現を吸収します。 つまり、マッチングはラビリンスの一部にすぎません。 グラフ化のためのデータ準備の一部。 言い方すらわからない...これはラビリンス全体ではありませんが、それは非常に重要な部分です。 グラフは、さまざまなオブジェクト、主題、現象間の関係を識別するのに役立ちます。



-順番に来てください。 迷宮はプロジェクトの名前ですよね？



-一般に、プロジェクトはコード名U1で始まりました。



-U1？ 飛行機の名前のように聞こえます。



-当初、このプロジェクトの顧客はURPAの部門でした。つまり、問題資産を扱う部門、つまり、ローンを支払いたくない人を探す部門でした。 したがって、文字「U」と「1」-URPAの最初のプロジェクト。 そして、これはこの顧客だけでなく適用可能であることに気付きました。 しばらくして、「Labyrinth」という名前がお客様から生まれました。 なぜまさに迷宮なのか？ 今言うのは難しいですが、 おそらく人と組織間のつながりのグラフがグラフィカルインターフェイスで歩き、ナビゲートし、新しい関係を開くことができ、迷路の中で道を見つけるようなものでした。



「それもかっこいいですね。」



-はい。 このシステムには他の名前もありましたが、迷宮が定着しました。



-どのビジネスシナリオで解決できるか、詳しく教えてください。



-当初、ビジネスシナリオは大規模な経営者の検索でした。 複数の企業が互いに独立しているように見える場合、興味深い金融スキームがあります。たとえば、ローンを取り込んだ後、一瞬で消滅します。 まあ、彼らの間の何らかの種類の相互作用のために、このお金はスクロールされ、どこかに奪われ、すぐに消えます。 同時に、これらの企業間の関係は表面上では見えませんが、外部の追加データを使用することで、企業が疑わしいエンティティのコングロマリットであるというリスクを検出して強調することができます。



-隠し持ち？ イノポリスのスライドを覚えています。



-はい。ただし、「隠された保持」は別のシナリオです。 そのような共通のリーダーの検索が、興味深い種類の詐欺、詐欺を明らかにする可能性が高い場合、「隠された持ち株」は別のシナリオです。 ご存知のように、Sberには多くの顧客がいます-個人と法人の両方です。 トランザクションに基づいて、いくつかの生産チェーンを発見できます。 たとえば、企業がサービスに対して定期的に相互に支払い、事実上、事実上の保持を形成する場合、それらは正式ではありません。 そして、そのような生産チェーンを見つけた場合、このグループの企業は持ち株に便利な特別な企業向け製品を提供できます。 これにより、システムの観点から完全に独立した企業である場合よりも、遅延、少ない遅延などで、相互間の決済をより速く、より便利に行うことができます。 これは肯定的な使用法です。 企業がSberのサービスをより便利に使用できるようにします。



-これは会社の観点からどのように起こりますか？ ある朝、Sberbankの従業員があなたに電話し、「あなたは同じチェーンで働いていることがわかりました！」と言います。



-残念ながら、これはこういうことです。私には言えません。 このビジネスが実際にどのように適用されるか、会話スクリプト-残念ながら、私は知りません。 推測することしかできません。



-つまり、ビジネスに情報を提供するだけです。



-はい、情報を提供します。この情報に基づいて製品を販売する方法は、ビジネスユニットのタスクです。 クライアントマネージャーが人とよく発達した関係を持っている場合、人に何を尋ねるかを知っていれば、いつでもそのトピックについて会話をすることができます。



-このシステムのユーザーの観点から、このようなチェーンが検出されたときの応答の結果はどのように見えますか？ チェーンアイテムをリストしたテキストファイルが生成されましたか？



-いいえ。 これはグラフィック画像です。 通常、特定の会社が描かれ、その周りには相互接続された顧客のクラウドがあります。 大企業のクライアントに対して同様のタスクを検討する場合、どこから来て、どの会社であるかがすぐにわかります。 私たちは最大の顧客を引き取り、彼らが契約している請負業者を探します。 大規模なクライアントの活動のタイプを知っていると、各生産チェーンの方向を簡単に考えることができます。 誰が何を彼に、誰に何のサービスを提供するか。 グラフィカルに、それはクライアントのように見え、その周囲にはそのような発散する光線があり、これらはカウンターパーティです。 したがって、彼らは通常、大規模な顧客から始めて、フィルターを通ります。 そして、それらからさらにすべてのチェーンが展開します。



-これは単なるスナップショットですか、何かを時間内に追跡できますか？ 会社の成長なのか、逆に会社の崩壊なのか？



-これはわずかに異なるタスクです。 隠された持ち物を見つけるために、最初の段階では、履歴情報はそれほど重要ではありません。 関連する情報だけが重要です。 履歴情報による顧客とクライアントのステータスの追跡は、わずかに異なるプロジェクトです。 彼は現在、商業運用ではなく開発中です。 これは「ニュース監視」プロジェクトです。 ニュースソースをテキストとして処理し、顧客に関連する重要なイベントを発見しようとするとき。 たとえば、ニュースで組織の裁判に関する情報が大量にある場合、これはそれぞれのクライアントマネージャーが財務状況などを詳しく調べる機会です。



-それで、たくさんのプロトタイプと実験がありますか？



-はい。 実際、ビッグデータプラットフォームは、多くの実験が行われているような方法で開発されています。 古典的な企業である銀行ソフトウェアは、次のように開発されています。ボックスを購入し、機能を実行します。これらはすべてクライアントに提供されるだけです。 ビッグデータの動作は少し異なります。 ここで、私たちは実験室でこれらの機能を見つけようとしています。これらの機能に基づいて、後で内部使用のために特定のボックスを作成できます。 それ自体で箱を作ることはより長いプロセスですが、多くの場合、実験の結果に基づいて、ビジネスは今すぐ利益を得ることができます。



-誰がこれをしているの？ このスタッフは研究者、開発者で構成されていますか？ またはその逆に、3分の2がアナリストであり、2人のプログラマがいますか？ どのように見えますか？



-実験については、ここで大部分の人々はアナリストとデータ科学者であり、プログラマーは少し少ない。 つまり、開発者は、たとえばアナリストやデータサイエンティストが自分では処理できない非常に大量のデータを処理する必要がある場合に、実験のプロセスに関与します。 しかし、研究と関係は分析とデータ科学者です。 そして、これらは必ずしも私たちのユニットの従業員ではありません。 多くの場合、これらはビジネスブロックの従業員などです。



-データサイエンティストは、作業中にどのツールを使用しますか？



「彼らは、Python、Jupyter Notebook、すべてのデータ科学者が世界中で使用する多数のpythonライブラリを好む傾向があります。」 ビッグデータに関しては、PySpark（Apache SparkのPython API）、Hive（データを準備するため）です。これらは非常にカスタムの興味深いソリューションです。 たとえば、Spark内でxgboostを構築し、それを分散して実行しました。 すぐに使用できるSparkの機械学習ライブラリは良好な結果をもたらしましたが、xgboostは小さなデータでより適切に機能しました。 私は2つの世界のベストを取りました。



-それで、あなたはどんなツールでも使用できますか？ いくつかのツールセットがインストールされていませんか？



-2つの環境があります：実験室（新しいツールを導入しやすい）と産業用回路（新しいツールを導入するには実証プロセスが必要です）。 動物園に新しい獣が必要な理由を建築家に示す必要があります-実験室では簡単で、ウエディングではやや複雑です。 しかし、もちろん、技術の悪循環はありません。 私たちは状況を見ようとします。



-そして、アーキテクチャの観点から、誰がそれを定義しますか？ たとえば、ビッグデータソリューションのアーキテクチャは？



-アーキテクチャを描く企業のアーキテクトがいる場合、ここには伝統的な組織構造があり、これはさらに実装する必要があるようです。 もちろん、実際には、ビッグデータで何かが絶えず変化していること、トレンドが絶えず変化していること、何かが背景に追いやられていることを考えると、これは必ずしもそうではありません。 本当に掘り下げてみると、ある時点でmap-reduceは、プログラマーが直接使用するテクノロジーとしてレーダーをほぼ完全に残しました。 実際、企業のアーキテクトは、当社の能力の中心にいるアーキテクトやチームリーダーと緊密に連携していることがわかりました。 概して、多くの決定はチームリーダーのレベルで行われます。 最初はチームリーダーが開始し、関心のある人々と徹底的に話し合います。



-そして、コンピテンスセンターとは何ですか？



-これは特定の技術に焦点を当てた組織構造です。 たとえば、ビッグデータがあります。 PRPRには、グリッドゲインに関連するすべてのものがあります。 処理センター、CRMなどがあります。 — BI, SQL-. — : , .



— , , - Agile-?



-はい。 , , . . , , , , . «»… , , IT, . , , .



— . ?



— , ?



— , ( ). - ? -, .



— . , , , , . , — , , . , , : , , , , , , .



. — , . - , -, . — , , . , , , , , - . , , . , , , , . . , - …



— , .



— , , - . , . - ( — ) , -. . , (, , ), , , , - .



— - ? , , -?



— , — . - , . , , , , - . , , . . : , , -. — , , — .



— ?



— . — , - , . , - , .



— ?



— . . - , , , — , , . , . — -, . , , .



— — . , ?







— — , . , Big Data- , . , . , open source, . , . , ? . , , , - , , — . . - … . , . , — . . , . , , . (, , , ) .



— . . - ?



— , , . , - - . .



— ?



— , TigerGraph . , , , . , . . , , — , - .



— , , .



-はい。 , , , — , , , . - . . , — GraphX , Giraph , . , Hadoop, , . , , , , . .



— , ?



— . , — . . . « »? , : , — . , . , , :-) — , — .



— ? ?



— . ID, , . .



— . , , , ?



— , , . , . . , , , — .



— , ?



— . , Elastic Solr ( Elastic, — ), key-value (assandra HBase, ) , .



— - Java API , ?



— API, . . , , . , - -, . «». , — . , . , . , 10-20-50-100 , , . UI — .







— UI JavaScript ?



— JavaScript, .



— ?



— D3 . , . — , , . , , , , . . D3 — , - , . , . , , , , , .



— ? Java- -, ?



— , . , , , , - , . , , — .



— , , — .



— , , . — . - , . , , .



— . « 2.0»?



— — , , — , . — , , . . , ( ) , , . — - , , . , , - , , . , , , — , , , -? , , , , . . — .



— . ?



— ? , , - - , . — . (, , ) , , , .



, , , . , - . , . , , , . , , …



— — , .



-はい。 , , , . , — . , , — . , — , , , . — .



— -?



— . , , , . , , , . , , . .



— , , — ?



— — , .



— , .



— . , — , . , — . , , . , , , . - , . , . .



— , , - ?



— , ? , . , . , . , .



— .



— — -. : , , , .



— , ?



— , Big Data, - . . . , - , , . -, . Hadoop. — , .



— ?



— , . - , — . , — — , , . , . , - .

— . , , — . . — , - , . -, - . .



— ?



— - . , , . . , — . .



— , , ?



— , — Hadoop, — Spark . , — Leaflet , ( ). , , , .



— , , ?



— , . , - , -, . - .



— — - ?



— , . — , , . - , , , . , . , , -.

, … - — . - , , , , , , - . .



— - , — ? …



— , . , . : , , — . , . -. , . , . . -.



— , , . , ?



— , , , , . ? open source. , enterprise, , , , open source- — IT.



— , ?



— , . IT, - . . , — , , , IT- . , IT . , .



? , Big Data — , , , . , ad-hoc. , - , — . , , . . , . , — , .



Hadoop , , . SQL- Hadoop, , , . SELECT , - , , , . — . , , — realtime- Hadoop. , , , . , IT-, — Hadoop. — Big Data . , . , - .



— , — . ?



— , , . — , . . . , . , , , , . — . .



— - , - ?



— . realtime- Hadoop — ? . Hadoop — , batch, , , . , , .



, . ( - ) , , , . .



, — Hadoop. — - , , HDFS, — , ! ? , , - . . source control devops stack.



— , , ( - )?



— , , Java-, . . , , , — , . , . , , SQL, . — data scientist. , ( ) . , . — . , — , - . , .



— -.



— . , -, .



— -?



— , , Hadoop, Spark, Hive, , — HBase, Cassandra, Solr, Elastic , Hadoop. , Java — . . — ( - Hadoop ).



— . , , — . - SmartData. — JBreak JPoint . , !