ビッグデータの概念と用語の紹介

処理される情報の膨大な規模は、ビッグデータシステムの定義に役立ちます。 これらのデータセットは、従来のデータセットよりも桁違いに大きくなる可能性があり、処理とストレージのライフサイクルの各段階でより多くの考慮が必要になります。

多くの場合、作業要件が1台のコンピューターの能力を超えるため、これはコンピューターのグループからのリソースのプール、割り当て、および調整の課題になります。 タスクを小さな断片に分割できるクラスター管理とアルゴリズムがますます重要になっています。

ビッグデータが他のデータシステムと大きく異なるもう1つの方法は、情報がシステム内を移動する速度です。 多くの場合、データは複数のソースからシステムに流れ込み、多くの場合、リアルタイムで処理されて洞察を得て、システムの現在の理解を更新します。

ほぼ瞬時のフィードバックに焦点が当てられているため、多くのビッグデータの実践者は、バッチ指向のアプローチから離れ、リアルタイムストリーミングシステムにより近くなりました。 新しい情報の流入に対応し、重要な情報を最も関連性の高い時期に早期に明らかにするために、データは絶えず追加、マッサージ、処理、分析されています。 これらのアイデアには、データパイプラインに沿った障害から保護するために、可用性の高いコンポーネントを備えた堅牢なシステムが必要です。

ビッグデータの問題は、処理対象のソースとその相対的な品質の両方の範囲が広いため、しばしば独特です。

データは、アプリケーションログやサーバーログなどの内部システム、ソーシャルメディアフィードやその他の外部API、物理デバイスセンサー、その他のプロバイダーから取り込むことができます。 ビッグデータは、すべての情報を単一のシステムに統合することにより、どこから来たとしても潜在的に有用なデータを処理しようとします。

メディアの形式と種類も大きく異なります。 画像、ビデオファイル、音声録音などのリッチメディアは、テキストファイル、構造化ログなどと一緒に取り込まれます。 従来のデータ処理システムでは、既にラベル付け、フォーマット、および編成されたパイプラインにデータが入ると予想される場合がありますが、ビッグデータシステムは通常、生の状態に近いデータを受け入れて保存します。 理想的には、生データに対する変換または変更は、処理時にメモリ内で発生します。

さまざまな個人や組織が元の3つのVを拡張することを提案していますが、これらの提案はビッグデータの品質よりも課題を説明する傾向があります。 一般的な追加は次のとおりです。

ビッグデータの品質のために、個々のコンピューターはほとんどの段階でデータを処理するには不十分であることがよくあります。 ビッグデータの高いストレージと計算のニーズによりよく対応するには、コンピュータークラスターの方が適しています。

ビッグデータクラスタリングソフトウェアは、多くの小型マシンのリソースを組み合わせて、多くの利点を提供しようとしています。

クラスターを使用するには、クラスターメンバーシップの管理、リソース共有の調整、および個々のノードでの実際の作業のスケジューリングのためのソリューションが必要です。 クラスターメンバーシップとリソース割り当ては、Hadoop’s YARN（Yet Another Resource Negotiatorの略）やApache Mesosなどのソフトウェアで処理できます。

組み立てられたコンピューティングクラスタは、多くの場合、他のソフトウェアがデータを処理するためにインターフェイスする基盤として機能します。 コンピューティングクラスタに関与するマシンは、通常、分散ストレージシステムの管理にも関与します。これについては、データの永続性について説明するときに説明します。

データの取り込みは、生データを取得してシステムに追加するプロセスです。 この操作の複雑さは、データソースの形式と品質、および処理前のデータが望ましい状態からどの程度離れているかに大きく依存します。

ビッグデータシステムにデータを追加できる1つの方法は、専用の取り込みツールです。 Apache Sqoopのようなテクノロジーは、リレーショナルデータベースから既存のデータを取得し、それをビッグデータシステムに追加できます。 同様に、Apache FlumeとApache Chukwaは、アプリケーションとサーバーのログを集約してインポートするように設計されたプロジェクトです。 Apache Kafkaのようなキューイングシステムは、さまざまなデータジェネレータとビッグデータシステム間のインターフェイスとしても使用できます。 Gobblinのような取り込みフレームワークは、取り込みパイプラインの最後でこれらのツールの出力を集約および正規化するのに役立ちます。

通常、摂取プロセス中に、ある程度の分析、ソート、およびラベル付けが行われます。 このプロセスはETLと呼ばれることもあり、これは抽出、変換、およびロードの略です。 この用語は従来、レガシーデータウェアハウジングプロセスを指していますが、同じ概念のいくつかがビッグデータシステムに入るデータにも適用されます。 一般的な操作には、受信データの変更によるフォーマット、データの分類とラベル付け、不要または不良データのフィルタリング、特定の要件に準拠していることの検証などが含まれます。

これらの機能を念頭に置いて、理想的には、パイプラインでさらに柔軟性を高めるために、キャプチャしたデータを可能な限り生のままにしておく必要があります。

通常、取り込みプロセスは、ストレージを管理するコンポーネントにデータを渡すため、データを確実にディスクに永続化できます。 これは簡単な操作のように見えますが、着信データの量、可用性の要件、および分散コンピューティングレイヤーにより、より複雑なストレージシステムが必要になります。

