これは、ドイツ銀行テクノロジーセンターのアントンバティアエフとのインタビューです。 金融数学者が何をするのか、銀行からのデータはどこから来るのか、どのように処理され最適化されるのかについてお話します。 金融セクターへの参入の難しさ、証券取引所での取引、銀行の一般的なニーズ。

あなたは銀行で何をどう思いますか？

-自己紹介をお願いします。あなたが誰で、何をしているのか教えてください。

今年の1月上旬にドイツ銀行TechCenterに移り、現在、世界中のさまざまなトレーダーやこのデータを必要とする他のチームのさまざまな種類の金融商品リスクを考慮したプロジェクトでサーバー側を開発しています。

このプロジェクトは、多くの一般的な標準フレームワークである非リレーショナルデータベースを使用するかなり大規模なインフラストラクチャを構築し、Kafkaのビッグデータを処理します。 また、数万個のCPUのグリッドで作業し、さまざまなカスタムプロジェクトを使用し、protobufで作業を最適化し、金融数学に計算を実装し、

インフラストラクチャの一部として、いくつかの追加の最適化とチップがあります。 おそらくこれは明らかかもしれませんが、銀行で何が起こっているかを一貫して論理的に伝えることは非常に困難です。数パーセントがそれを投げ出して財源を得ました。これは複雑な数学、アルゴリズム、大規模インフラストラクチャ、技術および最適化タスクです。

-順番に来てください。 TechCenterでは、グローバルバンキングプラットフォームの計算を行っているとおっしゃいました。 しかし、銀行では何が考えられますか？

私の経験に基づいて、投資活動の枠組みの中で、価格とさまざまな商品の他の多くの指標の両方が考慮されます。 株式について話すと、すべてが明確です。相場はその価格です。 債券の場合、これは額面の割合になります。

デリバティブ（デリバティブ金融商品）について話す場合、価格はこの商品に支払わなければならないプレミアムのサイズです。 それは多くの異なる式で計算されます。 オプションの価値を見積もるブラック・ショールズ式があります-これは、現在の相場、原資産、ボラティリティ、満期までの時間、および他の多くの要因の関数に依存する関数です。

トレーダーのポートフォリオの価値を計算できるモデルがあります。 部門または会社には、一連の取引、ポートフォリオ内のデリバティブ金融商品があり、現在の費用を計算する必要があります。 それとは別に、1つの価格がありますが、合計すると、何らかの形で相関し、割引を与えることができます。 たとえば、合成ポジション：オプションの先物と同等のオプションを作成する方法。 これは、たとえばオプションなどの非線形資産に適していますが、必ずしもすべての種類のデリバティブに当てはまるわけではありません。 評価は、デリバティブが構築される原資産の見積に基づいています。 たとえば、1つ以上の通貨ペアの引用。 デリバティブはさまざまな原資産に基づいて構築できます。通貨の場合、原資産はユーロ、ドルなどになります。 コモディティデリバティブ-オイル、金、小麦; スポット用-さまざまな株式と債券。

デリバティブの評価に加えて、リスクも考慮されます-市場価格がより激しく暴騰した場合に何が起こるか（ボラティリティの変化）。 または、ドルの費用が1つではなく、他の1つまたはすべての通貨に対して100通貨すべてにかかる場合はどうなりますか。 特定の商品、ポートフォリオに何が起こるか。

これをリアルタイムで計算し、ポートフォリオの現在の状態を、各通貨の価格変動のさまざまな悪影響、市場のボラティリティの変化に近似させる必要があります。 これを行うために、現在の状況、明日、市場危機が発生した場合に何が起こるかを示す、考えられるすべての変更のマトリックスを構築しています。

これは、現時点で何を売買し、どのようなリスクがあるかを評価するために必要です。 また、今後何が起こるかを評価し、取引戦略を評価し、市場の変化により正確に対応します。 たとえば、クォンタムの1つは、リスクを計算するための新しいアルゴリズムを考案しました。たとえば、過去数十年間のすべての交換情報を履歴データで確認し、何が起こるかを確認する必要があります。

これらのニーズに対応するため、市場データを当社に送信するさまざまな交換プラットフォームに接続されたインフラストラクチャがあります。 弊社には世界中に多くのデータがあるため、事前集計を迅速に処理するには、何らかの方法で事前集計を保存および構築する必要があります。

