最新のデータ ウェアハウスのファイル形式と構造を理解する
データ ウェアハウスにデータを読み込む場合、ファイルの種類やデータを取り込む方法はソースによって異なります。 たとえば、オンプレミスのファイル システム、リレーショナル データ ストア、またはストリーミング データ ソースからデータを読み込む場合、データ レイクや中間データ ストアへのインジェストから、整理されたデータのサービング レイヤーへの配置まで、さまざまなアプローチが必要になります。 さまざまなファイルの種類と、生の保存と分析クエリ用の整理されたバージョンのどちらのために使用するかを理解することが重要です。 また、クエリやデータの読み込み作業を最適化するための階層構造なども考慮に入れて設計します。 このユニットでは、ファイルの種類とその最適な使用例、データ レイクでの最適な整理方法について説明します。
生データをバッチで取り込む場合にサポートされるファイル形式
Data Engineering では、データの読み込み速度を次の 3 つの待機時間の 1 つとして説明する傾向があります。
- バッチ: 完了するまでに数十分、数時間、または数日かかるクエリまたはプログラム。 アクティビティには、初期のデータ ラングリング、完全な ETL パイプライン、ダウンストリーム分析の準備などがあります。
- 対話型クエリ: "人間" の対話の速度でバッチ データのクエリを実行すること。現世代のテクノロジでは、秒単位から分単位の時間で結果を得られます。
- リアルタイムまたは準リアルタイム: 通常は無限に続く入力データ (ストリーム) の処理。短時間で結果を得られます (ミリ秒単位から長くても秒単位)。
新しいデータ ソースから生データをバッチで取り込む場合、次のデータ形式が Synapse でネイティブにサポートされています。
- CSV
- Parquet
- ORC
- JSON
ただし、Synapse Notebooks で Apache Spark を使用している場合は、お使いの生データに合わせてその他のファイルの種類を調べて処理することができます。
Synapse 専用 SQL プールにストリーミング データを取り込む
届くデータを 3 つ目の待機時間 (リアルタイムまたは準リアルタイム) で処理することは、ストリーミング データ処理とも呼ばれます。 ストリーミング データ ソースには、IoT デバイスとセンサー、金融取引、Web クリックストリーム データ、ファクトリ、医療機器などがあります。
Azure には、Azure IoT Hub や Azure Event Hubs など、(Kafka のサポートの有無にかかわらず) 堅牢で、実績があり、ハイ パフォーマンスの、目的に応じたストリーム インジェスト サービスが用意されています。サービスです。 データ パイプラインでは、このような、または同様のサービスからメッセージを収集し、Azure Stream Analytics、Azure Functions、Azure Databricks、またはストリーミング データの取り込みと処理を実行できるその他のサービスを使用して処理する必要があります。
たとえば、このデータを Synapse Analytics ワークスペースに関連付けられた Azure Data Lake Storage (ADLS) Gen2 アカウントなどのデータ レイクに配置し、サーバーレス SQL プールに Synapse Spark ノートブックまたは T-SQL クエリを使用してデータを調べ、変換することが目標だとします。 この場合、通常は、そのデータを CSV や JSON などの生の形式のいずれかで保存します。 Azure Stream Analytics を使用して、入力ソースとして IoT Hub または Event Hubs に接続し、出力として ADLS Gen2 ストレージ アカウントにファイルを出力することで、このタスクを簡略化することができます。 パス パターンを指定できます。これは、最適な分析ワークロードのためにパスベースのデータの排除によってデータを構造化するために役立ちます。 たとえば、ADLS Gen2 の出力に tran/sensor/{datetime:yyyy}/{datetime:MM}/{datetime:dd} というパス パターンを設定できます。 さらに、オプションを使用して、JSON などのシリアル化、UTF-8 などのエンコード、100 などの 1 ファイルあたりの最小行数などを設定できます。
ただし、ストリーミング データを専用 SQL プールに格納する場合は、いくつかの選択肢がありますが、前述のように、まずデータを処理してデータ レイクに格納します。 次に、Synapse Pipelines、Synapse Spark プール、COPY ステートメントなどのさまざまなデータの読み込み手法のいずれかを使用して、データを専用 SQL プールに読み込みます。 これにより、データ レイクをステージング領域として使用することや、生の形式をデータ レイク内に保持しながら、より整理されたバージョンのデータを専用 SQL プール内に保持することができます。
もう 1 つの選択肢は、Azure Stream Analytics ジョブによる高スループットのデータ インジェストの出力シンクとして、Azure Synapse Analytics (専用 SQL プール) を使用することです。
Synapse Analytics の出力を作成したら、Stream Analytics のクエリでターゲットとしてそれを設定することができます。 次の例では、CallStream という名前の Event Hubs の入力と、sqlpool-demo-asaoutput という名前の Synapse Analytics の出力があります。 この SQL クエリを実行すると、単にすべての受信データが専用 SQL プールに直接書き込まれます。 また、受信ストリームから特定のプロパティのみを選択してデータ型を変換し、ウィンドウ関数のいずれかを使用してデータを集計してから、専用 SQL プールに書き込むこともできます。
この方法で Stream Analytics を Synapse Analytics と併用すると、Stream Analytics クエリによってストリーミング データが書き込まれる専用 SQL プールのデータベースとテーブルを選択することができます。 このネイティブのストリーム インジェストは、データをどこか他の場所に格納することなく、専用 SQL プールにデータを迅速に直接書き込むように最適化されています。
推奨されるファイルの種類
生データ
生データの場合、データをネイティブ形式で格納することをお勧めします。 リレーショナル データベースのデータは、通常、CSV 形式で格納します。 これは、ほとんどのシステムでサポートされている形式であり、最も柔軟性があるためです。
Web API と NoSQL データベースのデータの場合は、JSON が推奨される形式です。
整理されたバージョンのデータ
クエリに備えて整理されたバージョンのデータを格納する場合、推奨されるデータ形式は Parquet です。
ストレージ層でデータを共有する場合 (Hadoop、Databricks、SQL エンジンのシナリオなど) の Parquet 形式については、業界内で調整されています。 Parquet は、ビッグ データのシナリオに最適化されたハイ パフォーマンスな列指向形式です。
Parquet のような列形式には、ストレージとパフォーマンスの利点があります。 値は列ごとにクラスター化されるので、圧縮の効率が高くなります (ストレージの占有領域が小さくなります)。また、クエリ エンジンにより、列のプロジェクションをプッシュ ダウンすることができます (不要な列をスキップすることで、ネットワークとディスクからの読み取り I/O を減らすことができます)。これは、列の排除とも呼ばれます。 (列の) 同様のデータ型が Parquet ファイルに一緒に格納されるため、効率的なデータ圧縮とエンコード スキーマを実現できます。
Parquet により、ファイルのメタデータにファイル スキーマが格納されます。 CSV ファイルにはファイルのメタデータが格納されないため、読み取り側は、スキーマを提供されるか、スキーマを推測する必要があります。 スキーマの提供は手間がかかり、スキーマの推測はエラーが発生しやすく、コストがかかります。
分析クエリのためにファイル構造を整理する
データ レイクにデータを取り込むときに最初に考慮すべきことは、データ レイク内のデータをどのように構造化または整理するかということです。 Azure Data Lake Storage (ADLS) Gen2 を使用することをお勧めします (Azure portal 内では、これは階層型名前空間が有効な Azure Storage アカウントのことです)。
ADLS Gen2 の主要なメカニズムにより、階層型名前空間に加えて、オブジェクト ストレージの規模と価格でファイル システムのパフォーマンスを実現できます。 これにより、コンピューター上のファイル システムを編成するのと同じ方法で、アカウント内のオブジェクト/ファイルのコレクションを、ディレクトリおよびネストされたサブディレクトリの階層に編成できるようになりました。 階層型名前空間を有効にすると、ストレージ アカウントは、分析エンジンと分析フレームワークでよく用いられるファイル システム セマンティクスを使用して、オブジェクト ストレージのスケーラビリティとコスト効果を提供することができます。
ADLS Gen2 では、運用環境専用のストレージ アカウントを用意し、開発とテストのワークロードには別のストレージ アカウントを用意するのがベスト プラクティスです。 こうすることで、開発やテストのワークロードが運用環境の支障にならなくなります。
データ レイク内のフォルダーを構成する一般的な方法は、整理度別に分けたフォルダーでデータを整理することです。 たとえば、bronze フォルダーには生データ、silver フォルダーにはクリーニング、準備、統合が完了したデータ、gold フォルダーには分析をサポートする準備が整ったデータ (事前にコンピューティングされた集計値などの最終的な調整などを含む) を格納します。 さらに調整レベルが必要な場合は、必要に応じてこの構造を変更し、フォルダー数を増やすことができます。
Data Lake Storage Gen2 を使用する場合には、次の点を考慮する必要があります。
- データが Data Lake Storage Gen2 に保存されると、ファイル サイズ、ファイル数、およびフォルダー構造がパフォーマンスに影響を与えるようになります。
- データを多数の小さなファイルとして保存すると、パフォーマンスに悪影響を及ぼすことがあります。 一般的に、データを大きなサイズ (256 MB から 100 GB のサイズ) のファイルに整理するとパフォーマンスが向上します。
- エンジンとアプリケーションの中には、サイズが 100 GB を超えるファイルを効率的に処理できないものもあります。
- 場合によっては、データ パイプラインで小さなファイルを多数含む生データの制御が制限されることがあります。 ダウンストリーム アプリケーションでは、"調理" のプロセスを設けて、より大きいファイルを生成することをお勧めします。