SinoPac Securitiesは、台湾の経済ビジネスで4番目に大きな市場シェアを持つ大手証券会社です。外部ユーザーと内部従業員は、さまざまな電子プラットフォームを介してシステムにアクセスし、Web、モバイルアプリ、Windowsアプリケーション、B2B、B2CAPIなどのサービス要件を送信します。 、など。
現在、永豐証券の各電子プラットフォームのサービス需要の処理と対応は情報部が行っており、プラットフォーム上で同時にオンラインで利用できる最大人数は12,000人に達するとのことです。市場データの処理、着陸、再適用は最も厄介なビジネスです。
2020年3月23日、台湾証券取引所は、トランザクションマッチングメカニズムを元の5秒集中型マッチングシステムからマイクロ秒（100万分の1秒）のトランザクションマッチングシステムに変更し、全体のデータ量は元の2〜4倍に増加しました。 、ピーク期間中のデータ量は4〜6倍に増加しました。市場データの増加に直面して、SinoPac証券の元の業界処理システムはボトルネックになっており、新しいソリューションを探す必要があります。
パフォーマンス、スケーラビリティ、成熟度、包括的な所有コストなどを包括的に検討した後、SinoPacSecuritiesはkdb +、InfluxDB、Kafkaを放棄し、最終的に市場データシステムの基本プラットフォームとしてDolphinDBを選択しました。
1.直面しているビジネス上の問題点
ユーザーに対応するサービスを提供するために、SinoPac Securitiesのサービス構造は、ティックの保持と市場相場のクエリ、リアルタイムの時系列クエリ（K、日次Kに分割）、さまざまな市場情報のスナップショット、およびデータベースを提供する必要があります。テクニカル分析の。ただし、以前の市場データサービスアーキテクチャには、機能拡張の難しさ、パフォーマンスの低下、システム統合コストの高さ、トラブルシューティングの難しさなど、多くの問題があります。
過去の市場データのサービスアーキテクチャ図
- 機能拡張は容易ではありません
以前、SinoPacSecuritiesは市場データのランディングと再適用にC-ISAM / HDF5ファイル形式を使用していましたが、開発システムのサポートは良くなく（C / C ++ APIのみ）、サーバーバージョンの影響も受けていました。 （Solaris 32ビット）各ファイルの最大サイズは2GBです。市場データが到着すると、保持時間セクションに制限があります。さらに、ファイル形式のデータベーステーブルは、展開時に柔軟性が不十分になるという問題が発生します。同時に、ファイル形式であるため、各サーバーに過去の市場データのバックアップが必要であるため、ストレージコストが増加し、増加します。データ。不整合のリスク。
- 業績不振
SinoPac Securitiesは、パンダを使用して市場データを計算および適用します。同時実行性の高い顧客クエリでは、RedisTickはリサンプルによってコンポーネントKに置き換えられます。このプロセスには約1秒かかります。
会社にとって、このパフォーマンスは本当に悪いです。同社はさまざまなビジネスをさまざまなサーバーに分散させようとしましたが、残念ながら、それでも効率的なサービスと優れたカスタマーエクスペリエンスを提供できませんでした。
- 高いシステム統合コスト
各市場データは、収集、処理、着陸などの複数のプロセスを経る必要がありますが、SinoPac証券は、Redisを介したリアルタイムの市場データの収集など、テクノロジーを選択する際に各段階で異なるソリューションを選択しました。アプリケーションの処理にはパンダを使用してください、およびC-ISAM / HDF5は、市場データのストレージを提供します。
これに基づいて、各サービスアーキテクチャを統合および開発する場合は、各サービスレイヤーの使用法を理解してから、システムが提供する必要のあるサービスを統合する必要があります。たとえば、市場データの次元を減らし（ティックレベルの高周波データを分レベルまたは日レベルのKラインに変換する）、異なる月の先物を継続的な契約に接続するタスクには、システムに非常に高いコストと技術要件が必要です。統合。
- 異常を除外する
オープンアーキテクチャ上に構築されたサービスは、データ側の例外など、さまざまな例外に直面し、効果的かつ正確にロックすることはできません。このような異常をなくすためには、開発アーキテクチャのコードの二次開発に多くの人的資源と物的資源を投資する必要があり、開発者はビジネスに集中できなくなります。
2.テクノロジープラットフォームの選択
上記のビジネス上の問題点とチームの特性を考慮して、履歴データとリアルタイムデータの処理を考慮に入れ、同時に金融市場の見積もりサービスのコンピューティング要件を満たすテクノロジープラットフォームを見つけたいと考えています。ボックスの、優れたパフォーマンス、低学習と開発コスト。
2019年6月、kdb +、InfluxDB、Kafka、DolphinDBシステムを連続して評価しました。
- kdb +
kdb +は、ウォール街で市場情報サービスに広く使用されている時系列データベースであり、その高速性で知られています。元の市場見積もりシステムの主な問題は、トランザクションマッチングビジネスのパフォーマンス不足であったため、多くの人がパフォーマンスの問題を解決するためにkdb +を使用することを推奨しています。
予備評価の後、2つの主な理由でkdb +を放棄することにしました：1つはチームメンバーの技術的背景が主にPythonである、kdb +にクロスオーバーするQおよびK言語が難しすぎる、そして市場データがシステムはkdb +を中心に構築されています。追加の高価なkdb +コンサルタントを採用する必要があります。2つ目は、kdb +が単一マシンの単一タスクシステムであるということです。kdbの単一ノードは現在の市場データ量とユーザーアクセスをサポートできますが、その後のストレージおよびコンピューティング機能の水平拡張が必要な場合は、多くの開発と統合作業が必要です。
- カフカ
市場情報サービスシステムの多くのタスクにはリアルタイムストリームコンピューティングが必要であるため、システムを構築するための中心としてカフカを検討するようになりました。
簡単な試行の結果、Kafkaはユニバーサルでカスタマイズ可能なメッセージングシステムであることがわかりましたが、特に安定した効率的な運用を実現するために、金融市場などの専門分野に適用する場合、多くの開発、統合、調整が必要です。必要です。最適化された技術的作業。テクノロジー自体ではなくビジネスに焦点を当てている小規模な開発チームにとって、Kafkaは最良の選択ではないかもしれません。
さらに、Kafkaの利点は、低遅延ではなく、高スループットにあります。金融市場取引のピーク時には、カフカに数秒の遅延が発生する可能性があります。これは、適時性が要求される市場サービスシステムにとって大きな問題です。
- InfluxDB
市場情報サービスは典型的な時系列データアプリケーションシナリオであるため、最も人気のあるオープンソース時系列データベースInfluxDBもテストしました。
InfluxDBはメトリックに従ってデータを編成し、特定のインジケーターのタグの組み合わせのセットの時系列値がシーケンスを形成することがわかりました。これらの異なるシーケンスは、論理ストレージと物理ストレージの点で互いにほとんど独立しています。これは、IoTセンサーのデータ収集とクエリ用に設計されています。市場サービスで多くの問題に直面すると、処理時の在庫オプションなどの表現力が不足する可能性があります。データでは、株価を相関させる必要があります。テクニカル指標を計算するときは、同じ株式の高値、安値、終値の関係、または異なる株式の利回りの関係に注意します。
InfluxDB自体は金融市場の見積もりサービスにおける複雑な計算の要件を満たすことができないため、InfluxDBを純粋なストレージエンジンとして使用して、複雑な計算をサードパーティ（パンダなど）に転送して処理することはできますか？InfluxDB-pandasの処理モードをDolphinDBライブラリの計算モードと比較しました。後者は、パフォーマンスにおいて前者より100倍以上進んでいます。
この利点は、次の3つの側面からもたらされます。
- DolphinDBのデータアクセス速度はInfluxDBよりも高速です。
- DolphinDBは、データ転送のコストを節約するためのライブラリ内コンピューティングパワーを提供します。
- DolphinDBの計算速度はパンダの計算速度よりも速いです。
- DolphinDB
DolphinDBは、kdb +の評価中に予期せず発見された製品です。テストの結果、金融市場サービスの要件に沿った、あらゆる面でのパフォーマンスが優れていることがわかりました。
kdb +と比較すると、DolphinDBは分散時系列データベースであり、水平方向の拡張に追加の作業は必要ありません。DolphinDBの言語はSQLとPythonの組み合わせのようなもので、初心者はすぐに始めることができます。Kafkaと比較すると、DolphinDB独自のストリーミングデータシステムはデータベースと緊密に統合されているだけでなく、組み込みのストリーミングコンピューティングエンジンが使用されています。ボックスは、単純な構成とスクリプティングにより、市場情報サービスの作業の95％以上を完了することができます。InfluxDBと比較して、パフォーマンスは優れています。
ハードウェアリソース、開発とメンテナンスのコスト、製品の納品サイクルなどの複数の側面と組み合わせると、DolphinDBの包括的なコストが最も低いことがわかりました。
3.DolphinDB導入後の現状
2019年8月にDolphinDBのテストを開始し、10月にテクノロジープラットフォームとしてDolphinDBを使用することを決定しました。2020年3月に、新しい市場情報サービスシステムが正式に開始されました。
- 関数ビューを使用してサービスをすばやく拡張する
DolphinDBの関数ビューは、データサービスを抽象化したものです。元々、関数サービスはデータを取得した後にクライアントが必要とする処理を計算する必要がありましたが、今では集中処理のためにデータベースに転送でき、クライアントはAPIを使用して関数ビューを呼び出すだけで済みます。他の事業部門が新しい市場データサービスリクエストを提出する場合、元のデータ構造と権限をすべて公開することなく、SQLのような言語で関数ビューを開発し、その使用を承認するだけで済みます。
このアプローチは、データサービスの開発をスピードアップするだけでなく、データのガバナンスと制御を簡素化します。機能ビューは、開発を加速し、システム管理と機能拡張のための管理を簡素化する効果もあります。
Web側での市場情報の表示を例にとると、もともとWebバックエンドで計算処理を行う必要がありました。関数ビューを使用すると、元のバックエンド処理ロジックがDolphinDBを介してより簡潔かつ効率的にカプセル化され、元のWebバックエンドで広範囲に開発されたコードが1行の関数に削減され、同じ結果を得ることができます。過去には、クロスマーケット製品の取得では、Webが複数の繰り返しクエリを通じて各市場の製品リスト情報をつなぎ合わせる必要もありました。DolphinDB自体が各市場の市場見積もりを収集しているため、単純なSQL文法とベクトルによって取得されます。ベースの取得。効率と開発が大幅に最適化されました。同時に、データの詳細はDolphinDBにカプセル化されます。Webバックエンドの他の同僚は、過去のデータとシステム間の強力な結合の問題を解決するためにデータインターフェイスを定義するだけで済みます。
DolphinDBの機能ビューは、概念的にはリレーショナルデータベースのストアドプロシージャに似ています。ただし、ストアドプロシージャの多くの制限を克服します。
- 複雑なビジネスロジックの処理には適していません。
- コードの可読性が低い。
- 並列計算と分散計算は実現できません。
DolphinDBを使用して関数ビューを開発することとPythonを使用してビジネスロジック関数を開発することの間に実質的な違いはありません。DolphinDBのスクリプト言語は、関数型、ベクトル、および分散型マルチパラダイムプログラミングをネイティブにサポートし、コードはより簡潔で、操作はより効率的です。
- 便利なストリーミングデータ処理
DolphinDBをインポートするプロセスで、最もエキサイティングなコア機能は、ストリーミングエンジンの処理能力です。ビジネス要件ごとに、異なるストリーミングデータエンジンが必要な処理機能を提供するため、以前のコンピューティング負荷でデータをリアルタイムで取得し、リアルタイムで処理できます。クエリに対するクライアントの戻り時間は1から2に短縮されます。秒から10ミリ秒。
現在使用されているストリーミングデータ処理エンジンは次のとおりです。
- K-lineデータは、Time SeriesAggregatorを介して即座に生成できます。
- Cross Section Aggregatorを使用して、市場の概要とさまざまな市場の状況の並べ替えを作成します。
- 異常検出エンジンを使用して、すべての市場データをリアルタイムで分析し、トランザクションルールをフィルタリングして、警告を発します。
DolphinDBの効率的で便利なスクリプトは、さまざまなプラグインとAPIを組み合わせて、ダッシュボードをすばやく作成します。データ監視および警告データは、GrafanaやNetDataなどのダッシュボードフレームワークと効果的に統合して、システム監視メカニズムを迅速に確立できます。
- 効率的な履歴データのクエリと分析
台湾株の現在の日次データ量は約60,000,000の市場データであり、元のデータサイズは約10Gです。DolphinDBをインポートした後、約2GBのハードディスク容量が必要であり、圧縮率は約20％です。同じシステムリソースの下で、より多くのより長いデータを保持できます。
DolphinDBは、データを合理的に分割してシステムパフォーマンスを向上させることができる分散時系列データベースです。データ量に応じて時間ディメンションで自動的にパーティション化する他の時系列データベースとは異なり、DolphinDBは豊富なパーティション化方法（値パーティション、範囲パーティション、ハッシュパーティション、リストパーティション、結合パーティションなど）を提供し、ユーザーがビジネス特性を利用できるようにします。およびデータ分散では、適切なパーティション戦略を個別に選択します。パフォーマンスの最適化に関する考慮事項に関係なく、これは市場サービスのビジネスニーズとも一致しています。市場情報サービスによる履歴データの処理は通常、日数に基づいており、任意の時間枠に分割することはできません。
台湾の市場データに関しては、Tick部分は現在ストレージに1日1パーティションを使用しており、OrderBook部分は非常に多いため、アクセスに関する現在のシステム要件を満たすことができるデュアルパーティション（Symbol + Date）を使用しています。 。OrderBookは、以前は構造を実装できなかったデータでしたが、現在はDolphinDBで保存されており、さらに顧客市場データを提供するSinoPac証券のコンテンツ項目が追加されています。
さらに、DolphinDBの設計により、同じ種類の市場を使用中の完全なデータテーブルと見なすことができ、特定の条件のデータを単純なSQLステートメントで照会できます。これまで、自己定義のクエリインターフェイスでHDF5 / Redisにアクセスする方法では、新しいクエリ条件のために、追加のクエリパラメータを開発する必要がありました。
DolphinDBは、豊富でオープンなAPIと効率的なサービス機能を備えているため、SinoPac SecuritiesはDolphinDBのセットを構築し、クエリAP側の要件を満たすためにシングルモード状態を採用しています。複数のサーバーを構築する必要はありません。必要なパフォーマンスと機能。
- 開発コストを大幅に削減
これまで、SinoPac Securitiesの製品は、さまざまなオープンシステムアーキテクチャを積み重ねて構築されていましたが、その一部は金融業界向けに設計されていなかったため、統合するために多くの時間とエネルギーを費やす必要がありました。DolphinDBをインポートした後、さまざまなサービスに元々分散されていた処理がDolphinDBに転送されて完了します。これには、リアルタイムストリーミングデータ、バッファリングされたデータ、履歴データ、レポートデータが含まれ、統合コンピューティングエンジンによって処理されます。全体的なサービス効率性と同時に、開発と統合の難しさ、およびハードウェア管理の複雑さも軽減します。
DolphinDBのサービスにより、各電子プラットフォームはDolphinDBの組み込みプログラミング言語を使用して関連機能を開発できます。当初は数百行のPythonコードが必要でしたが、現在では12行を超えるDolphinDBコードで完了できるため、改善されています。開発速度、デバッグの多くの時間と複雑さを節約します。
インポートプロセス中に、元のDolphinDBファクトリは、特別な使用シナリオ用の新しい機能も開発しました。これにより、技術的なコストとしきい値が大幅に削減されました。
概要
市場データを処理する場合、データの正確性を確保することに加えて、私たちが直面するより大きな課題は、パフォーマンス要件と機能の柔軟な拡張です。
DolphinDBの導入後、開発チームの実際の展開は2〜3人から1人（フルタイム以外）に減り、サーバーの数は6人から2人（そのうちの1人はバックアップ）に減りました。リモートディザスタリカバリ）。しかし、開発速度が速くなり、パフォーマンスが向上し、ユーザーエクスペリエンスが向上しました。