-インフラストラクチャの部分に移る前に、あなたがすでに言ったことについてお聞きしたいと思います。 あなたはあらゆる種類の分析アルゴリズムの束について話しましたが、これらのアルゴリズムはどこから来たのですか？ これは何らかの書籍の知識ですか、それともベストプラクティスですか？

いくつかのポイントがあります。 まず、よく知られた数式、数学者によって発明されたアルゴリズムが採用されます。 たとえば、一般に受け入れられているオプション価格設定モデルは、Black-Scholes式です。 しかし、これに加えて、内部改善があります。特に、価格分布の他の法則を使用し、これらの式の係数をひねります。 価格、取引、およびその他の指標の分布曲線の式は大きく異なる場合があります。

最適化について話す場合、これらはすでに内部的な改善です。 たとえば、開発者は各ポイントでインジケーターを計算する代わりに、キー値を計算して概算を行うことができます。これにより、コンピューター時間が20分の1になりますが、同時に許容できる十分な精度が得られます。

すべてのデータは絶えず変化しています。これは、レポートだけでなく、トレーダーに市場状況の最新の状況を提供するためにも重要です。

-これは非常に複雑な情報であり、おそらく人から人へ転送することはおそらく非常に困難です。 チームの規模はどのくらいですか？また、どうやって知識を交換しますか？

モスクワでの私たちのプロジェクトは35人を雇用しています。 これらは、UI、バックエンド、インフラストラクチャ、金融数学などの特定の機能を扱う複数のチームです。 このような各チームには、特定のモジュールの機能に関する深い専門知識があります。 しかし、これらの人々のほかに、私たちのプロジェクトに関連するシステムに関与している多くの人々がいます。

プロジェクトに関するすべての情報はConfluenceのアナリストによって記述され、標準メカニズムとパブリックフォーミュラへのリンクがあるJIRAタスクの説明にも含まれています。 機能の使用例は、テストで見つけることができます。 まあ、人間のコミュニケーションはキャンセルされていません。

-金融数学者：そこに何人いますか？ 重要な科学者はいますか？

はい、彼らは主にロンドンに座って市場がどのように機能するかの金融モデルを構築する専門家（量子）です。 ほとんどの場合、彼らは金融または数学の博士号を持っています。 彼らは、市場がどのように機能するか、トレーダーが何を必要としているかを知っており、市場の状態、リスク計算アルゴリズム、デリバティブの正しい評価を記述する何らかの数学的モデルを考え出すことができます。

たとえば、私の同僚のアレクサンダーはHabréに関する記事を書いており、彼はすでに量子の経験について言及しています。

-通常の開発者は彼らと通信できますか？ このコミュニケーションはどうなっていますか？ 実際、数学と従来の開発にはまったく異なる世界があります。

彼らはコミュニケーションとコミュニケーションができます：いくつかのトップレベルのビジネスタスクと概念がリーダーと議論されていることは明らかですが、特定のリスク計算またはその他の指標の枠組みでは、開発者はこのモデルを構築したトレーダーまたはクォンタムと直接通信します

しかし、実際には、これは相互作用の相互プロセスです。理論的なアルゴリズムが実際に常に実装されているわけではないからです。 したがって、開発者は、現在のアプリケーションアーキテクチャに適合するようにモデルの変更を提案できます。

対話するには多くの方法があります-同じSkype、電話、すべて標準のコミュニケーションツールです。

-結果として出てくるソフトウェアは自動ですか？ これらのロボットはありますか、それともテクニカル分析に携わっているトレーダーのために何かありますか？それともチャートですか？

ソフトウェアを使用するためのいくつかのオプションがあります：最初のオプションは自動です。 トレーディングロボット、2番目はトレーダーのアシスタントであり、ポートフォリオの現在の状態を表示し、さまざまな指標でのリスク、現在実行可能な取引のオプション、ポートフォリオの将来の状態、およびこれらの操作の結果に基づくリスクを詳細に示します。 トレーダー向けの指標、リスク計算、ポートフォリオの状態に関するデータもあります。

-もう1つの指標は、データ分析の頻度です。どのくらいの頻度で分析しますか？ 私が理解しているように、スペクトルの一方の側では数マイクロ秒、もう一方では数週間かかる可能性のあるビッグデータの分析です。

