がたくさんあります データのスケーラビリティの利点。 企業が処理しなければならないデータのサイズと多様性は、より複雑で大きくなっています。
従来のリレーショナルデータベースには一定の利点がありますが、大きくてさまざまなデータを処理するのには適していません。 その時 データレイク 製品の人気が高まり始め、それ以来、より多くの企業がデータインフラストラクチャの一部としてレイクソリューションを導入しました。 データソリューションの需要が高まるにつれ、AWSのようなクラウド企業も参入し、AWSAthenaとS3でマネージドデータレイクソリューションの提供を開始しました。 これらのサービスには、強力で便利な機能があります。 ただし、すべてのユーザーとユースケースに最適というわけではありません。 この記事では、AthenaとS3のインデックス作成の欠点と、それらに対処する方法について説明します。
AWSAthenaとS3
AWSAthenaとS3は別々のサービスです。 AWS Athenaは、ユーザーが標準のSQL構文を使用してS3のデータを分析できるようにするクエリサービスです。 Athenaはサーバーレスであり、AWSによって管理されています。 Athenaと他のAWSサーバーレスサービスは同様の料金体系を持っています-それはあなたが使用したものに対してのみ支払うことができます。 S3は、AWSの第3世代サービスのXNUMXつです。 さまざまな種類のファイルを保存して、クラウドストレージのように使用できます。 両方を組み合わせて、SQLを使用してSXNUMXに保存されているものをクエリします。
アテナの限界
Athenaには優れた機能があり、コスト面でメリットがありますが、使用すると、Athenaにはいくつかの制限があります。
共有リソース
Athenaを使用する場合、クエリを実行するための計算リソースは制御できるものではありません。 Athenaクエリを実行すると、リクエストはリージョン内のすべてのAthenaユーザーからの共有キューに送られ、AWSはリクエストされたクエリを順番に処理します。 つまり、忙しい時間にクエリを実行する場合は、次のことを行う必要があります。 もっと長く待つ クエリを処理して結果を返すため。 この環境では、一貫したパフォーマンスを保証できず、顧客とのサービス契約に悪影響を与える可能性があります。
インデックス機能
従来のリレーショナルデータベースエンジンでは、ユーザーはパフォーマンスを向上させるためにインデックス作成を計画できます。 ただし、Athenaはデフォルトでインデックス作成を使用しません。 クエリを実行すると、AthenaはターゲットのS3バケットに移動し、クエリのリクエストを満たすまで各ファイルのオープンを開始します。 たとえば、データが最後のファイルにある場合、最初にスキャンしたファイルからデータを見つける場合よりもクエリに時間がかかります。 データサイズが小さい場合は、あまり違いがない場合があります。 ただし、データが大きい場合、これは大きな違いになります。 このパフォーマンスの問題を軽減するには、 AWSはパーティショニングを推奨しています.
パーティションの制限
データをパーティション化することで、クエリのパフォーマンスを向上させることができます。 ただし、パーティショニングにも限界があり、使い勝手が悪い。 分割する列に基づいて慎重に決定する必要があります。 間違った列を選択した場合、パーティションを再作成すると、データ全体を新しいバケットの場所に移動し、新しいバケットの場所を参照するようにテーブルを変更してから、古いデータを削除できます。
Athenaはファイルシステムのように機能するデータストレージを使用するため、行または列レベルで更新または削除することはできません。 または、CTAS（テーブルASの作成）またはINSERTIGNOREINTOクエリを実行することもできます。 ただし、これらを使用する場合、宛先テーブルに作成できるパーティションは最大100個までです。 それは十分に大きく聞こえるかもしれません。 パーティショニングに使用するベースカラムによっては、予想外に速くその制限に達する可能性があります。
インデックス作成を改善する方法
問題があるときはチャンスになります。 Athenaは最も人気のあるデータレイククエリサービスのXNUMXつであるため、多くのユーザーがこれらの問題を経験し、企業は不便さとパフォーマンスの問題を排除するためのソリューションを開発しています。 AWS内の欠点を克服するのが難しい場合、人々は解決策を見つけるために外を見ることがあります。
AWSのインデックス作成とパーティション分割の制限について、ユーザーは次のことを検討できます。 バラダのビッグデータインデックス技術; ワークロードの要求に応じて列に自動的にインデックスを付けます。 それらのインデックスデータは、任意の列のデータをナノブロックに分割し、データの内容と構造を考慮して、各ナノブロックの最も効率的なインデックスを自動的に選択します。 バックエンドでは、機械学習最適化ツールがクラスターのパフォーマンスとデータ使用量を監視して、ボトルネックとクエリのパフォーマンスを検出します。 最適化の機会が見つかると、自動的に改善が適用されます。
その結果、クエリ結果が高速になり、コストが最適化されます。 このソースは、さまざまなメトリック間でパフォーマンスの比較を共有します。 顕著な違いのXNUMXつは、最初の実験です。 クエリは、以下のように特定のIDと特定の時間範囲を見つけることでした。
...
FROM demo_trips.trips_data
WHERE rider_id = 3380311
AND t_hour between 7 AND 10
結果は示した アテナは40.96秒かかり、132.0GBがスキャンされ、バラダは0.57秒と245KBがスキャンされました。
包み込む
結果は、パーティションによっては大きな違いがある可能性があることを示しています。 データエンジニアリングでは、パーティショニング以外にも、注意が必要な領域がたくさんあります。 エンジニアがパーティショニングを管理する必要がある場合、他の重要なタスクの速度が低下する可能性があります。 AWSにデータレイクインフラストラクチャがある場合、Varadaのようなサードパーティのソリューションに依存することを検討できます。
