インデックスの設計に関する考慮事項

このトピックでは、インデックス作成プロセスのパフォーマンスに影響を与える可能性のある要因について説明します。 データセットには固有の特性があるため、さまざまな設定を試して、アプリケーションに最適なデザインを見つける必要があります。

ストリーム レイヤーの保存期間が「 aggregation.window-seconds 」の値よりも大きいように設定します

ストリーム レイヤーの保持期間が十分に長いことを確認することは、パイプラインの設計上の重要な考慮事項です。これは、 保持期間がワークフローに組み込むフォールトトレランスのレベルに関連付けられているためです。 パイプラインをアーカイブすると、データが継続的にストリーム化され、indexing attribute値とaggregation.window-seconds値に基づいてデータがメモリにバッチ処理されてから、バッチ処理されたデータが定期的にアーカイブされます。 データのアーカイブに必要な時間は、パイプラインの設定によって異なります。

ストリーム レイヤーの保存期間を aggregation.window-seconds 常に値よりも大きい値に設定することをお勧めします。

例 : aggregation-window.seconds 値が 1800 （ 30 分）の場合は、ストリーム レイヤーの保持時間を 120 分以上に設定する必要があります。 この設定により、パイプラインで短時間の障害が発生した場合に備えてフォールトトレランスが保証されます。

ストリーム レイヤーの保存期間 aggregation.window-seconds が値以下の場合、データが失われる可能性があります。

属性のタイプ

設計上の最も重要な考慮事項は、インデックス レイヤーを作成するときにインデックス付け属性を選択することです。 これらのインデックス付け属性は、インデックス レイヤーの作成後は変更できません。 インデックス付け属性について考える 1 つの方法は、インデックス付けされたデータのクエリに使用する特性を考慮することです。

たとえば、次のユースケースについて考えてみます。 車両センサデータのインデックスを作成する予定で、地理的に異なる時間帯に発生するさまざまなイベントについて理解したいと考えています。 このユースケースでは、イベントタイプ、地理位置情報、タイムスタンプなどの複数の特性についてインデックス化されたデータを照会します。 したがって、次のインデックス属性を使用してインデックス レイヤーを設計します。

• 名前 : eventType、タイプ : 文字列。 値の例 : fogHazard
• name: tileId, type:heretile ( 必要なズーム レベルを含む ) 値の例 : 95140
• name: eventTime, type:timewindow ( タイムスライスの所要時間を指定 ) 値の例 : 1547053200000

timewindow 属性は常に含める必要があります。 追加属性の最大数は 3 です。

属性および属性値の数を制限します

小さいファイルの問題は、ビッグデータドメインでよく知られている問題です。 問題は、データが多数の小さいファイルまたは非常に小さいファイルに分割された場合、それらのファイルの処理が非常に非効率になることです。 HERE platform のインデックス作成では、データアーカイブライブラリが過度のパーティション分割を行うことで、この問題を引き起こす可能性があります。 インデックス レイヤーでは、属性と属性の値が多いほど、小さなファイルの問題が発生する可能性が高くなります。

インデックス レイヤー内のファイルのサイズは、データアーカイブライブラリによって生成されたパーティションの数に反比例します。 このため、インデックス付けのアプローチを決定する際には、十分に注意する必要があります。 潜在的なパーティションの合計数は、すべての属性のパーティションのデカルト積と等しくなります。 つまり、各属性内の属性の数と一意の値の最大数の両方を、特定のデータセットで可能な限り小さくする必要があります。 たとえば、属性の値の数が制限されていない限り、 4 つ以上の属性を使用することは推奨されません。 多くの場合、属性timewindow（通常はデータに応じて 1 時間から 1 日）、location（低タイルレベルの HERE Tile ）、追加属性を指定するだけで十分です。

location 属性のタイルレベルを特定する場合は、特に注意してください。 地図カタログの一般的なアプローチでは、その場所はタイルレベル 12 の HERE Tile として表されますが、インデックス作成には適していません。 location 属性に指定できる値の数は、タイムウィンドウごとに 1,000 ～ 10,000 の範囲にする必要があります。

計算例

次のデータストリームの特性を想定してみましょう。

• ストリームレートは、 1 秒あたり 1,000 メッセージです
• 各メッセージは 2 KB です
• データは 1 時間単位で集計されます ( timewindow 属性 ) 。
• 残りの 2 つの属性は location ( 遺伝的 ) で event-type 、カーディナリティは 5 です
• データは location 属性と event-type 属性に均等に分散されます

したがって、 1 時間あたりのデータ量は次のとおりです。

7.2 GB (1,000 x 3,600 x 2KB=7.2 GB)

1 時間あたりのデータ量 event-type は次のとおりです。

1.44 GB （ 7.2 GB/5 = 1.44 GB ）

個々のデータファイルは、 1 ～ 10 MB の範囲にすることをお勧めします。 これは、位置のカーディナリティを 20 ～ 700 にして、目的のタイルレベルを 3 ～ 5 にすることができることを意味します ( 位置ポリゴンの正方形のバウンディング ボックスを想定 ) 。 実際には、カーディナリティが高いほど、インデックス作成プロセスに必要な作業者数（並列化）が増加します。

の設定例を次に示します SimpleUDF。 この設定は、 10 分、 30 分、 1 時間など、さまざまな集約ウィンドウ間隔で有効です。

avg input data size throughput: 5 GB/hour
avg data size: 10k
duration slice for indexing attribute of time window type: 60 mins
number of event types: 8
number of tile ids: 10000
workers: ~ 12 - 15 (each worker with 1 worker unit i.e. 1 CPU - 7 GB RAM - 8 GB Disk Space)

次に、の設定例を示し MultiKeysUDFます。

avg input data size throughput: 5 GB/hour
avg data size: 10k
duration slice for indexing attribute of time window type: 60 mins
number of event types: 10
number of tile ids: 6000
workers: ~ 20 - 25 (each worker with 1 worker unit i.e. 1 CPU - 7 GB RAM - 8 GB Disk Space)
aggregation window interval: 30 mins
expected message duplication: 3 times [because cardinality of indexing attributes is 3 (3 event types * 1 tile id * 1 ingestionTime)]

推奨されるデータ形式の種類

Protobuf 、 Avro 、および Parquet は、データアーカイブライブラリを使用してデータをインデックス化する場合に推奨されるデータ形式です。 これらの形式にはそれぞれ独自の長所と短所があり、以下に要約します。

Protobuf

Protobuf はデータの転送や処理に適した形式ですが、データストレージには適していません。 データファイルの外部にあるスキーマが必要です。 もう 1 つの問題は、 Apache Spark や Flink などの主要な処理フレームワークによる比較的弱いサポートです。

Avro

Avro は、行指向のデータストレージでよく使用されている自己記述型のデータ形式です。 スキーマの進化を強力にサポートし、データを順次処理または変換する必要があるジョブに適しています。

寄木細工

Parquet は、主要な列データ形式の 1 つです。 大量のデータを保存する場合は、ファイル内のデータが内部的に編成されているため、圧縮特性が良好であるため、この方法を使用するとよいでしょう。 この形式のもう 1 つの長所は、データのアナリティクスの実行や、データのフィルタリングおよび集約操作を実行するクエリの実行に適していることです。