インジケータの複雑さと重要度に応じて、これらはライブインジケータになる場合があり、ティックごとに再計算されてからミリ秒単位で計算されます。 そして、ポートフォリオのコストを計算すると、更新が1秒に1回行われるため、人間の目でそれを知覚する時間があります。

長い計算（たとえば、いくつかの複雑なリスク）、日中に必要なデータを記述する場合、タスクはグリッドに送信され、通貨相場を変更するシナリオが考慮されます。 一般的なメカニズムは次のとおりです。特定のサイクル内のすべての新しいトランザクションを検討してから、グリッド上で困難なタスクを実行して、現在の市場状況のトランザクションセット全体のインジケーターを再計算します。

このようなタスクは、1時間に1回更新できます。 取引戦略を追い払う必要がある場合-これは長いタスクであり、投げられ、数時間は複雑さとデータの量に応じて考慮されます。 グリッド上のタスクは、たとえば、1つの式を計算して1つの結果を出すなど、非常に小さくすることも、たとえば、考えられるすべてのリスクシナリオの相関を計算して組み合わせた結果を与える必要があるテーブルの場合は大きくすることもできます。

グリッドの負荷を最適化し、機器の種類、データの量、その他の指標に応じてタスクの計算時間を予測して、負荷を最大にするタスクが表示されます。 なぜなら、1つの大きなタスクを投げると、他の全員が並んで待機するからです。

一般的に、バックパックと他の最適化のタスク。 グリッドへのpingが計算時間自体よりも長い場合は、バックエンドで実行します。バックエンドでは、このような小さなタスクのためにミニクラスターが既にデプロイされています。

-なんらかの形でそれを配置できますか？ 私の知る限り、タスクの量に応じて異なる最適化方法が使用されます。 小さなタスクでは、JITコンパイラーを最適化し、大きなタスクでは他の何かを最適化するのが理にかなっています。 問題の領域と、加速と最適化のためにそこで使用されている方法を教えてください。

大きなタスクの例は、各通貨の相場を1-2-3-10％変更する際のすべての金融商品とリスクを計算することです。 この場合、最適化は、トランザクションをバンドルにグループ化して、1つのバンドル内に1つのタイプのポートフォリオまたは1つの通貨のトランザクションがあるようにします。

各トランザクションに多くのリスク計算がないように、それらを大規模な1つのトランザクションとして提示し、結果を比例的に分割します。 したがって、必要な計算の数を減らします。

別の最適化の例として、今回は通貨ペアを使用します。 「ルーブルドル」と「ルーブルユーロ」の2つのペアがあるとします。 最初のペアでは、ルーブルが下落していることを想像できますが、ドルが上昇している可能性があります。 実際、これはまったく同じです。 ルーブルとユーロのペアについても同じことが言えます。 したがって、両方のケースでルーブルが変化することに基づいて、1つのパックで一見異なるペアを考慮することができます。

計算の数が減り、結果が加速されます。 1つの通貨（この例ではルーブル）が変更されたようですが、実際には、異種資産のリスクを計算しました。

-そして、問題を真正面から解決し、それを巨大で巨大なクラスターに展開できますか？

そのようなクラスターがありますが、既に多くの計算がロードされています。 現在数万のCPUが存在するにもかかわらず、クラスターはゴムではありません。

-そして、ソフトウェアの観点から、In-Memory DataGridまたはHadoop？

はい、すべてを処理するHadoop、Kafka、およびビッグデータの処理を最適化するClickHouseデータベースがあります。 データのスタックに関しては、JSONを駆動することは、控えめに言っても非効率であることは明らかです。 この点で、Protobufで最適化の瞬間があります。 バイナリデータを配置するだけでなく、辞書を使用してできる限り厳しくすることが重要です。

それらには、たとえば、すべてのトランザクションに対して同じタイプの契約仕様を保存します。 辞書によるこの最適化により、同僚は占有メモリの30％を節約しました。

-これらのディクショナリは特定のノードにあり、複製されているか、中央ベースにありますか？

さまざまな方法で。 主に中央基地にあります。 また、多数の計算を使用してグリッドに転送する辞書があります。 インターネットチャネルはゴムではないため、大量のデータをドラッグしないように、できるだけコンパクトにしたいと考えています。

