編集

バッチ処理

Encoding

ビッグ データの一般的なシナリオは、保存されたデータのバッチ処理です。 このシナリオでは、ソース アプリケーション自体またはオーケストレーション ワークフローによって、ソース データがデータ ストレージに読み込まれます。 その後、データは、並列化されたジョブによってインプレースで処理されます。これは、オーケストレーション ワークフローによって開始することもできます。 処理には複数の反復手順が含まれることがあり、処理後の変換された結果が分析データ ストアに読み込まれ、分析およびレポート コンポーネントによるクエリを実行できます。

たとえば、Web サーバーからのログがフォルダーにコピーされた後、夜間処理されて、Web アクティビティの日次レポートが生成されます。

バッチ処理パイプラインの図

このソリューションを使用する状況

バッチ処理は、単純なデータ変換からより完全な ETL (抽出-変換-読み込み) パイプラインに至るまで、さまざまなシナリオで使用されます。 ビッグ データのコンテキストでは、バッチ処理は非常に大きなデータ セットを操作する可能性があり、計算にかなりの時間がかかります (例については、「Lambda architecture」(ラムダ アーキテクチャ) を参照してください)。バッチ処理は、通常は、さらに対話型で調査することに至り、機械学習用のモデル化の準備が完了したデータを提供したり、分析とビジュアル化用に最適化されたデータ ストアにデータを書き込んだりします。

バッチ処理の 1 つの例は、フラットな半構造化 CSV ファイルまたは JSON ファイルの大規模なセットを、さらにクエリを実行できる準備が整ったスキーマ化され、構造化された形式に変換することです。 通常、データは、取り込みに使用される生の形式 (CSV など) から、クエリを効率的に実行できるバイナリ形式に変換されます。これが行われるのは、データが列形式で格納され、多くの場合、データに関するインデックスとインライン統計が用意されるためです。

課題

  • データの形式とエンコード。 デバッグ時の最も困難な問題の一部は、予期しない形式またはエンコードがファイルで使用されている場合に発生します。 たとえば、ソース ファイルで UTF-16 と UTF-8 エンコードの両方が使用されていたり、予期しない区切り文字 (スペースやタブ) や予期しない文字が含まれていたりすることがあります。 別の一般的な例は、区切り記号として解釈されるタブ、スペース、またはコンマが含まれているテキスト フィールドです。 データの読み込みと解析ロジックは、これらの問題を検出して処理するのに十分な柔軟性を持っている必要があります。

  • タイム スライスの調整。 多くの場合、ソース データは、年、月、日、時間別に整理された処理時間を反映するフォルダー階層に配置されます。 場合によっては、データが遅れて到着することがあります。 たとえば、Web サーバーが失敗し、3 月 7 日のログが 3 月 9 日までフォルダーに保存されないとします。 遅すぎたためにそれらは単純に無視されるのでしょうか。 下流の処理ロジックは順序がばらばらのレコードを処理できるでしょうか。

アーキテクチャ

バッチ処理アーキテクチャには、上の図に示した次の論理コンポーネントがあります。

  • データ ストレージ。 通常は、さまざまな形式の大量の大容量ファイルのリポジトリとして機能できる分散ファイル ストアです。 一般的に、この種類のストアは、しばしばData Lake と呼ばれます。

  • バッチ処理。 ビッグ データの大容量という性質は、多くの場合、ソリューションで、実行時間の長いバッチ ジョブを使用してデータ ファイルを処理し、フィルター処理や集計などを行って分析用のデータを準備する必要があることを意味します。 通常、これらのジョブには、ソース ファイルの読み取り、ソース ファイルの処理、新しいファイルへの出力の書き込みが含まれます。

  • 分析データ ストア。 多くのビッグ データ ソリューションは、分析用にデータを準備した後、処理されたデータを分析ツールを使用してクエリを実行できる構造化された形式で提供するように設計されています。

  • 分析とレポート。 ほとんどのビッグ データ ソリューションの目的は、分析とレポートによってデータに関する実用的な情報を提供することにあります。

  • オーケストレーション。 バッチ処理では、通常は、データ ストレージ、バッチ処理、分析データ ストア、およびレポート層にデータを移行するかコピーするための何らかのオーケストレーションが必要です。

テクノロジの選択

次のテクノロジは、Azure でのバッチ処理に推奨される選択肢です。

