毎日ビッグデータに取り組んでいますが、どこで時間を費やしていますか?

長年ビッグデータに携わってきた中で、ビッグデータで最も労働集約的で技術的に難しい側面は何だろうと自問したことはありませんか?

私は毎日考えています。考えることはとても重要です。それは消化と継続的な深化のプロセスです。次の文はこう述べています:

生まれてから人生そのものについて考えず、ただ社会の慣習に従って生きてきたのなら、人生は無意味なものとなるでしょう。人生について考えたこともないからです。

では、私たちはビッグデータそのものについて考えたことはありますか?ビッグデータは具体的に何をするのでしょうか? 長年ビッグデータに取り組んできたのに、なぜまだ完了できないのでしょうか?ビッグデータの本質は次のとおりです。

科学技術の発展により、より多くのデータを保存し、分析できるようになります。こうしてビッグデータの概念が生まれました。

機械学習の本質は次のとおりです。

データ量が増えると、量的な変化が質的な変化につながります。データが十分に大きくなると、その中の暗黙のルールはますます正確で完全なものになります。機械学習は、データメモリ内に存在する暗黙的な接続を探し出すテクノロジーです。

ビッグデータが最も多くのワークロードを消費する場所はどこですか?

現在、作業負荷の 80% はデータの収集、クリーニング、検証に費やされています。 仕事自体は難しくはないのですが、本当に面倒で骨の折れる仕事です。

私たちは毎日ため息をついています。

• データはどこですか?収集方法
• データをクリーンアップする方法
• 無効なデータが多すぎる場合、それを削除する方法

私たちがイライラするのは、新しい需要が来たときに、既存のデータ形式ではその需要を満たすことができないようで、既存のデータ パイルで再度、データ収集、クリーニング、検証のプロセスを経なければならないことです。

それはまるで呪いのようでした。険しい山に巨石を押し上げる刑に処せられた哀れなシシュポスのように。シシュポスは全力を尽くして巨石を頂上に上げようとしたのですが、そのたびに手から滑り落ちてしまい、また押し戻さなければならず、果てしない労働を強いられるのです。

現在、ビッグデータで直面している最大の技術的困難は何ですか?

これは、大量のデータに対するアドホッククエリです。 Hadoop が初めて登場したとき、私たちは Hadoop を使って、ますます安くなる PC サーバーの価格を操作することができました。そして、ある種の暴力がエコシステム全体に浸透しました。

突然強力な計算能力を手に入れたので、貧しい人が突然たくさんのお金を手に入れたようなものです。私たちは、データを実行するために、最も効率の悪いプログラムを動かすために強力なコンピューティングパワーを使い始めました。これがバッチ処理時代の悲劇です。

しかし、クエリの効率要件がますます高くなるにつれて、変更を余儀なくされることになります。以前のログはすべて単純な Raw テキストだったことを覚えていますか? 現在、さまざまなストレージ形式が徐々に普及しつつあります。

1. Digital Brickが開発したストレージ技術「Parquet」
2. Hiveの共通ストレージ形式であるORC
3. CarbonDataは、ファーウェイが立ち上げたPBレベルのデータフォーマットのセットである。

つまり、クエリの問題を解決する魔法の技術はまだ見つかっていないようで、妥協するしかありません。

クエリを高速化するために、データストレージは初期の生のテキストから、ベクトル化され、インデックス化され、特定のエンコードと圧縮をサポートする列ストレージ構造に徐々に変化してきました。 もちろん、ストレージ構造を調整するこの方法では、データの入力時に必然的に時間とリソースが消費されます。

つまり、ストレージとクエリの間で妥協点を見つけました。

重労働を軽減する方法

先ほども述べたように、私たちの仕事のおそらく 80% はデータの収集、クリーニング、検証に費やされています。しかし、この部分の作業をどのように圧縮すればよいのでしょうか?

答えは次のとおりです。

• ストリームコンピューティング
• ストリーミングコンピューティングの上部構造

すべての計算をスムーズに行うことで、次のことが容易になります。

すでに流れているデータのどの時点でも、新しい支流を導入できます。データを取得したい場合、基本的に行うことは、2 つ以上のノードを接続し、それらの間でデータを変換することです。川の水と同じように、支流を開いて水を流し、新しい農地に灌漑することも簡単にできます。

また、ストリーミング コンピューティングの実装では、ストリーミングとバッチ セマンティクスが組み合わされることを期待しています。なぜ？

Storm 上の Huawei の StreamCQL を見ると、リアルタイム ストリーミングは多くの場合非常に制限されていることがわかります。これは、将来的にはストリーミングでさらに多くのことができるようになるためです。

1. データ処理
2. アドホッククエリ
3. 機械学習
4. レポート
5. ストレージ出力

これにはある程度の柔軟性が必要です。なぜなら、データ セット上でのみ、アドホック クエリ、効率的なストレージ、および一部の機械学習アルゴリズムへの適応が可能になるからです。多くの場合、単一のデータにはあまり意味がありません。

私はずっと Spark Streaming の支持者でした。

では、なぜストリーミング コンピューティングの上部構造が必要なのでしょうか? 問題を確認しましょう。データ ETL プロセスは、プログラマーの作業時間を大量に消費する大変な作業です。この時間を短縮するには、次の 2 つの方法があります。

• 全員が実行できるように、いくつかのタスクを分配します。すると、合計量が同じであれば、個人の数は減ります。
• 全員の生産性を向上

ストリーム コンピューティングは全体の基盤を構築し、その上のフレームワークによって上記の 2 つのポイントが可能になります。