どのように機能しますか？ 計算タスクを必要なすべての情報とともにグリッドに送信し、重複を避けるために辞書にパックします。 内部にはすでにすべてのコンテンツがあり、追加のリポジトリに移動する必要はありません。 これにより、ネットワークトラフィックが節約され、計算の遅延が減少します。

-私の知る限り、銀行は過去のデータを分析しています。これは、ギガバイト-テラバイトあたり1つの巨大なデータです。 そして、単一のデータベースでのアプローチは機能しませんか？ キーに2 TBを配置できますが、それは良くありません。

はい、そのような瞬間は分割によって決定されます。 ニューヨークからシンガポールへのすべてのトランザクションに関する情報の送信はリソースを大量に消費するため、交換情報によってレイアウトされた国別のローカルキャッシュがあります。 ここでは、国による区分が論理的であることは明らかです。たとえば、米国での取引はアメリカのデータセンターに配置されます。 引用符を使用した同様の状況-ルーティングを構築し、それがどのような取引であるか、どのリージョンに属しているかを判断し、キャッシュの場所を理解し、必要なストレージとデータベースに送信し、データを再度追跡しないようにする必要があります

-そして、異なる地域のデータを結合する必要がありますか？

はい、それはあります、そして、それは難しい仕事です。 集約された結果を取得するために、すべてのリージョンからテラバイトのデータをポンプアウトしないことは明らかです。 ほとんどの場合、各地域でこの地域のローカル集計を計算し、これらすべての結果を収集して概要データを取得します。

-おそらく、交換履歴などの外部データがあります。 そして、それらをどのように扱うのですか？ あなたは自分自身をミラーリングしていますか、それともそれらを処理する方法はありますか？

プロトコルおよび標準データプロバイダーへの接続があります。ロイター、ブルームバーグは、交換情報を提供します。 必要なデータは内部ストレージに保存しますが、データプロバイダーから再要求できるものもあります。 繰り返しますが、地域ごとに、トラフィックを促進しないようにします。

また、速度とパフォーマンスを確保するために世界中にサーバーを展開していることは明らかです。

-そして、読み取りまたは読み取り/書き込み用のデータ？ 記録がそのような量を転がすのが怖くないなら？

基本的に、読み取りについては、トランザクションに関する情報や規制当局が必要とするその他の情報を記録しながら書き込みを行います。 基本的に、国内のニーズの計算：リスク、ポートフォリオの価値など。 これは内部キッチンであり、外部に送信することなく、一部の地域またはデータセンターのデータを引き継ぐことができます。

-破片が月を割ってデータセンターに飛んだ場合、どうなりますか？ 終わりましたか？

データセンターのデータはミラーリングされます。 リージョン内では、データが1つのデータセンターの1つのハードドライブに置かれていないことは明らかです。 そうしないと、その自転車のように、清掃中の女性が誤ってサーバーを切断する可能性があります。 すべてがオンラインでコピーされます。両方向のデータストリームがあり、最も近いミラーから読み取り、記録と同期して一貫性を確保します。

しかし、原則として、ユーザーに表示する必要があるため、記録に使用できる情報ははるかに少なくなります。 彼が今ではなく、2秒後に別のソースから再集計を見る場合、それは悲しいですが、あなたは生きることができます。 規制当局、外部のマーケティング担当者、および市場参加者に必要なデータは、何も失わないように複数のソースで複製および同期されていることは明らかです。

Tech Center Deutsche Bankがデータを準備してゴミを収集する方法

-データの準備に関する質問。 私の知る限り、各ソースには独自の形式があり、それらを即座に変換することはお勧めできません。 計算のために何らかの形で事前に準備していますか？

内部に単一の形式があります。 同じデータで作業する方が便利であることは明らかですが、これはそれらを変換する必要性につながります。 情報の交換、サプライヤへの接続を担当するデータストリームとチームがあります。 これらは、単一の形式でデータを形成および強化します。 パフォーマンスの問題を解決するために、2つのデータストリームがあります。そのうちの1つは、交換データストリームからの情報を提供する高速サイクルです。 このため、さまざまなストレージに移動して標準構造を形成する必要性は低くなります。 その上で、必要な指標をリアルタイムで計算できます。

