こんにちは、Habr！

彼らが言うように、伝統によると、私たちは年に一度Yandex.Pogodで何か新しいものを出します。 最初はMeteum-機械学習を使用した伝統的な天気予報、次にScienceasting-気象レーダーとニューラルネットワークに基づく降水の短期予報。 この投稿では、世界の天気予報を作成し、それに基づいて美しい天気図を作成した方法について説明します。

最初に、製品に関するいくつかの言葉。 天気図は、西部では非常に人気があり、これまでのところロシアではあまり人気がない天気を調べる方法です。 この理由は、実際には、天気そのものです。 気候のために、私たちの国の最も人口の多い地域は突然の気象災害の影響を受けません（そしてこれは良いことです）。 したがって、これらの地域の居住者の間の天気への関心は、家庭である可能性が高くなります。 そのため、例えばロシアの週末にモスクワの天気がどうなるか、木曜日にサンクトペテルブルクに雨が降るかどうかを知ることは、ロシア中央部の人々にとって重要です。 日付、時刻、天気パラメータのセットがある表からそのような情報を見つけるのが最も簡単です。

一方、米国東海岸の住民にとっては、美しい女性の名前を持つ次のハリケーンの軌跡を知ることがより重要であり、ダコタの農家にとっては、トウモロコシが生育する畑のhの分布を監視することです。 そのような情報は、多くのテーブルからよりもマップから学ぶ方がはるかに簡単です。 そして、ロシアの天気予報サービスがより可能性の高いテーブルであり、西部ではより可能性の高いマップであることがたまたま起こりました。 ただし、ロシアでは、ユーザーが必要な天気がどこにあるかをユーザーが正確に知る必要がある場合、天気の消費パターンがあります。これらは週末にピクニックの場所を選択する人々、特に接頭辞「風」と「k」、そして最後に夏の居住者を持つアスリートです。 これらのカテゴリのユーザーのために、私たちは製品を作りました。 そして今、私は彼のフードの下にあるものについて話します。

予測計算：個人およびグローバル

私たちはすぐに、地図を作成するために、予測がグローバルになることを決定しました。 まあ、地球全体をカバーしていないカードが中世から配られているからという理由だけで。 したがって、Meteumをグローバルなカバレッジに拡大する必要がありました。 ただし、以前のシステムアーキテクチャは、水平スケーリングには適していませんでした。

前のシリーズの要約。 熱心な読者が覚えているように、Meteumの最初の実装では、必要に応じて天気予報を計算しました。 ユーザーがサイトにアクセスするとすぐに、座標の要因のリストを収集し、それを訓練されたMatrixnetモデルに転送しました。 vector-apiと呼ばれるマイクロサービスは、要因の収集を担当しました。 マイクロサービスは、1つを除くすべての人に適していました。新しい要素を追加したり、カバレッジの地域を拡大したりすると、マイクロサービスが機能する物理マシンのメモリ制限に近づきました。 さらに、最終的な天気API自体の応答の形成には、Matrixnetモデルを使用した時間とCPUの負荷という点で高価な操作が含まれていました。 両方の要因がグローバルな予測の構築を強く妨げました。 さらに、バックログには、実験の予測の精度を向上させる要因の完全なキューがありましたが、上記の制限のために生産に行くことができませんでした。

また、多くのユーザーに愛されている降水マップの選択されたアーキテクチャの欠点に直面しました。 降水情報の構築に必要なデータを保存および処理するために、PostGIS拡張機能を備えたPostgreSQL DBMSが使用されました。 夏の雷雨の間、1秒あたりの重いハンドルあたりのリクエスト数は数百から数万に瞬時に変わりました。これは、データベースサーバーのプロセッサとネットワークチャネルの大量消費を伴いました。 これらの状況は、サービスの将来について考え、気象データの処理と保存に異なるアプローチを適用する追加のインセンティブとして機能しました。

