Tutu.ruの経験：列車のスケジュールはどうですか

通勤電車-電車-は、ロシアで最も人気のある旅客輸送手段の1つです。 年間で何百万人もの乗客がそれらを使用し、数千の列車で合計数千億キロを移動します。 モスクワ政府の統一データウェアハウス（）に掲載されているモスクワ運輸省によると、2017年1月だけで、郊外の鉄道輸送の旅客輸送量は4260万人に達しました。 これは昨年より4.1％増加しています。



電車の時刻表の利用可能性、アクセス可能性、正確性はすべての乗客を興奮させ、それを形にして人々に伝える人々にとって、それは重要で非常に難しい仕事です。



私の名前はアレクサンダー・ポドレフスキフです。私はTutu.ru社のリードエンジニアであり、電車のチームリーダーです。記事では、オンラインスケジュールを作成する技術的な詳細と困難、それがどのように機能するか、ロシアの鉄道が提供するデータをどのように使用するかについて説明しますユーザーは、気付かないうちにスケジュールを最新の状態に保つのに役立ちます。





列車のスケジュールは、デカルト座標系での列車の移動プロセスの表示です。 この形式では、鉄道の列車のスケジュールが表示されます。



ロシアには約30の郊外旅客会社（PPC）があり、それぞれが特定の地域の旅客サービスを担当しています。 地域の輸送順序、乗客の希望、研究に基づいて、各PPCは年に1回（夏の初め頃）JSCロシア鉄道に送られるスケジュール変更の提案を作成します。



ロシア鉄道は、電車、旅客列車、貨物列車のスケジュールの申請書を数か月以内に受け取り、新しい列車のスケジュール（新しいスケジュール）を作成し、年末に発効します。 このようなスケジュールは、毎年12月の第2日曜日から翌年の12月の第2土曜日まで有効であり、規範的または基本的と呼ばれます。 原則として、駅やプラットホームの大きなスタンドに掛けられているのは、多くの駅の興行所で購入できる本に印刷されているからです。



同時に、大きな鉄道のジャンクション（モスクワなど）のほとんどの乗客は、交通量の多い地域では基本スケジュールにほとんど意味がないことを知っています。 事実、鉄道は定期的に修理を行う必要があり、ほとんどの場合、列車の動きを部分的に閉じることなく修理を行うことはできません。 そして、JSC Russian Railwaysは、たとえば、1つのステージで両方向に1つのトラックに沿って交互の列車の移動を提供する、さまざまな列車のスケジュールを開発します。 つまり、基本スケジュールに一時的な変更が加えられます。 そして、そのような変更は、修理作業だけでなく、スケジュールに対して絶えず行われます。



スケジュールのあるオンラインリソースが登場する前は、主に駅での発表からのみ一時的な変更について知ることができました。 さらに、アナウンスは特定の日のスケジュールではなく、原則として、基本スケジュールに変更を加えたA4リーフレットです。 そして、1日にそのようなリーフレットがいくつかあるかもしれません。 たとえば、そのうちの1人によると、電車は15:30ではなく15:50に行き、もう一方では、同じ電車が何度も停車し、3番目に-夕方の変化で、ほとんど見られなかった（たとえば、電車が始まった、 22:00ではなく15:40になりました）。 ちなみに、多くのステーションはまだそのようなアナウンスを持っています。 人生の例は実例として役立ちます：Tutu.ruの私の同僚がモスクワからRzhevsky地区に乗り換えることを決めたら、モスクワからVolokolamskまで電車に乗り、修理のためにRzhevに必要な通勤電車が明日だけ、モスクワでは、これに関する情報はありませんでした。



オンラインリソースの出現により、スケジュールを見つけるのがはるかに簡単になりました- ウェブサイトまたはモバイルアプリケーションに移動し 、出発駅と目的駅、日付を入力するだけで、システムはこれまでに知られているすべての一時的な変更を考慮して、その日に予定されている列車を表示します。 変更を加えた大量の紙を勉強する必要はありません。 そして、Tutu.ruはロシアで最初のオンラインリソースになりました。2003年には、基本的なスケジュールだけでなく、一時的な変更も公開され始めました。