そして、同じストリームを処理するより遅いサイクルがありますが、私たちのフォーマットでは、必要なすべてのフィールドのセットがあります。 計算がますます遅くなり、追加情報、フィールド、その他すべてが必要になります。

-開発者の観点からはどのように見えますか？ データベースのどの領域が重い計算の影響を受けるかを常に知っていますか？

いくつかのイベントが到着します。フィールドには、100％と部分的にのみ入力できます。 高速イベントでは、オンラインですばやく再計算されるインジケーターをカウントします。 データの完全なセットを使用する長くて遅いサイクルでは、すべてのインジケータを必要とするタスクを再カウントします。 これは、タスクの詳細にすべて依存しているため、深くしない場合です。

-そして、データは何に保存されますか？ HDD、SSD、RAM、すべてRAM

主にメモリ内。 必要なデータの速さと近さに応じて、Javaの標準構造またはインメモリデータグリッドのいずれかでデータを消費および保存するバックエンドで大きなヒープを使用します。 過去日の履歴データがSSDとディスクに保存されることは明らかです。 ただし、計算に必要なものまたは必要なものは、メモリ内のキャッシュにロードされます。

-キャッシュせずに、不正確な計算を使用して情報を失うことで何かを行うことは可能ですか？

はい インディケータが変更されたため、資産の変化のチェーンのリスクを0〜100％で計算する必要がある場合があることを少し触れました。 分布図は、式または線形関係に従って、パーセンテージとして構築されます。 キーポイントを構築し、近似を行います。 近似結果が得られます。これは、グラフの特定の各ポイントでカウントした場合、実際の値と100％一致しませんが、これらのデータを処理するには十分です。

このアプローチは、たとえば、他のすべての通貨に関連して各通貨の値を1ペニー単位で変更するときにすべての計算を実行できないため、よく使用されます。 まれなステップで移動するか、いくつかの特定のポイントを選択して、残りを補間します。 精度の値で十分です。

-それは常にJavaの大きなヒープですか、それともすべてオフチップですか？

主に腰にあります。

-それでは、ガベージコレクションにどのように取り組んでいますか？

ガベージコレクターの割り当てと頻度の標準的な監視に加えて、巨大なページなどの調整、適切なガベージコレクターの選択などの多くの操作を開始します。 たとえば、シェナンドーの使用を試すことができます。 一部のコンポーネントは、現象としてフルGCが存在しないことに基づいて構築および調整されます。

これは反復プロセスです：毎日、フレームグラフをライブで収集し、誰がリソースをどこで使用しているかを確認し、割り当ての頻度とそれらがドロップアウトするものを確認し、コード内のホットアルゴリズムをより最適なものに書き換えたり、計算全体を最適化したりします

-そして、どのようにメトリックを収集し、どのようにフレームグラフを作成しますか？

ツールキットには素晴らしいものは何もありません。情報を接続して収集するのは、私たちが作成したJavaエージェントか、標準のプロファイリングツールやその他のツールのいずれかです。 ELKスタックにイベントをラップするメカニズムがあります。GCの一時停止とメモリ消費インジケーターのメトリックアセンブリを含むログがあります。ヒープステータスのアンロード、ダンプインジケーターとその処理に対する手動または半自動の要求があります。 150 GBのヒップを削除して処理するには、特定のトリックが必要なタスクです。 同僚は、 150 GBのガベージを処理する方法と何が起こるかについて、Habrに関する記事を書きました 。 深く掘り下げたわけではないので、詳しくは説明しません。

-あなたのJavaとGCは何ですか？

Java 8、11日は現在いくつかのバックエンドでテストされています。 パフォーマンスを比較します。 ガベージコレクタとして、主にG1が使用されます。

-古いコレクターはまったくいませんか？

はい、新しいものを使用します。 さて、JVMキーでそれらをねじってください。

-私が理解しているように、ほとんどの作業は最適化、パフォーマンスに関連しています。 どういうわけか最適化をテストすることは可能ですか？これを自動的に行うことは可能ですか？

はい、できます。 テストループに接続して各インジケーターの計算を測定できる独自のテストフレームワークがあります。 私たちは、その作成に従事する専任のチームを持っています。 prodとyuateの速度を測定できます（UAT- ユーザー受け入れテスト ）-パフォーマンスが低下したかどうかを確認します。 数学の正しさ、クエリの頻度、実行時間を確認できます。グリッドを使用して作業を確認できます。 prodで2分間、yuateで3分間作業する場合、これが起こる理由を理解する必要があります。