これは通常、生データストレージ用に分散ファイルシステムを活用することを意味します。 Apache Hadoop’s HDFSファイルシステムのようなソリューションでは、クラスター内の複数のノードにまたがって大量のデータを書き込むことができます。 これにより、計算リソースからデータにアクセスでき、インメモリ操作のためにクラスターのRAMにロードでき、コンポーネントの障害を適切に処理できます。 CephやGlusterFSなど、他の分散ファイルシステムをHDFSの代わりに使用できます。

より構造化されたアクセスのために、データを他の分散システムにインポートすることもできます。 分散データベース、特にNoSQLデータベースは、多くの場合同じフォールトトレラントを考慮して設計され、異種データを処理できるため、この役割に適しています。 データの整理方法と表示方法に応じて、さまざまな種類の分散データベースから選択できます。 いくつかのオプションとそれらが最も役立つ目的の詳細については、NoSQL comparison guideをお読みください。

データが利用可能になると、システムはデータの処理を開始して実際の情報を明らかにすることができます。 必要な洞察の種類に応じて要件と最適なアプローチが大きく異なる可能性があるため、計算層はおそらくシステムの最も多様な部分です。 多くの場合、データは単一のツールで繰り返し処理されるか、さまざまな種類の洞察を得るために多数のツールを使用して繰り返し処理されます。

Batch processingは、大規模なデータセットを計算する1つの方法です。 このプロセスでは、作業を小さなピースに分割し、個々のマシンで各ピースをスケジューリングし、中間結果に基づいてデータを再編成し、最終結果を計算して組み立てます。 これらのステップは、しばしば個別に分割、マッピング、シャッフル、削減、およびアセンブルと呼ばれるか、または集合的に分散マップ削減アルゴリズムと呼ばれます。 これは、Apache Hadoop’s MapReduceで使用される戦略です。 バッチ処理は、かなりの計算を必要とする非常に大きなデータセットを扱うときに最も役立ちます。

バッチ処理は特定のタイプのデータと計算に適していますが、他のワークロードではより多くのreal-time processingが必要です。 リアルタイム処理では、情報をすぐに処理して準備する必要があり、新しい情報が利用可能になるとシステムが対応する必要があります。 これを実現する1つの方法は、stream processingです。これは、個々のアイテムで構成されるデータの連続ストリームを操作します。 リアルタイムプロセッサのもう1つの一般的な特性は、インメモリコンピューティングです。これは、クラスタのメモリ内のデータの表現と連携して、ディスクに書き戻す必要がないようにします。

Apache Storm、Apache Flink、およびApache Sparkは、リアルタイムまたはほぼリアルタイムの処理を実現するさまざまな方法を提供します。 これらの各テクノロジーにはトレードオフがあり、個々の問題に最適なアプローチに影響を与える可能性があります。 一般に、リアルタイム処理は、システムに急速に変化または追加されている小さなデータチャンクの分析に最適です。

上記の例は、計算フレームワークを表しています。 ただし、ビッグデータシステム内でデータを計算または分析する方法は他にもたくさんあります。 これらのツールは、しばしば上記のフレームワークにプラグインし、基礎となるレイヤーと対話するための追加のインターフェースを提供します。 たとえば、Apache HiveはHadoopのデータウェアハウスインターフェイスを提供し、Apache Pigは高レベルのクエリインターフェイスを提供しますが、データとのSQLのような相互作用は、Apache Drill、Apache Impalaなどのプロジェクトで実現できます。 ）s、Apache Spark SQL、およびPresto。 機械学習の場合、Apache SystemML、Apache Mahout、Apache Spark’s MLlibなどのプロジェクトが役立ちます。 ビッグデータエコシステムで広くサポートされているストレート分析プログラミングでは、RとPythonの両方が一般的な選択肢です。

ビッグデータシステムで処理される情報のタイプにより、時間の経過に伴うデータの傾向や変化を認識することは、値自体よりも重要であることがよくあります。 データを視覚化することは、トレンドを見つけて多数のデータポイントを理解するための最も便利な方法の1つです。

リアルタイム処理は、アプリケーションとサーバーのメトリックを視覚化するために頻繁に使用されます。 データは頻繁に変更され、メトリックの大きなデルタは通常、システムまたは組織の健全性に重大な影響があることを示しています。 このような場合、Prometheusのようなプロジェクトは、データストリームを時系列データベースとして処理し、その情報を視覚化するのに役立ちます。

データを視覚化する一般的な方法の1つは、以前はELKスタックと呼ばれていたElastic Stackを使用することです。 データ収集用のLogstash、データのインデックス作成用のElasticsearch、および視覚化用のKibanaで構成されたElastic Stackは、ビッグデータシステムで使用して、計算結果または生のメトリックと視覚的にインターフェースできます。 同様のスタックは、インデックス作成にApache Solrを使用し、視覚化にBananaと呼ばれるKibanaフォークを使用して実現できます。 これらによって作成されたスタックはSilkと呼ばれます。

インタラクティブなデータサイエンスの作業で一般的に使用される別の視覚化テクノロジは、データの「ノートブック」です。 これらのプロジェクトは、共有、提示、または共同作業に役立つ形式でのデータのインタラクティブな調査と視覚化を可能にします。 このタイプの視覚化インターフェースの一般的な例は、Jupyter NotebookとApache Zeppelinです。