このようなリソースを作成し、スケジュールを最新の状態に保つことは簡単ではありませんでした。 変更は手動で監視する必要がありました。サービスの作成者自身が駅に行き、写真を撮り、スケジュールとアナウンスを書き直しました。 すべてのステーションを移動することは物理的に不可能であったため、スケジュールの変更は不正確に行われました。 そして、ここで私たちのユーザーは大いに助けてくれました-Tutu.ruを書いて呼び出して、直接情報を提供してくれました。



しかし、まだスケジュールに誤りがあったため、追加の情報源を探し始めました。 そのため、同様に乗客にスケジュールを正確に知らせることに関心を持っている郊外の旅客会社（PPC）の出現後すぐに、すべての駅のすべての列車のスケジュールとその変更に関するデータを受け取ることに同意しました。 この情報源の出現により、スケジュールの質が大幅に向上しました。 2005年に戻った場合、ほぼすべてのユーザーがサイトで少なくとも1つのエラーに遭遇し、10年後、大多数のユーザーは常に正確で信頼できるスケジュールを確認していました。



まれではありますが、コントロールパネルのデータにエラーが発生し、オペレーターも時々ミスを犯すため、別のソース（ロシア鉄道のメインコンピューティングセンターの郊外スケジュールの中央データベース）を停止および接続しませんでした。郊外電車のスケジュールを作成し、ロシア全土に変更します。

Tutu.ruサービスがスケジュールの関連性を維持する方法

Tutu.ruで、17の「地域」の電車の時刻表、ルート、およびスケジュールに関する情報を見つけることができます（おおよそ、関連するコントロールセンターの責任の制限に従って、領域の条件付き内訳）。 Tutu.ruは、有効にする前にメインスケジュールのデータと、スケジュールの一時的な変更に関する情報（特定の日の列車の移動オプション）を受け取ります。



この情報は、半手動モードでインターフェースを介して入力するオペレーターによってデータベースに取り込まれます。 パートナーシップを結んでいない分野では、専門家がスケジュールサイトを手動で参照し、データを手動で入力します。 このアプローチは多くの労力を必要とし、エラーにつながる可能性があり、その結果、スケジュールが実際のスケジュールと完全に一致しません。



MCCデータベースを接続することにしたとき、その使用方法を正確に知りませんでした。 もともとは、より正確なデータを取得するための追加のデータソースであると想定されていました。 こことMCCシステムのスケジュールモデルの詳細の一部が異なることがわかっていました。たとえば、列車は1つのルートに沿って移動し、終点駅に到着し、この駅にしばらく立ち、その後番号を変更し、移動を続けます。しかし、異なるスケジュールとルートで。 原則として、MCCシステムでは、これら2つの列車は異なって表示され、ロシア鉄道のWebサイトでは、最初のセクションの駅から2番目の駅までのスケジュールにそのような列車はありません。 このような状況は個別に処理され、この列車が単に駅に立ち、その後番号を変えて移動し続けることが確実な場合は、1つのオブジェクトとして起動します。 複合番号（「/」区切り記号で示される元の列車の番号）があり、この列車は異なるセクションの駅間の列車の検索の結果として存在します。



一部のコントロールステーション（CPPCやSZ PPKなど）からパートナー/サブスクライバーに送信される変更には、電車のすべての停留所に関するデータは含まれず、個々のポイント（鉄道駅、チェックポイント、道路横断、ウェイポイントなど）のみに関するデータが含まれます。そして、列車が停止する中間地点（停止地点、プラットフォームなど）を通過するのにかかる時間、それでも各パートナーは独自の方法で計算します。

例について考えてみましょう。リガ方向の6600番の電車は、通常のスケジュールに従って毎日運行し、ナハビノで5:04、オパリハ5:10、クラスノゴルスク5:14、パブシノ5:18以降に停車します。 7月9日、列車のスケジュールが変更され、4：57にナハビノを出発するという情報が運送業者の会社から届き、パブシノは標準のスケジュールに従って運行を続けます。



