目次:
ビッグデータは、大量のデータの処理を指すために使用される包括的な言葉です。 データ量が多いほど、データが複雑になることは誰もが理解しています。 従来のデータベースソリューションは、その複雑さとサイズのために、大量のデータを適切に管理できないことがよくあります。 したがって、大量のデータを管理し、真の洞察を引き出すことは困難な作業です。 同じ「値」の概念は、小さなデータにも適用できます。
ビッグデータの使用方法
RDBMSコンセプトに基づく従来のデータベースソリューションは、トランザクションデータを非常にうまく管理でき、さまざまなアプリケーションで広く使用されています。 しかし、大量のデータ（アーカイブされ、テラバイトまたはペタバイト単位のデータ）の処理に関しては、これらのデータベースソリューションはしばしば失敗します。 これらのデータセットは大きすぎ、ほとんどの場合、従来のデータベースのアーキテクチャには適合しません。 最近、ビッグデータは、より大きなデータセットを処理するための費用対効果の高いアプローチになっています。 組織の観点から見ると、ビッグデータの使用は次のカテゴリに分類できます。ここでは、ビッグデータの実際の価値が存在します。- 分析的使用
ビッグデータのアナリストは、処理するにはコストがかかりすぎるデータの多くの重要な隠れた側面を明らかにしました。 たとえば、特定の新しいトピックに関する学生の関心の傾向を確認する必要がある場合、毎日の出席記録やその他の社会的および地理的事実を分析することでこれを行うことができます。 これらのファクトはデータベースにキャプチャされます。 効率的な方法でこのデータにアクセスできない場合、結果を見ることができません。
- 新製品を有効にする
最近では、Facebookなどの多くの新しいWeb企業が、新しい製品を発売するためのソリューションとしてビッグデータを使用し始めています。 Facebookの人気の高さは誰もが知っています。ビッグデータを使用して、高性能なユーザーエクスペリエンスを実現しました。
本当の価値はどこにありますか？
さまざまなビッグデータソリューションは、データを保存する方法が異なりますが、最終的にはすべてフラットデータ構造でデータを保存します。 一般に、Hadoopはファイルシステムとオペレーティングシステムレベルのデータ抽象化で構成されます。 これには、MapReduceエンジンとHadoop分散ファイルシステム（HDFS）が含まれます。 単純なHadoopクラスターには、1つのマスターノードと複数のワーカーノードが含まれます。 マスターノードは次のもので構成されます。- タスクトラッカー
- ジョブトラッカー
- 名前ノード
- データノード
- タスクトラッカー
- データノード
一部の実装にはデータノードのみがあります。 データノードは、データが存在する実際の領域です。 HDFSは、複数のマシンに分散した大きなファイル（テラバイトからペタバイトの範囲）を保存します。 すべてのノードのデータの信頼性は、すべてのホスト間でデータを複製することにより実現されます。 したがって、ノードの1つがダウンしていても、データは使用可能です。 これにより、クエリに対する応答が速くなります。 この概念は、Facebookのような巨大なアプリケーションの場合に非常に役立ちます。 ユーザーとして、たとえばほぼすぐに、チャット要求に対する応答を受け取ります。 ユーザーがチャット中に長時間待たなければならないシナリオを考えてみましょう。 メッセージとそれに続く応答がすぐに配信されない場合、実際にこれらのチャットツールを使用する人は何人ですか？
Facebookの実装に戻ると、データがクラスター間で複製されない場合、魅力的な実装を行うことはできません。 Hadoopは、より大きなクラスターのマシン間でデータを分散し、一連のブロックとしてファイルを保存します。 これらのブロックは、最後のブロックを除いて同じサイズです。 ブロックのサイズとレプリケーション係数は、必要に応じてカスタマイズできます。 HDFSのファイルは厳密に追記型のアプローチに従っているため、一度に1人のユーザーのみが書き込みまたは編集できます。 ブロックの複製に関する決定は、名前ノードによって行われます。 名前ノードは、各データノードからレポートとパルス応答を受け取ります。 パルス応答により、対応するデータノードの可用性が確保されます。 レポートには、データノードのブロックの詳細が含まれます。
別のビッグデータ実装であるCassandraも、同様の配信コンセプトを使用しています。 Cassandraは、地理的な場所に基づいてデータを配布します。 したがって、Cassandraでは、データはデータ使用の地理的位置に基づいて分離されます。
時には小さなデータがより大きな（そしてより安価な）影響を与える
Open Knowledge FoundationのRufus Pollockによれば、ビッグデータの周りに誇大広告を作成する意味はありませんが、小さなデータは依然として真の価値が存在する場所です。
名前が示すように、小さなデータとは、より大きなデータのセットからターゲットにされたデータのセットです。 小さなデータは、データの使用から焦点を移すことを意図しており、ビッグデータへの移行の傾向に対抗することも目的としています。 スモールデータアプローチは、少ない労力で特定の要件に基づいてデータを収集するのに役立ちます。 その結果、ビジネスインテリジェンスを実装する際のビジネスプラクティスがより効率的になります。
中核となる小さなデータの概念は、さらなるアクションを必要とする結果を必要とするビジネスを中心に展開します。 これらの結果は迅速に取得する必要があり、後続のアクションも迅速に実行する必要があります。 したがって、ビッグデータ分析で一般的に使用される種類のシステムを排除できます。
一般に、ビッグデータの取得に必要な特定のシステムの一部を考慮すると、企業は多くのサーバーストレージのセットアップに投資し、高度なハイエンドサーバーと最新のデータマイニングアプリケーションを使用してさまざまなデータを処理する場合があります、ユーザーアクションの日時、人口統計情報、その他の情報が含まれます。 このデータセット全体が中央のデータウェアハウスに移動し、そこで複雑なアルゴリズムを使用してデータを並べ替えて処理し、詳細なレポートの形式で表示します。
これらのソリューションは、スケーラビリティと可用性の点で多くのビジネスに利益をもたらしていることは誰もが知っています。 これらのアプローチを採用するには相当な努力が必要であると考える組織があります。 また、場合によっては、堅牢性の低いデータマイニング戦略を使用して同様の結果が得られることも事実です。
小さなデータは、組織がより洗練されたビジネスプロセスをサポートする最新および最新のテクノロジーへの執着から後退する方法を提供します。 小規模なデータを推進している企業は、ビジネスの観点から、リソースを効率的に使用することが重要であると主張しており、テクノロジーへの過剰な支出をある程度回避することができます。
ビッグデータとスモールデータの現実について多くのことを議論しましたが、正しい使用のために正しいプラットフォーム（ビッグデータまたはスモールデータ）を選択することが演習全体の最も重要な部分であることを理解する必要があります。 そして真実は、ビッグデータが多くの利点を提供できる一方で、常に最良とは限らないということです。