実行時に天気を計算する代わりに、要因が更新されたときの座標の大きなセットの予報の予備計算がありました。 2x2 kmの解像度の土地と10x10 kmの解像度の水をカバーするグローバルグリッドに定住しました。 グリッドは3 x 3度の正方形に分割されます-これらの正方形により、モデルの因子を同時に準備し、結果を処理できます。 これは地図上でどのように見えるかです。

通常のグリッド領域の分割

気象の準備プロセスは、Meteoクラスターから始まります。 名前によれば、「古典気象学」はこのクラスターで行われます。 ここでは、モデルGFS（米国）、ECMWF（英国）、JMA（日本）、CMC（カナダ）、EUMETSAT（フランス）、Earth Networks（米国）およびその他多くのサプライヤーの観測データと予測をダウンロードします。 ここで、WRF天気モデルは、私たちにとって最も興味深い地域について計算されています。 パートナーから、または計算の結果として受信した気象データは、通常、異なる圧縮レベルのGRIBまたはNetCDF形式でパッケージ化されます。 サプライヤーまたは計算方法に応じて、このデータはモスクワ地域または全世界を対象とし、200MBから7GBまでの重さです。

天気クラスターからの天気予報ファイルは、最初にMDS（メディアストレージ、大きなバイナリ情報のリポジトリ）に行き、次にYT （Yandex Map-Reduceシステム）に行きます。 YTでの作業は、暫定的に「配信」と「アプリケーション」と呼ばれる2つの段階に分けられます。 配信とは、トレーニングされたモデルを後で適用するための要素の準備です。 ファクターは、結果のグリッドに正しく再補間され、単一のユニットに縮小され、並列処理とアプリケーションのために3 x 3度の正方形にカットされなければなりません。 ここでの手順の複雑さは、大量のデータと、任意のエリアの予測に関する新しいデータが来るたびに演習を行う必要があることにあります。

最初の段階が機能した後、事前学習済みの機械学習モデルの適用が開始されます。 Meteumaの最初の実装では、機械学習を使用して温度と降水量の2つの主要な気象パラメーターのみを予測できました。 新しい計算スキームに切り替えたので、残りの気象パラメーターを計算するために同じアプローチを使用できます。 機械学習を使用すると、圧力、風速、湿度などの新しいパラメーターの精度が明確に向上します。 24時間前にこれらのパラメーターを予測する際のエラーは、最大40％低下します。 多くのユーザーにとって風と圧力の最も正確な指標が重要であるという事実に加えて、この改善により、別の一般的なパラメーターである感覚に応じた温度をより正確に計算することができます。 それは、常温、風速、湿度で構成されています。 もう1つの注目すべき革新は、気象現象を計算する新しい方法でした。 現在では、複数の分類式に基づいています-降水の有無だけでなく、そのタイプ（雨、雪、h）、および雲の存在と曇りも決定します。

これらすべてのモデルは、通常のグリッドの各ポイントに限られた時間で適用する必要があります。 モデルが適用された後、データ処理の別の層-ビジネスロジックがあります。 このセクションでは、機械学習によって予測された変数を必要な単位に組み込み、予測の一貫性を保ちます。 現在、MLモデルはプロセスの物理学についてほとんど知らず、主に気象モデルから派生した要因に依存しているため、「-10の雨」などの一貫性のない気象状態を取得できます。 この場所でより正確に行う方法についてのアイデアはありますが、現在は正式な制限により解決されています。

訓練されたモデルを適用することの難しさは、予測ごとに約140億の操作を完了する必要があることです。 各計算には何百もの要因が必要であり、これらの要因のリストは非常に可動性があります。私たちは常にそれらを試し、新しいものを試し、グループ全体を追加し、弱いものを捨てます。 すべての要因がサプライヤーから直接とられるわけではありません。 いくつかのパラメーターの因子関数を実験します。 このような多数の機能を生成するためのルールは、Pythonコードの形で維持するのが非常に困難です。面倒で、遅延計算が難しく、分析や診断が困難な機能（または機能のソースデータ）が不要になります。 そのため、LISPのアナログを発明しました。 厳密に言えば、これはLISPではなく、すでに準備されたASTであり、データの詳細を考慮したLISPの方言に非常に似ています。 このLISPのプロセッサを、必要な方法であるレイジーとキャッシングに作りました。 したがって、まず、不要になった要因を計算せず、2番目に必要なものを2回計算しません。 これらのメカニズムは、すべての計算に自動的に適用されます。 そして、これが正式なASTであるという事実により、必要なものと必要でないものを簡単に分析できます。 ロジックの一部を個別にシリアル化して保存し、ビジネスパーツをログに書き込み、ロジックの大部分を自動的に形成し（コード形式でプレゼンテーションをバイパス）、実験用にバージョン化します。 すべての操作が行列に対して直ちに実行されるため、オーバーヘッドはまったく重要ではありませんでした。