MCCのデータは次のとおりです。ナハビノ駅とパブシノ駅では、それぞれ4:57と5:18が入力され、中間駅の通過時間は、最初の歩行スケジュールに比例して、つまり6：4：4の比率で計算されます（あたかも列車がこのセクションにいるかのように）遅くなります）、オパリハの停留所は5:06に延期され、5：12にクラスノゴルスク駅に行きます。 長い間、Tutu.ruのWebサイトの計算アルゴリズムは類似しており、99％の場合、列車はまさにそのような動きをします。 しかし、変更の原因が消えて（修理など）、列車が通常の速度でエリア内を移動した場合がありました。 この例では、彼女は6分（5:03）にオパリハに到着し、4分（5:07）にクラスノゴルスクに到着し、4分（5:11）にパヴシノに到着したことを意味します。 それから、スケジュールに従うために、列車は5:18まで駅に立ち、スケジュールに従ってさらに進みます。



これはユーザーにとって何を意味しますか？ 5:10にクラスノゴルスカヤ駅に到着したユーザーは、次の列車を待つことになります。 そのような場合のために、Tucu.ru Webサイトで正確な時間がわからないポイントを停止する時間は、MCCとは異なるアルゴリズムを使用して入力されるようになりました。 時間は、移動の初期スケジュールに基づいて計算されます。一般的には、指定された駅間の列車の最小通過時間に基づいて計算されます。 ユーザーに高い確率で、列車が行くよりも数分短い時間を与えます。 プラットフォームに来るのは、数分後よりも数分早いほうがいいです。



さらに、MCCシステムでスケジュールを作成するときに作成されたヒューマンファクターに関連するエラーが検出されました。 これらおよびその他の理由により、MCCからデータを直接インポートすることは望ましくないと判断されました。 代わりに、MCCと当社のデータがどのように異なるかを調べることがより重要です。 これらのデータに基づいて、他の情報源（困難な場合には駅での列車の実際の検査を含む）に基づいて、専門家はどのデータが「より正確」であるか（またはユーザーにとってより有用か）を決定します。



しかし、何かを比較する前に、オブジェクト間に少なくとも何らかの接続を確立する必要があります。 当初、列車の通信も駅の通信もなかったため、この通信を厳密に確立できるフィールドはありませんでした。 MCC基地で約2万5千個の駅のオブジェクトと1万5千個の列車のオブジェクトが見つかったため、関連する列車を「正面」で検索すること、つまり、各駅と各駅、各列車と各列車を検索して比較することは困難でした。



モデルを作成するためのアルゴリズムで上記の矛盾が考えられるため、比較はあいまいにする必要があります。 これは、オブジェクトの正確な同等性ではなく、データフィールドの1つにわずかな違いがあるオブジェクト、たとえば、日付の1つでの出発時間の2〜3分による違いを探すことを意味します。 ファジー比較はかなり高価なアクションであり、比較対象のオブジェクトのペアが数億になるという事実を考えると、このような方法は妥当な時間内に結果を生成しません。 そして最終的には、最初はすべての機能が知られていないため、確立された通信はほとんどありません。

マッチングステーションと鉄道施設

これは、いくつかの段階といくつかのパスで行われました。 最初のステップは、ステーションのオブジェクト間の対応を確立することでした。 所有している識別子とMCCデータベースによると、コンプライアンスを明確に確立することはできませんでした。 たとえば、ロシアには9つの停留所「105 KM」と17の停留所「106 KM」があります。 そのため、名前の比較はあまり効果的ではありませんでした。MCCベースで一意のステーションを見つけることができる一意の名前を持つステーションの約10％がありました。



この点で、スケジュールデータベースの専門家であるAleksey Derkachevは、Express-3ステーションの7桁のコード（ステーションIDの1つとして広く使用されている）とMCCデータベースのステーションコードとの対応をどこかで掘り下げました。 この表を使用して、列車のスケジュールに参加している駅の約半分のペアを見つけることができました。 少なくともそのような数の駅を比較することが可能になった後、次の段階に進むことができました。同じ列車を見つけようとします。



これを行うために、自動スクリプトは検出されたすべての駅のペアを調べ、特定の駅の列車のスケジュールを選択しました。 次に、受信した列車の各セットを比較し、完全一致（ルート上の駅の数が同じ、各駅での列車の到着/出発時刻が同じ、列車番号が類似、週次スケジュールが同じ）を見つけると、重複が削除され、私たちのスケジュールでは、列車は1つだけでした。



