Consulting / SI いわゆるビッグデータ問題

１：スキル／リソース

ビッグデータは不足している新しくて専門的なスキルを必要とします。従来型のSQL中心のアナリストはビッグデータが要求するものに対処するために十分には準備ができていません。開発者は高パフォーマンスの並列処理のためのデータ移行と分析フレームワークを構築し維持するために、新しいプログラミングのパラダイムとシステムデザインにこなれていなければならないのです。
またITスタッフはハードウェア、システムソフトウェア、ネットワーク環境にも熟達していなければなりません。もしこうしたスキルが、社内にあったとしても、そうしたスキルを持った人々は他の重要なプロジェクトにコミットしている可能性が高くなります。外部から人を雇うには何ヵ月もかかり、支払うべき給料も高くなります。

2：長い実装時間

スタッフの強化の時間は別にして、従来型のビッグデータソリューションは典型的には、6〜12ヵ月の設置期間をはじめ、専用システムへの大規模な事前投資が必要となります。
オープンソースであるマルチノードのHadoopを使い人員の設置とテスト、最初のクエリーが走る前の標準的なシステムの設置や独自コードの開発・統合・テスト・チューニングを含むプロジェクトは、3〜6ヵ月の時間を要します。

データ分析が重要であるように、依然として深い洞察が新しい問いを生み出し、データクエリーをダイナミックに変更するような反復プロセスが必要とされています。
リソースの限られた自前の分析環境でこのプロセスを達成しようとすると、分析サイクルは簡単に何日間から何週間もかかってしまい、その結果このプロセスの目的を達成はできなくなってしまいます。

3：ETL（Extract/Transform/Load）とスキーマ依存

この2つの事柄はしばしば考慮に入れられないことがありますが、ビッグデータを扱う為には多大な時間と労力が必要となります。
ETL（extract/抽出、transform/変換およびload/ロード）にはソースデータを分析エンジンに移したり、データのかたまりを従来のウェアハウスのプラットフォームやBIツールに移したりといった作業を伴います。その過程の中でソースとターゲットのプラットフォームの間のデータ形成のサポートが行われなければなりません。

現在はロードとエクスポートの両プロセスのために手動で作成されたルーチンとデータ型毎に複数の選択肢が発生します。しかしそのプロセスは時間がかかり、維持することが困難な日々増大するコードベースに着地します。
また、型にはまったほとんどのデータウェハウスのプラットフォームは仮の分析モデルをサポートするためスキーマ依存です。この場合、洞察を与えるために予測されるデータ・エレメンツならびにデータストアのスキーム構造は前もって定める必要があります。

パフォーマンスへの考慮は初期設計において大変重要です。そして、アナリストはクエリーのパフォーマンスを確かなものにするためにその基礎構造に関する知識を持たなければなりません。また新しいカラムがテーブルに加えられる際には、スキーマを変更する必要があります。

しかし、ビッグデータ分析は、ほとんどが仮定できるようなものではありません。つまり、アナリストは初めからあまり分からない隠されたパターンや関係性やイベントを見つけ出す必要があります。
またユーザーはパフォーマンスの負荷を考えることなく、データが出てきたところで、事象を追求してゆく必要があります。このような場合、スキーマ依存のモデルでは、管理上のオーバーヘッドが多くなります。

4：マネジメント上のオーバーヘッド費用と変化

実行上のオーバーヘッドの費用（人的・手続き的直接/間接のコスト）はビッグデータのプロジェクトにとって最も大きな障害の一つとして現れます。
システムマネジメントツールは未成熟であるか使えない状態が多く、複雑なシステムと新技術がオンプレに設置される環境では、実行上のオーバーヘッドの費用は簡単にハードウェアとソフトウェアのコストを越えてしまいます。

ビッグデータの環境はこれまでのデータ保存や分析環境よりダイナミックなので、ETLレイヤーでの変化を管理したり、データストアをスケールしたりするのには、これまでのデータウェアハウスのソリューションよりも時間とリソースが掛かります。

ビッグデータ問題が主流として受け入れられるために打破すべき2つの大きな障害：

次ページへ：異なるアプローチ

さらに詳しい情報は