テスト手順が自動的に開始されます。 2つの回路への接続が行われ、インジケーターが測定されます。その後、カスタムリクエストをスローし、異なるバージョンのセールの応答時間と遅延で結果を比較できます。 ガベージコレクションが動作し始める頻度などを比較できます。

-多数のコンポーネントについて話しましたが、システム全体をキャプチャするテスト、グローバル統合テストはありますか？ それとも、すべてのマイクロベンチマークですか？

これは包括的なインフラストラクチャです。 システム全体で実行されます。ヒープのサイズ、GCの応答時間、メモリ内のライブセットのサイズなどを確認できます。 ある種の複雑なこと。 このシステムの主要な機能は、計算パス全体に沿った数値のわずかな変化でもキャッチできることです。 実際、これが最後の防衛線です。 この巨大なシステム全体のどこにも予期しない変更を加えていないことを確信できます。

パフォーマンスデータは、特定のビジネス機能、いくつかの指標によって詳細化できます。 どれだけ早く、頻繁にカウントされるかをご覧ください。 カスタムリクエストを作成し、それらを異なるコピーで実行し、JSON diffを発行できます。 このJSONには、変更されたデータとパフォーマンスメトリックが含まれています。

これをすべて開発する別のチームがあります。 たとえば、さまざまな環境への接続、視覚化およびその他の機能のサポート。 これは内部開発です。

-若いまたは古い開発者が、システム全体が停止するほどパフォーマンスを損なうようなミスを犯す方法はありますか？

マイクロサービスを備えたモジュラーシステムを使用しているため、このような変更はすべてのアプリケーションに一度に影響を与えるわけではないため、これは機能しません。 ヒープが100 GB未満であるにもかかわらず、それらはあまり「マイクロ」ではありませんが、それでもそうです。 解決するタスクに応じて、サイズをわずかに小さくしたり大きくしたりできます。 システム全体に影響を与え、パフォーマンスを根本的に破ることはできないでしょう。

ボタンをクリックするだけで、バトルサーバーへの展開が開始され、すべてが展開されて回帰テストが実行された後、手動テストやその他のタイプのテストで問題を特定できます。 また、テストフレームワークが計算の正しい部分をカバーするだけでなく、パフォーマンス、メモリ、その他すべての作業もカバーしているという事実によるパフォーマンスの低下に気付くことができます。 投資活動では、決済の速度とそれに基づいた取引決定の採用が重要な役割を果たします。

結果に基づいて1日に1回アップロードされるフレームグラムでも、昨日は1つの結果があり、今日は完全に異なっていることがわかります。 どのコードが問題を引き起こすか、パフォーマンスの低下などがあった場所を理解しています。 明示的な論理バグを解決する標準テストとCIについては話していない。

-そして、金融数学のレベルでの論理的なバグはどうですか？

テストフレームワークを犠牲にして、指標の違いを比較します。 自身-十分な専門知識がある場合、または数学を発明したアナリストやクォンタムがあれば。 変更が正しいかどうか、なぜそうなのかを把握し、実際のトランザクションと合成トランザクションで実行して結果を確認します。 誰かが間違えた場合、それを修正し、再確認する必要があります。

財務バックエンドについて

-この巨大なシステムで何をしているかを思い出してください。
バックエンド-数学自体を実装するサービスを使用するシステム。 これらの条件付き計算機のリクエストを準備し、そこに送信し、リスク、ポートフォリオの価値、指標に関する回答を取得し、何らかの変換を行います。

比較的言えば、ある場所では、いくつかの機器のリスクのコストを計算する必要があり、別の場所では、1つの基本的なリスクに基づいてその変動を作成する、つまり、この結果をオプションに展開し、UIに送信してデータを表示する必要があります。 これは、計算データを構築し、最も困難な数学をすべて直接計算するシステムに行き、結果をUIに送信するようなバックエンドです。

-そこで使用されているテクノロジーは何ですか？ これらは純粋にあなた自身の開発ですか、それとも春のような「普遍的な」もので作業できますか？

Spring、Java、MongoDB、Protobufのような標準的なものがあり、依存性注入のさまざまな標準システムです。 Reactのあらゆる種類のUI、外部システムとのgRPCを介した相互接続によりデータを提供します。