データ ストレージ

  • Azure Storage Blob コンテナー。 多くの既存の Azure のビジネス プロセスでは、既に Azure Blob Storage を活用しているため、ビッグ データ ストア向けの適切な選択肢になっています。
  • Azure Data Lake Store。 Azure Data Lake Store は、任意のサイズのファイルを格納できる豊富なセキュリティ オプションを備えた実質的に無制限のストレージであり、異種形式のデータの一元的なストアを必要とする非常に大規模なビッグ データ ソリューションに適した選択肢です。

詳しくは、データ ストレージに関するページをご覧ください。

バッチ処理

  • U-SQL。 U-SQL は、Azure Data Lake Analytics によって使用されるクエリ処理言語です。 それは、SQL の宣言型の性質を C# の手続き型の拡張性と組み合わせたものであり、並列性を利用してデータを大規模に効率的に処理できるようにします。
  • Hive。 Hive は、HDInsight を含む大半の Hadoop ディストリビューションでサポートされている SQL に似た言語です。 Azure Blob Storage と Azure Data Lake Store を含む HDFS と互換性のあるストアのデータを処理するために使用できます。
  • Pig。 Pig は、HDInsight を含む多数の Hadoop ディストリビューションで使用される、宣言型のビッグ データ処理言語です。 非構造化または半構造化データを処理するために特に便利です。
  • Spark。 Spark エンジンは、Java、Scala、および Python を含むさまざまな言語で記述されたバッチ処理プログラムをサポートします。 Spark は、分散アーキテクチャを使用して、複数の worker ノード間でデータを並列で処理します。

詳しくは、バッチ処理に関するページをご覧ください。

分析データ ストア

  • Azure Synapse Analytics。 Azure Synapse は、SQL Server データベース テクノロジに基づく管理対象サービスであり、大規模なデータ ウェアハウスのワークロードをサポートするように最適化されています。
  • Spark SQL。 Spark SQL は Spark 上に構築された API で、SQL 構文を使用してクエリを実行できるデータフレームとテーブルの作成をサポートします。
  • HBase。 HBase は、待ち時間の短い NoSQL ストアで、構造化および半構造化データに対してクエリを実行するための高パフォーマンスで柔軟なオプションを提供します。
  • Hive。 バッチ処理に適していることに加え、Hive は、概念的には一般的なリレーショナル データベース管理システムに類似するデータベース アーキテクチャを提供します。 Tez エンジンや Stinger Initiative などのイノベーションによる Hive クエリのパフォーマンスの向上は、シナリオによっては Hive テーブルを分析クエリのソースとして効率的に使用できることを意味します。

詳しくは、分析データ ストアに関するページをご覧ください。

分析とレポート

  • Azure Analysis Services。 多くのビッグ データ ソリューションでは、レポート、ダッシュボード、および対話型の "スライス アンド ダイス" 分析のベースにすることができる一元的なオンライン分析処理 (OLAP) データ モデル (しばしばキューブとも呼ばれます) を含めることによって、従来のエンタープライズ ビジネス インテリジェンス アーキテクチャをエミュレートします。 Azure Analysis Services では、このニーズを満たすために、表形式モデルの作成をサポートしています。
  • Power BI。 データ アナリストは、Power BI を使用して、OLAP モデル内のデータ モデルに基づいて、または分析データストアから直接、対話型のデータのビジュアル化を作成できます。
  • Microsoft Excel。 Microsoft Excel は、世界で最も広く使用されているソフトウェア アプリケーションの 1 つであり、豊富なデータ分析とビジュアル化の機能を備えています。 データ アナリストは、Excel を使用して、分析データ ストアからドキュメントのデータ モデルを構築したり、OLAP データ モデルから対話型のピボット テーブルとグラフにデータを取得したりできます。

詳しくは、分析とレポートに関するページをご覧ください。

オーケストレーション

  • Azure Data Factory。 Azure Data Factory パイプラインを使用して、繰り返されるテンポラル ウィンドウに合わせてスケジュールされた一連のアクティビティを定義できます。 これらのアクティビティでは、オンデマンド HDInsight クラスターの Hive、Pig、MapReduce、または Spark ジョブ、Azure Date Lake Analytics の U-SQL ジョブ、Azure Synapse または Azure SQL Database のストアド プロシージャと同じようにコピー操作を開始できます。
  • Oozie と Sqoop。 Oozie は、Apache Hadoop エコシステム向けのジョブ オートメーション エンジンであり、それを使用して、Hive、Pig、MapReduce ジョブと同じようにデータのコピー操作を開始してデータを処理でき、Sqoop ジョブと同じように HDFS データベースと SQL データベース間でデータをコピーできます。

詳細については、パイプラインのオーケストレーションに関するページを参照してください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

次のステップ

関連リソース