この記事では、大量の気象データをクラウド上に保存したり、クエリを実行したりするために、Table Storeをどのように利用できるかについて説明しています。
著者：宜勝
気象データは、大容量・高瞬間性・多様性を特徴とするビッグデータの代表的なものです。気象データは主に時空間データであり、時間や空間の範囲内で個々の物理量の観測値やアナログ量を保持しています。一日に生成されるデータは通常数十TBから数百TBにも及び、爆発的に増加しています。気象データを効率的に保存し、クエリを行うことは、ますます困難な課題となってきています。
従来のソリューションは、通常、リレーショナルデータベースとファイルシステムを組み合わせて、この種の気象データをリアルタイムで保存し、クエリを行います。しかし、これらのソリューションには、スケーラビリティ、保守性、パフォーマンスの面でいくつかの欠点があり、データサイズが大きくなるにつれて明らかになってきています。近年、学術界と産業界の両方の人々が、大量の気象データをリアルタイムで保存し、クエリを行うためのソリューションとして、分散型NoSQLストレージを使用し始めています。従来のソリューションと比較して、分散型NoSQLストレージは、より大きなデータサイズをサポートし、より優れたクエリ性能を提供し、安定性、管理性、および他のいくつかの機能を大幅に向上させることができます。
また、クラウドコンピューティングリソースを利用してデータの解析、保存、クエリ、分析を行うことも増えてきています。クラウドには多様な製品・サービスと弾力性のあるコンピューティングリソースがあり、クラウドの分散ストレージを利用して気象データをリアルタイムで保存・照会し、ビッグデータコンピューティングサービスを利用して気象データを分析・処理し、最終的には各種アプリサービスを利用して気象プラットフォームやアプリを構築するなど、気象データ処理のワークフロー全体の実現をサポートすることができます。
そのため、気象学の研究者（海洋学や地震学などの分野の研究者だけでなく）の間でも、クラウドコンピューティングや分散ストレージについて学び、これらのサービスに基づいて大量の気象データのストレージやクエリソリューションを設計する方法を検討する人が増えてきています。この記事では、アリババクラウドテーブルストア（旧称：OTS）を気象学に実験的に適用し、テーブルストアを使って気象データをリアルタイムで保存し、クエリを行う方法を説明します。
気象データの特徴と問い合わせ方法
本章では、気象データ（主にモデルデータ）の特徴、いくつかの問い合わせ方法、そして大量の気象データを保存して問い合わせを行うために解決しなければならない問題点について説明します。
モデルデータ
気象データの非常に重要な部分は、数値モデルを予測するモデルデータです。モデルデータは、センサー（地上、空中、衛星などのセンサー）からのリアルタイムの観測データをもとに、高性能な計算機が具体的な物理式を計算して得られます。モデルデータを作成するためには、多くの計算機システムが必要となります。一般的に先進国の気象機関は、独自のモデルシステムを持っています。
モデルシステムは1日に数回の計算操作を行い、一定時間内（例えば240時間以内）に高度の異なる一連の緯度経度グリッド上のデータを予測するために、毎回数百の物理量が生成されます。グリッド上の各点は、将来のある時点で、その高度の緯度経度で指定された場所の物理量の予測値を表しています。
多次元モデルデータ
モデルデータは、典型的には多次元データです。例えば、モデルシステムがデータを生成するたびに、以下の5つの次元を含みます。
1、物理量（または要素）：温度、湿度、風向、風速など。
2、予測時間範囲：次の3時間、6時間、9時間、72時間など。
3、高度。
4、経度。
5、緯度。
要素と予測時間範囲を指定すると、次の図のように高度、経度、緯度が三次元データグリッドを形成します（図はインターネットより入手）。各点は三次元空間内の点であり、特定の点の値は、予測時間範囲（例えば、次の３時間）内の物理量（例えば、気温）のその点の予測値です。
3次元格子空間が高さの異なる10個の平面で構成されているとします。各平面は2880×570の格子点で構成され、各格子には4バイトのデータが格納されています。そうすると、総データサイズは約64MB（2880×570×4×10）になります。これは、あるモデルシステムが特定の時間範囲内で行った物理量の予測です。このことから、モデルデータの総データサイズが非常に大きいことがわかるはずです。
モデルデータの問い合わせ方法
予測者は、ページ上のモデルデータを閲覧し、それに応じて数値モデルを予測します。このページでは、複数のモデルデータのクエリ方法を提供する必要があります。ここでは、いくつかのクエリ方法の例を紹介します。
1、例えば、全球の地表面温度のグリッドデータや、今後3時間の浙江省の地表面温度のグリッドデータなどです。
特定のグリッドポイントの時系列データをクエリ：例えば、アリババがある都市の気温を3時間後に取得し、その後6時間後に取得し、次の72時間後に取得した時系列データを繰り返します。
3、異なる物理量を有するデータをクエリ：例えば、特定の予測時間範囲内の特定の高度にある地点における全ての物理量の予測データ。
4、様々なモデルシステムによって生成されたクエリデータ：例えば、ヨーロッパのセンターでのクエリモデルデータと、中国の気象機関で生成された対応するデータ。
クエリ方式は前述のタイプに限定されるものではありません。本論文では、主に最初の2つの代表的な問い合わせ方法である、経度緯度平面の格子点データの問い合わせと、特定の格子点の時系列の問い合わせについて分析します。
まだ未解決の問題について
第一の問題はストレージです。大量の気象データを保存するためには、複数のサーバが必要となります。データの信頼性、管理性、システムの保守性を確保した分散型ストレージシステムを選択・構築することが課題です。
2つ目の課題はクエリです。予報者は、効率的で正確な天気予報を提供するために、大量の気象データを素早く閲覧する必要があります。そのため、各クエリ操作の待ち時間は非常に短く（ミリ秒）なければなりません。上述したように、データは複数のサーバに分散しているため、ミリ秒レベルのレイテンシを実現するためには、以下の2つの要件を満たす必要があります。
1、クエリ基準に基づいて、クエリされたデータを効率的に配置することができること。
2、データが配置された後、クエリに必要なデータを効率的にフィルタリングすることができること。例えば、ある点の時系列データをクエリするには、その点のデータのみをフィルタリングする必要があります。
従来の方法と分散型NoSQLの方法がそれぞれどのようにこの問題に対処しているかを見てみましょう。
従来の気象データの保存とクエリソリューション
多次元気象データは大規模であるため、従来のストレージでは、データベースではなくファイルシステムを使用します。ファイル・システムでは、各ディメンジョンはディレクトリです。ディレクトリは、以下の図に示すように、データ・ファイルをツリーのリーフ・ノードとするディレクトリ・ツリー構造になっています。
前述の図は一例に過ぎません。データ層とディレクトリ構造設計の関係は、異なるストレージシナリオでは異なる場合があります。研究機関では、異なるディレクトリ構造を採用しています。考慮すべき点の1つは、データファイルのサイズ、つまりデータファイルが保持すべき次元情報の量です。すべてのファイルが小さい場合、ファイルシステムはあまりにも多くのファイルを含み、特定のファイルを検索する際の待ち時間と、小さいファイルを維持するためのコストを増加させます。すべてのファイルが大きい場合、システムはファイル全体の読み取りを避けなければなりません。
さて、このソリューションがストレージとクエリの問題にどのように対処しているかを見てみましょう。ストレージに関しては、様々なデータ型を異なるサーバ間で分散して保存するために、手動でデータを分割する必要があります。各サーバのディレクトリ構造は、前掲の図に示されています。特定のデータ型が常に特定のサーバに対応することを保証するために、通常、リレーショナル・データベースまたは構成ファイルがデータを記録するために使用されます。
データクエリの場合、このソリューションでは、まず、クエリを実行するデータファイルを含むリレーショナルデータベースからサーバとファイルシステムのパスを取得し、対応するサーバ上のエージェントを訪問してクエリを実行します。エージェントはローカルのファイルシステムにアクセスし、データファイルを読み込んだ後、ユーザが必要とするデータをフィルタリングして処理します。このエージェントは不可欠です。その役割は、ネットワークトラフィックを減らすために、ローカルでデータをフィルタリングして処理することです。
予測時間範囲の間隔が3時間で、指定された高度にある地点の時系列データを今後72時間の間に取得するとします。24個の数値が必要です。問題は、24個の数値は、冗長なデータが多すぎるため、非常に大きな（数百MBの）データファイルを必要とする可能性があるということです。他の経度緯度グリッドポイントや他の高度のデータには興味がありません。ローカルエージェントがデータを読み取るとき、データが特定のファイル形式（例えば、NetCDF）であれば、プロセスを最適化するために、ファイルの一部だけを読み取らなければなりません。
しかし、このソリューションには明らかな欠点があります。
1、異なるデータタイプが異なるサーバに格納されている場合、データの整合性と可用性の問題に対処するために、かなりの手動メンテナンスとコストが必要になります。
2、データタイプとストレージノード間の対応関係が確立されているため、後からデータが追加されたり削除されたりすると、手動での調整が必要となり、パフォーマンスが相対的に低下します。
3、したがって、クエリ性能を最適化するために、エージェントプログラムを開発し、ストレージノード上で起動する必要があります。このプログラムは、データファイルから基準を満たすデータのごく一部をフィルタリングする役割を担っています。データファイルがNetCDF形式で格納されていると仮定します。ローカルエージェントは、ディスクの読み取りレイテンシを減らすために、ファイルの一部のみを読み取る必要があります。このようにカスタマイズされたソリューションでは、開発コストと保守コストが発生します。同時に、このエージェントはローカルファイルシステムとNetCDFファイル形式に基づく特定の最適化であるため、既存の成熟した分散ストレージシステムに統合することは困難です。
気象データの保存とクエリのためのテーブルストアソリューション
Alibaba Cloud Table Storeは、高カレンシーなデータの読み書き操作とPBレベルのデータストレージをサポートし、ミリ秒単位でデータを読み込む機能を提供するクラウド上の分散型NoSQLサービスです。前節では、従来のソリューションを分析し、大量の気象データの保存とクエリについて学びました。次に、Table Storeがこれらの問題にどのように対処しているかを見てみましょう。
一方、Table Storeは分散型のNoSQLストレージサービスです。Table Storeでは、データはさまざまなサーバーに分散されており、1つのクラスタで10PBのデータをサポートすることができます。これにより、ストレージの問題が解決されます。
一方、Table Storeは高速な1行クエリと範囲クエリをサポートしているため、データモデルの観点からは大規模なSortedMapになります。テーブルが数百億、いや数兆のデータ行を持っていても、1行のデータが配置される速度が低下することはありません。そのため、ファイルシステムに小さなファイルが過剰に含まれている場合、目的のデータを見つけるのにかかる時間が短縮されます。
クエリの観点から見ると、データの位置をより効率的かつ正確に特定することは、読み込まれて返される冗長なデータが少なくなることを意味し、クエリの効率性が高まることを意味します。テーブルストア内のデータの行または列を、すべてのクエリ方法の要件を満たす適切な粒度に制限することができます。このソリューションが優れたパフォーマンスを提供することが証明されています。では、このストレージソリューションがどのように設計されているのか、具体的に見ていきましょう。
ストレージソリューションの設計
次の図は、Datastore データ モデルを示しています。各行には、データの行を一意に識別するために使用される属性カラムと主キーがあります。
以下のソリューションでは、主キーと属性列の設計方法と、2つの典型的な問い合わせ方法である、経度-緯度平面の格子点データの問い合わせと、特定の格子点の時系列の問い合わせの実装方法を主に説明します。
ソリューション1
気象学における特定のモデルデータ型（Data）を表すために、以下の式を一時的に使用します。
データ＝Ｆ（物理量、予測開始時刻、高度、予測時間範囲、経度、緯度
最初の4つのディメンジョンをPrimaryKey(PK)とし、最後の2つのディメンジョンを属性カラムとすることができます。これらの次元は以下のように表されます。
Row（物理量、予測開始時刻、高度、予測時間範囲）＝Ｆ（経度、緯度
PK = (物理量、予測開始時刻、高度、予測時間範囲)
データ = F (経度、緯度) = 2次元の経度、緯度グリッドデータ (バイナリ形式で属性欄に格納)
メタ＝補助情報、例えばデータが圧縮されているかどうかなど。
これが最終的な結果です。下図のように、Row(PK)=(Data, Meta, Other attribute columns)、Table = SortedMap(Rows)となります。
この時点で、経度平面の格子点データを問い合わせるには、物理量、予測開始時刻、高度、予測時間範囲をPKとして組み合わせて、Table StoreのGetRowインターフェイスを使ってデータの行を読み込めばいいだけです。複数の経度平面のデータを取得するには、BatchGetRowインターフェイスを使用して複数行のデータを読み込みます。データを読み込んだ後、クライアントは属性列に格納されているバイナリデータを解決する必要があります。気象データの圧縮率が比較的高いため、本ソリューションを使用する場合はデータ圧縮を推奨します。
このソリューションでは、各行に保存されるデータの粒度を設計上考慮することが重要です。この例では、各行には経度平面のデータのみが保存されています。2880×570のfloatデータを考えてみます。合計サイズは2880 x 570 x 4 = 6.3 MB（圧縮すると小さくなります）です。この粒度はストレージとクエリの両方に適しており、気象学におけるクエリ要求のほとんどは1つのプレーンを読み込むだけで済みます。
しかし、このソリューションには1つの欠点があります。それは、経度平面の格子点データを問い合わせるためには、要求された格子点を見つける前に、経度平面の格子点のすべてのデータを最初に読まなければならないということです。このソリューションでは冗長なデータが多くなりすぎるため、このシナリオでは高い検索性能を得ることができません。この問題を回避するため、ソリューション2を提案します。
ソリューション2
特定の格子点の時系列を問い合わせるための要件を満たすために、データの粒度を下げ、問い合わせて返される冗長性を減らすために、データをさらに分割することを検討します。データの粒度を下げるために、1行の経度平面をさらに100の正方形に分割し、100の属性列に保存します。次の図は分割の例です。481 x 641平面を49 x 65の多数の正方形に分割します。各正方形のデータは、Data_x_yという列に保存され、(x,y)は左上の正方形の角の座標です。
このとき、Row(PK) = (Data_x1_y1, Data_x2_y2, Data_x3_y3, ... , Meta)
以下に分割図を示します。
このソリューションを使用して特定のグリッド点の時系列を問い合わせるには、まずスピッティング式を使用してその点の属性列を計算し、その属性列のみを読み込むように設定し、BatchGetRowインターフェースを使用して異なる予測時間範囲内のデータを一括して読み込む必要があります。これにより、その格子点の時系列データを取得し、フィルタリングすることができます。ソリューション1と比較すると、ここで読み込むデータは100倍にもなりますので、クエリ性能は大幅に向上します。
グリッド点ではなく、あるエリアのデータを読み込むとします。まず、その領域にどのマスが関係しているかを計算し、関連するマスのデータのみを読み込むことができます。これにより、読み込むべき冗長なデータの量を減らすこともできます。
平面全体を読み込まなければならない場合は、ソリューション1と2の両方をこのシナリオに適用することができます。ソリューション1の利点は、データを結合してより良い圧縮率を実現できることです。オプションを評価した後、両方のソリューションを組み合わせるか、必要に応じて1つだけを使用するかを決定することができます。
ソリューション2の分析
次の図は、Table Storeを使用した場合の新しいクエリ処理を示しています。
では、そのメリットをまとめてみましょう。
1、高い信頼性、高い可用性、高い保守性、高い拡張性。複数のサーバー上のファイルシステムを手動で管理する場合に比べ、本ソリューションで使用されるよく開発された分散型NoSQLシステムは、より高い信頼性と可用性を提供します。高いスケーラビリティにより、さまざまなデータタイプを容易に保存することができます。
2、弾力性のあるストレージとコンピューティングリソース Table Storeのサービスをクラウド上で利用する従量課金プランにより、大幅なコスト削減が可能であり、一時的な容量不足やアクセスピークのニーズにも対応できるソリューションです。
3、優れたパフォーマンスとシンプルなアーキテクチャ 実用的なテストでは、分散型 NoSQL ソリューションは従来のソリューションよりもはるかに高いパフォーマンスを実現しています。従来のソリューションでは、読み取りパフォーマンスを最適化するために、サーバー側でエージェントを起動する必要がありました。Table Store ソリューションでは、同様のエージェントを開発する必要がなくなり、アーキテクチャがシンプルになり、レイヤリングが明確になります。
Table Storeソリューションの潜在的な欠点は、気象システムの開発エンジニアが分散型NoSQLシステムに徹底的に精通していなければならないことです。具体的には、ソリューション2の実装のためにデータを分割するために複雑な開発努力が必要になります。
概要
この記事では、大量の気象モデルデータを格納してクエリを実行するための従来のソリューションとTable Storeソリューションについて説明し、それぞれのメリットとデメリットを比較しています。さまざまな業界でビッグデータの問題を解決するために、分散システムやクラウドコンピューティングサービスを利用する傾向が強まっています。この記事では、初期のソリューションのみを紹介しています。将来的には、より高度な産業向けソリューションがクラウド上に実装されることになるでしょう。
本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。
アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