したがって、一部の列車ではペアを見つけることができました。 列車間の通信が確立された後、再び駅に戻ることができました-見つかった列車のペアを通過し、同じであるため、ルート内の駅はほとんど同じです。 これにより、さらに一致するステーションがいくつか得られました。 その後、再び一致する列車を探すことができました。 途中で、さまざまな検索パラメーター、さまざまな仮定を試して、スケジュールの編成と保存の新しい機能を考慮に入れることができました。 数十回の反復の後、通信データベースはすでに使用されている可能性があります。

継続的なスケジュールの不一致検索

列車のスケジュールデータは非常に頻繁に変更されます。1日に数百の変更が行われ、夏のシーズンの開始と終了までに、変更は1日に数千に達することがあります。 さらに、変更がデータベースとMCCデータベースの両方に常に同時に発生するわけではないため、相互作用のルールに従って、1日2回特定の時間にのみデータ更新をアップロードできます。 また、専門家は24時間体制でデータベースにデータを入力できます。



毎回、すべての列車を調整するのはかなり時間がかかる操作であり、比較基準が変更される場合があります（たとえば、1分間の差異の一部は取るに足らないと見なされ、これらの差異を無視できます）。この間にデータ自体が変更される場合があり、新しい列車が追加される場合があります一致するものはまだ見つかりませんでした。 お客様は不一致を見つけるのに役立ちます。 毎秒、サイトで平均10回のスケジュール検索が行われます。



バックグラウンドでの検索ごとに、MCCデータのローカルコピーのデータが要求され、比較が行われます。 列車が類似している場合（番号、週のスケジュール、駅の通過時間）、それらに一致するものがない場合、インストールされます。 一致するものの、データが分岐する場合、見つかった不一致は保存されます。 将来的には、スケジュールの専門家は、一般的な不一致のリスト、特定の列車の不一致を調べて、データが発散する理由を見つけ、ウェブサイトで変更するかどうかを決定できるようになります。



現時点では、モデルの比較、および表示の利便性と操作の両方の点で、システム全体がまだ最終段階にあります。多くの不一致があるため、それらのほとんどは重要ではなく、最初に表示する必要はありません。 モデルと使用されるスケジューリング原則の違いは、比較の精度に影響を与える可能性があります。

技術的な実装

数年前、当社では、DevOpsチームのおかげで、マイクロサービスを作成できるようになりました。 サービスのモノリスとは別に新しい機能を実装することが可能になりました。



そのため、データベースが応答するのと同じ形式でMCCからのスケジュールのすべてのデータを保存し、検索クエリに応答するAPI（現在の日付、駅のスケジュール、特定の電車のルート）を実装するマイクロサービスがありました。 これは、リポジトリからのデータを使用して検索クエリに応答し、2つのデータセットを比較し、モデルの不一致に関するデータを保存するマイクロサービスです。

不一致ベースの補充

サイト上の任意のルートで列車を検索する場合、スケジュールサービスが呼び出され、結果を返す前に、計算されたデータを含むイベントがバスからバスに送信されます。 比較サービスはこれらのイベントをリッスンし、データを受信すると、MCCからデータストレージサービスに同じデータを要求し、受信した2つのセットを比較します。



接続がすでに確立されている列車のデータに矛盾がある場合、これに関して別のイベントが生成され、不適合ストレージサービスでリッスンされます。 一部の列車で接続が存在しない場合でも、データによれば、それらが非常に類似していることがわかると、それらは接続されます。

矛盾のデータベースを備えた電車のスケジュールにおける専門家の仕事のプロセス

これらの不一致を更新するプロセス

おわりに

システムは静止しておらず、私たちは絶えず開発しています。 スケジュールデータモデルの生成および入力方法には、まだ違いがあります。 そのため、最終的な違いのリストにはかなりの数のエントリが蓄積されますが、それらを考慮する必要はありません。そのため、方向付けが非常に複雑になり、結果として問題への対応が難しくなります。 しかし、私たちはそれに取り組んでいます。



私たちは、駅と列車の施設間の通信の自動インストールに取り組んでいます。 「電車チーム」は、サービスの改善に絶えず取り組んでおり、お客様が利用しやすいようにしています。



次の記事では、モデルの構造について詳しく説明する予定ですが、比較のためのアルゴリズムについてさらに詳しく説明します。 さらに、特定された違いと、それらに基づいてシステムがどのように進化するかを説明します。 記事のトピックに関する質問や提案、製品自体についてのご要望がある場合は、必ずご記入ください。