-Mongoは聞いたが、Oracleは聞こえなかった。 本格的なリレーショナルデータベースなどをお持ちですか？

はい、ありますが、別の形式で使用されます。 バックエンドでは、交換情報の更新が個別のメッセージとイベントの形式で到着します。 また、以前の期間の一部のデータについてデータベースにアクセスする場合は、標準JDBCドライバーを介して接続します。 SpringDataなどの高レベルライブラリはなく、純粋なJDBCクエリだけがあります。 これは、パフォーマンス、コンパクトなクエリ、および高レベルのタスクに従来のフレームワークを使用して達成するのが難しい他のすべての問題です。

「CQRSをどこかで使ってみましたか？」

試しましたが、これは主に株式情報です。

安全から未来へ

-そして、最初に誰のために勉強しましたか？ プログラマー、数学者...

私は無事です。

-そして、どうやってこれに来ましたか？ 一度セキュリティを取った場合、降りるのは難しいです。

安全卒業証書は、私がセキュリティだけに関心があったとは言っていません。 私はそれを勉強しましたが、コーディングした最初の年からほとんどの部分で、C ++開発者の仕事を得ました。 彼は組み込みのGNU / Linuxでキャッシュレジスターを書いてから、Javaに切り替えました。 彼は標準的なバックエンドとビジネスオートメーションを作成し、ある金融会社の証券業界で働いていました。 デリバティブの計算、リスクの計算を実装しました。 彼は単純な開発者、リード、アーキテクト、部門長でした。 なんとかできました。

私は1月からここにいましたが、それ以前は約2年間金融数学に従事していました。

-どのようにして数学から単純な開発に投げ込まれましたか？

実際、金融数学を「単純な」開発と呼ぶことは困難です。 デリバティブ、リスク、またはその他の指標の評価を計算するアルゴリズムの実装に直接関与していない場合でも、何らかの計算に関与しています。 これは純粋なバックエンドだけでなく、バ​​ックエンドには「単純な」迅速な計算のためのミニクラスターがあると既に述べました。 つまり、基本的な数学を考慮したサービスに触れないという事実は、計算をまったく行わないという意味ではありません。

-この作品の何が面白くてかっこいいですか？

まず、財政を理解できること。 わたし
個人的には非常に刺激的です：金融数学、貿易、証券取引所など。 私は本当に指標を計算するのが好きです。 バックエンドで難しい数学を数えないことは明らかですが、とにかく、自分で標準的な財務事項を計算します。 これには特別な困難はありませんが、興味深いです。

これも大量のデータです。これは、バックエンドで150ギガバイトのバックエンドを使用する必要がないことが多く、バイト単位でパックする必要があるためです。 これらはパフォーマンス最適化の最適化のピースです。 ビジネスの数学、プロセスの本質に没頭することはエキサイティングです。

モデル、データストリーム、ジェットストリーム、データスタック処理。 データベースからテラバイトのデータをロードするのではなく、1つの簡単なリクエストで送信される蓄積された事前集計を取得するために、グリッドを読み込んでデータ事前集計を計算する方法-これは非常に興味深いです。 銀行ですべてがどのように機能するのか、なぜそれが必要なのか、そしてこのすべての背後にある規模を理解しています。

孤独なオオカミは銀行なしで取引できますか？

-普通の人や開発者が理解していない面白いことはありますか。それらを共有して人々の脳を吹き飛ばすことができますか？

最初に頭に浮かぶのは、アイデアの説明と財務計算のタスクの複雑さです。 特に一部のデリバティブを使用した取引所での取引は、単に取引端末から価格を取得し、ある程度の量を要求することを意味しません。 価格が正確かつ最新であるかどうかを判断する必要があります。 計算を行う必要があります。これは、積分で記述された2つのA4シートの数式です。

私がこの地域に来て、何かをプログラムし始めた頃の小さな話があります。かつて、1つのインディケーターの計算に精通するように申し出られました-積分と2次導関数を持つ2つのシートがあります。そして、あなたは彼らが大学で高等数学を教えた理由と、それがどこで役立つかを理解し始めます。

大学プログラムの問題は、実際の生活でこの知識が必要な理由が理解できないことです。そして、実際の生活では、これらすべての指標が実際に使用されていることがわかります。