APIの一般的なデータ配信スキーム

予測を計算した後、予測を特別な形式（ForecastContainer）で記録し、これらのコンテナーをメモリからのデータ回復のマイクロサービスにロードします。 実際、0.02度のグリッドを持つ全世界では、約1,166,400,000の浮動小数点値を取得します。これは、1つのパラメーターのみで34GBのデータです。 このようなパラメーターは50以上あります。したがって、このデータを1台の物理マシンのメモリに完全に保存することはできませんでした。 圧縮データの高速読み取りをサポートする形式を探し始めました。 最初の候補はHDF5でした。これは、データチャンクの機能とアンパックチャンクバッファーのサポートを備えています。 2番目の候補は、LZ4で圧縮され、フラットバッファーに記録された、自己記述形式の独自形式の浮動小数点行列です。 テスト結果から、作業用にデータファイルを開くには、HDF5よりもFlatbuffersの半分の時間がかかり、キャッシュから任意のポイントを読み取ることがわかりました。 その結果、50個の変数のデータが52.1GBを占めるようになりました。

問題の記述以来、メモリ消費と応答時間の要件は非常に高いため、Pythonで記述された古いマイクロサービスをC ++で書き直すことにしました。 これにより、99分位のサービス応答時間が100ミリ秒から10ミリ秒に短縮されました。

サービスを新しいバックエンドアーキテクチャに移行することで、内部および外部のパートナーに天気予報を直接提供し、実行時にキャッシュとモデル計算をバイパスし、緊急の場合は、Yandexクラウドテクノロジーを使用して負荷を簡単にスケーリングできるようにしました。

全体として、新しいアーキテクチャにより、応答のタイミングを短縮し、より多くのワークロードを維持し、異なるパートナーに与えられたデータ同期を取り除くことができました。 Yandex.Weatherデータは、Yandexメインページ、Yandex.Browserの天気プラグイン、Ramblerの天気など、多くのYandexサービスで表示されます。 その結果、彼らは全員、 Yandex.Weatherメインページのユーザーがその瞬間に見る値を正確に与える機会を得ました。

人に近い：タイルサーバーと前面

新しいマップに予測を描画するには、多くの追加処理が必要です。 最初に、マイクロサービスとAPIによって提供される同じデータでMapReduce操作を実行し、解像度0.02度の通常の緯度経度グリッドで全世界のデータを生成します。 出力では、各パラメーター：温度、圧力、風速、風向、および各地平線：将来までの予測時間または過去までの事実時間について、サイズ9001 * 18000のマトリックスが取得されます。

その後、このデータに基づいてメルカトル図法を構築し、Yandex.Maps APIの要件に従ってタイルにカットします。 ここで、天気図の作成チェーンで最も大きな問題の1つに遭遇します。新しい予測を生成するたびに、すぐに更新する必要があるタイルの数です。 したがって、マップの次の各ズームレベル（ズーム）には、前のタイルの4倍のタイルが必要です。 0から8までのすべての近似レベルについて、準備が必要であると推定するのは簡単です。

$$

$$4 ^ 0 + 4 ^ 1 + \ドット+ 4 ^ 7 = 21845$$

写真。 合計で、4つのパラメーターのそれぞれについて25の地平線が表示され、そのうちの12の予測には将来の予測があります。

