Google、Facebook、Netflix、LinkedIn、Twitter、その他すべてのソーシャルメディアプラットフォームは、明らかにビッグデータテクノロジーセンターとしての資格があります。 しかし、彼らはいつ頃から、自分たちが持つデータを気にするようになったのでしょうか？ 答えは簡単です。ビッグデータの特性と、データ処理が5つのVs.を侵食し始める時期によって決まります。
では、ビッグデータの5つのVsを見てみましょう。
- Volume（データ量）
- Velocity（速度）
- Variety（多様性）
- Veracity（真実性）
- Varietyは、データの種類がどれだけ異質であるかを表します。
- Value（価値）：データの重要性
# Volume
データの量がエクサバイト、ペタバイト、またはそれ以上でなければ、本当の意味でビッグデータの世界にいるとは言えません。 AmazonやShopifyなどのEコマースプラットフォームのようなビッグデータ技術の巨人は、世界中の何百万人もの顧客、特にスマートフォンユーザーから、毎秒テラバイトからゼタバイトに及ぶリアルタイムの構造化データや非構造化データを入手しています。
どのような場合にボリュームが問題となるか
ウェブで検索してみると、10TBのハードディスクが最低でも300ドルすることがわかります。 1ペタバイトのデータを管理するには、100×300ドル＝30,000ドルとなります。 もしかしたら割引があるかもしれませんが、たとえ50％オフでも、ストレージのコストだけで1万ドルをはるかに超えてしまいます。 ディザスタリカバリのためにデータの冗長性を確保したい場合を想像してみてください。 そうなると、さらに多くのディスクスペースが必要になります。
ソリューション:
AWSが提供するマネージドクラウドデータウェアハウスサービスであるAmazon Redshiftは、ストレージの人気オプションの1つです。 複数のノードに分散してデータを保存するため、PostgresやMySqlなどのオンプレミスのリレーショナルデータベースに比べて、災害に強く、計算も高速です。
Redshiftについてもっと知りたい方は、Redshiftとリレーショナルデータベース、RedshiftとHadoop、Redshiftと従来のデータウェアハウスを見てみてください。
# Velocity
流れてくるデータから常に学習する機械学習サービスや、何十億ものユーザーが24x7x365で写真を投稿・アップロードするソーシャルメディアのプラットフォームを想像してみてください。 毎秒、何百万ものトランザクションが発生し、ペタバイト、ゼタバイト単位のデータが、毎秒、何百万ものデバイスからデータセンターに転送されていることになります。
速度が問題になるのはどんなときか
速度の高いデータは、速度×時間＝量であり、量がインサイトにつながり、インサイトが収益につながるため、素晴らしいものに聞こえます。
ファイアウォールを通過してくるすべてのデータパケットを、どのようにして悪意がないかどうか処理するのか、というような疑問が生じます。 このような高頻度の構造化データや非構造化データを、その場でどのように処理するのか？ さらに、データの速度が速いということは、ほとんどの場合、毎秒処理されるデータ量に大きな変動があることを意味します。Twitterのツイートは、スーパーボウルの時には、通常の火曜日よりもはるかに活発になりますが、これをどのように処理しますか? Apache organizationにはSparkやKafkaといった人気のソリューションがあります。Sparkはバッチ処理とストリーミング処理の両方に優れており、Kafkaはパブリッシュ/サブスクライブのメカニズムで動作します。 Amazon Kinesisもソリューションのひとつで、ストリーミングデータを処理するために設計された関連APIのセットを持っています。 Google Cloud Functions（Google Firebaseにもこのバージョンがあります）も人気の高いサーバーレス関数APIです。
さて、独自のデータパイプラインを構築するための時間と費用をかけたくない場合は、FlyDataのようなものが役に立つでしょう。
# Variety
現実の世界はさまざまな種類のデータによって混乱しているため、刺激的な課題に取り組む人が混乱したデータにも対処しなければならないのは当然のことです。 データウェアハウスを構築する上で、データの異質性はしばしばストレスの原因となります。 動画や写真、階層的につながっているソーシャルプラットフォーム上の投稿やつぶやきだけでなく、基本的なユーザー情報もさまざまな種類のデータで構成されています。
どのような場合に多様性が問題になるのか
大量のデータを消費する場合、データウェアハウスに保存するための統一されたデータタイプにマッサージする前に、データは異なるデータタイプ（JSON、YAML、xSV（x = C(omma)、P(ipe)、T(ab)、など）、XML）になることがあります。 また、APIのキーの名前を変えたり、導入したり、廃止したりと、データのカラムやキーが永遠に存在することが保証されていない場合、データ処理はさらに困難になります。
解決策
多様なデータ タイプに対処する 1 つの方法は、データ処理パイプラインのルートに沿って適用されるすべての変換マイルストーンを記録することです。 まず、生データをそのままデータレイクに保存します（データレイクとは、Amazon S3のファイルストレージのように、収集したデータをそのままの形で保管する柔軟性の高いリポジトリです）。
# Veracity
現実世界のデータは非常にダイナミックで、何が正しくて何が間違っているのかを知ることは困難です。 Veracityは、データの信頼性と混乱のレベルを意味し、データの信頼性が高ければ、混乱も低くなり、逆もまた然りです。
Veracity が問題となる場合
ハッシュタグ、一般的でないスラング、略語、タイプミス、口語などが使用されているTwitterのツイートの場合を考えてみましょう。これらのデータには多くの混乱やノイズがあり、データ量の増加に伴いノイズも増加します。
解決策
データが十分に信頼できるものでない場合、価値の高いデータのみを抽出することが重要になります。 データ抽出中に、データ処理パイプラインのできるだけ早い段階でデータからノイズをフィルタリングすること。
# Value
せっかくのビッグデータを価値あるものに変えられなければ意味がありません。 ビッグデータの収集に投入されたリソースと労力のコストと、データ処理の最終段階でどれだけの価値を提供するかを理解することは非常に重要です。
Netflixのケースを考えてみましょう。ユーザーの視聴や閲覧パターンのデータをさまざまなデータソースから収集し、データ処理パイプライン内で抽出・変換することで、ユーザーの関心事など価値の高い情報のみを生成し、有益なリコメンデーションを提供しています。 これにより、Netflixはユーザーの離脱を防ぎ、さらに多くのユーザーを自社プラットフォームに呼び込むことができます。 生成された情報は、ユーザーを満足させられなければ価値の低いものになっていたかもしれない。
#結論
現代では、スマートフォン、IoTデバイス、ラップトップなどのデバイスから大量のリアルタイムデータが常に流れており、これらの流れはすべてビッグデータを形成しています。5つのVは、データの流入が拡大しているときに何を考慮すべきかを特定するのに役立つ重要な特性（ビッグデータのフレームワークとでも言いましょうか）です。 ビッグデータは、人工知能、ビジネスインテリジェンス、データサイエンス、機械学習などの多くの分野で重要な役割を果たしており、データ処理（抽出-変換-読み込み）により、新たな洞察、イノベーション、より良い意思決定をもたらします。 また、ビッグデータの破壊は、意思決定の前にデータ分析を行う者に、従来のデータを使ってビジネスを行う者に対する競争上の優位性をもたらします。 Amazon Redshiftのようなソリューションは、データウェアハウスのためのリレーショナルデータベースに対する優位性を確実に提供するでしょう。一方、SparkやKafkaは、データウェアハウスへの継続的なデータストリーミングのための有望なソリューションです。