「もし孤独なオオカミがこのすべての金融数学で銀行と競争することに決めたら、それはどれほど難しいでしょうか？」

« ». — , — , .

- - , , - . , , .

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

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

— ?

. , . , , .

— , , , - . , — , .

. , : , - , .

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

( , )

— , ? ?

, , Java. dependency injection, , , — , . , . . : , - .

, . , , , , happens-before. , , .

ご存知のように、 IntStream#distinctは、プリミティブをJava型でラップし、その後逆の操作を行うことが含まれます。 それほど怖くないようですが、大量のデータでは、大量のボクシングとアンボクシングが顕著になり、メモリが無駄に使用されます。 Javaの本質を理解する必要があります。ボクシングのような些細なことでは、不要な追加の割り当てを大量に生成できるからです。 また、これに間に合うようにするには、ツールを使用してパフォーマンスを評価し、メトリックを収集し、他の標準的な事項を理解できる必要があります。

-銀行の詳細を知る必要がありますか？

いいえ、基本的に。 私たちは皆、銀行の詳細を知っている人々がすでに銀行で働いていることを理解しています。 あなたが別の分野から来たとき、あなたは彼女を知らないでしょう。 最初に、一般的なポイントに関するドキュメントを学習できます。先物とは何か、オプションとは何か、どのように異なるのか、リスクは何か。 そして、あなたはただ飛び込み、ビジネスの詳細を理解し始めます。

ただし、それでも重要です。 最初は、特定のビジネスの特殊性に関連付けられていない機能を実装するだけで、より複雑で主題固有のことを徐々に学習できます。 ここにあるもの、最後の職場（私が部長として従業員を雇用したとき）-10人のうち少なくとも1人が未来が何であるかを理解していれば、これはすでに良いことです。

アルゴリズム、マルチスレッド、およびJava全般に関する知識があれば、ビジネスの詳細を学ぶことは難しくありません。 この環境に突入し、ドキュメントを読んで理解すると、それ自体が判明します。

-インタビューでJavaのこのような深い知識をどのようにテストしますか？ これは本当ですか？

それらをチェックしない可能性が高いことは明らかです。 しかし、ロジック、アルゴリズム、内部構造の理解に関する標準タスクがあります。 これはテストタスクであり、ホワイトボードコーディングです。 たとえば、候補者がマルチスレッドを理解しているかどうか、つまり競合、デッドロック、その他すべてを理解できるように、キューにキャッシュを実装するタスク。 途中で、それが消費するメモリ量、なぜHashMapではなくTreeMapについて質問することができます。 したがって、1つの一般的な問題を解決すると、さまざまな詳細から瞬間を調べることができます。 ここでは、むしろ、特定のニュアンスが計算される方法。

-プログラマーとしてより良くなるために何をする必要があると思いますか？

進化！ アルゴリズムの問​​題を解決するテクノロジーやアルゴリズム、新しい言語をコーディングして監視します。 実際、多くは経験に依存しています。 アルゴリズムに関する多くの問題を解決した場合、新しい未知の過去のタスクから類似のものを見つけることができます。 思考、迅速に答えを見つける能力を開発する必要があります。 StackOverflowでGoogleを検索して解決策を見つける機能は非常に便利です。 何かを知らないが、どこでそれを見つけるかを知っているなら、これが成功への道です。

言語は変化しており、テクノロジーとフレームワークは変化しています。 新しいパターンが登場しますが、誰もが使用するパターンがいくつか残っています。 Reactive StreamsについてのレポートとKotlinについての説明のないJava会議は、もはや通用しません。 に座って、ある意味では現在のイベントソーシングが徐々に世界を支配していることを理解していないのは奇妙です。

背景を開発する必要があります。 たとえば、Knutの本はまだ関連しています。 ベースと新しいテクノロジー。 そして、どこで何をグーグルするべきかを知る必要があります。

-彼が最後に理解したことは何でしたか？

コトリンコルーチンで。 かっこいい。 構文とロジックの両方。 マルチスレッドと非同期での作業方法を検討します。 以前は、Kotlinをほとんど使用する必要がありませんでした。 現在、私はそれを積極的に研究しています、いくつかのプロジェクトはすでにそれを利用しています。 prodのいくつかの小さなモジュールにも存在します。