写真の準備ができたら、高度な並列処理でYandexファイルの内部リポジトリにアップロードします。 すべてのズームのマップレイヤー全体が読み込まれたら、インデックス値を置き換えます。これにより、フロントは新しいタイルの場所を理解できます。 したがって、マップ上の新しい予測の十分に高い出現率と予測時間内のデータの一貫性が達成されます。

本格的なバックエンドトレーニングを行ったとしても、天気図の描画とアニメーション化も難しい作業です。 1つの記事ですべてを伝える方法はないため、ここでは最も注目すべき機能、つまり3番目の方向を示すアニメーション化されたパーティクルのレンダリングに注目しました。

これは、風のアニメーションの粒子が天気図でどのように見えるかです

クライアントデバイスのリソース消費を最適化するために、WebGLを使用して風のアニメーションが実行されます。 WebGLを使用すると、グラフィックアダプターの重要なリソースを使用して、コード実行のプロセッサーストリームをオフロードし、バッテリー消費を最適化できます。 この場合のプロセッサのタスクは、シェーダープログラムを実行するための引数を設定することです。 粒子を移動するには、各軸（x / y）のテクスチャの2つのカラーチャネルに粒子の位置を保存するアプローチが使用されます。 そのような位置テクスチャは2つあります。1つはパーティクルの現在の位置を保存し、2つ目は新しい状態を保持するように設計されています。

パーティクルレンダリングは、いくつかのWebGLプログラムによって記述されます。 互換性を高めるために、この標準の最初のバージョンが使用されました。 ブラウザーでは、WebGLの使用は、対応するキャンバス要素コンテキストを介して行われます。 グラフィックアクセラレータはプロセッサを介して数倍の並列操作を実行できるため、パーティクルの移動はWebGLプログラムを介して実行する必要があります。 このようなプログラムの出力は、指定された空間内のポイントのセットです。 このデフォルトのスペースは、キャンバスの表示領域、つまりユーザーの画面です。 ただし、フレームバッファを使用して描画するテクスチャを指定することは可能です。

風のレイヤーが開始されると、プロセッサは粒子の初期位置を生成し、0〜255の範囲で（粒子*コンポーネント）（RGBA）の量の要素の型付き配列を作成します。 この配列から2つのWebGL位置テクスチャが作成されます。 風速データもテクスチャに記録されるため、ビデオカードはそれらにアクセスできます。 このテクスチャの赤と緑のチャンネルには、それぞれ平行速度と子午線速度の値が含まれています。さらに、127の値は風がないことに対応し、127未満の値は軸に沿った負の方向の風速を指定し、正の方向の値より大きい値を指定します。 準備されたテクスチャを使用して、パーティクルの現在の位置が描画されます。 レンダリング後、現在の状態のデータソースとして2番目のテクスチャを使用して、位置テクスチャの1つが更新されます。 次の可視フレームは、透明度を高めて粒子位置の前の画像を描画することにより形成され、その上に現在の粒子位置が適用されます。 したがって、尾が減衰した粒子が得られます。

これが、風のアニメーションのパーティクルが作成の過程でどのように見えるかです。

判明したように、高品質の視覚化のためにテクスチャピクセルの粒子の位置をエンコードするための現在のアルゴリズムは、テクスチャ自体の高精度計算と浮動小数点値のハードウェアサポートを必要としますが、これはモバイルデバイスでは利用できないことが多いため、アルゴリズムは修正され、改善されます。

結論と計画

Yandex.Weatherのアーキテクチャについてお伝えしたかったのはそれだけです。 今年は、内部（上記のとおり）および外部（Yaが存在するほとんどすべてのプラットフォーム。天気は大幅に変更されました）からサービスを完全に再編集しました。 これらの変更の最終結果は、インタラクティブな天気図でした。これは、 当社のサービスで試すことができます 。

しかし、私たちは栄光にとどまることはありません。 来年は、地球のさまざまな地域の気候を探索して「人は何を呼吸するのか」という質問に答えることができるサービスから、多くの興味深い製品と技術の更新を見つけるでしょう。 そして、これはもちろん、すべてとは程遠いものです。 私たちと一緒に。

いつもあなたのもの

Yandex天気チーム