ビッグデータの問題
ビッグデータの量は急激に増加しています。この現象は何年も続いていますが、そのペースは2012年以降劇的に加速しています。ビッグデータの出現とそれに関連する課題についての同様の視点については、CSCから「ビッグデータが爆発し始めたばかり」というタイトルのこのブログをご覧ください。
IRIは、1970年代後半の会社設立以来、この傾向を認識してきました。その主力製品であるCoSortパッケージは、ソフトウェアアルゴリズムと設計、「ポータブル」ハードウェア活用手法、およびタスク統合（sort-join-aggregate-encrypt-reportなど）の効率化を通じて、増大するデータ量を処理するように設計されています。この記事が提起する問題は、「機械の台頭」を考えると、アプローチの1つです。
解決におけるハードウェアの制限
確かに、コンピューターのパフォーマンスは、ほとんどすべての点で何十年にもわたって加速しています。そして多くの人にとって、ビッグデータの問題にハードウェアを投入することは、単なる第二の性質です。ただし、問題はそれよりも大きい可能性があります。 CPUパワーが2倍しかないムーアの法則を考えてみましょう。 せいぜい18か月ごと、およびハードウェア中心の戦略に固有の陳腐化、メンテナンスの問題、および純粋なコスト。
考慮すべき新しいことは、ビッグデータのこのパフォーマンスパラダイムが終了する可能性があるという期待です。 Gery Menegazによると、彼の前提は、ムーアの法則の終わりが近づいているということです。 Time Magazineは、2012年5月に、ムーアの法則の崩壊というタイトルの同様の記事を掲載しました。物理学者はすでに起こっていると言っています。タイムの記事によると、
それを踏まえると、カク氏は、ムーアの法則が次の10年の終わりまでにようやく崩壊したとき、「3次元のチップのようなコンピューターで少し調整する」と述べています。それを超えて、彼は「分子コンピューターに行かなければならないかもしれないし、おそらく21世紀の量子コンピューターの後半に行かなければならないかもしれない」と述べています。
ただし、ほとんどのユーザーにとって、ハードウェアは、直面または予測するビッグデータ処理の課題に対応するために、ある程度拡張するために購入されています。しかし、その上で実行されているソフトウェアのパフォーマンスが低いほど、非効率性を克服するためにより多くのハードウェアリソースを費やす必要があります。私たちの世界の例としては、IBMp595を購入して/bin / sortを実行し、そのサイズとコストの3分の1のマシンでCoSortを実行しても同じ結果が得られる場合があります。
一方、ハードウェアを中心に構築されたExadataやNetezzaなどのDBおよびELTアプライアンスには、すでに6〜7桁の投資が必要です。そして、彼らはより大きな負荷を引き受けるためにスケーリングすることができますが、通常、スケーリングできる量（確かに指数関数的ではありません）、スケーリングを維持するために費やすことができる金額、および人々がワークロードのミッションクリティカルな側面ごとに単一のベンダー。また、代わりにストレージと取得（クエリ）の最適化のために設計されたデータベースにビッグデータ変換のオーバーヘッドを課すことは良い考えですか？
これらすべての質問に簡単に答えられたとしても、指数関数的に大きなリソース消費（並べ替えなど）を必要とする計算問題（ビッグデータの増加を線形にスケーリングするだけでも）をどのように解決できますか？どういうわけか、答えは単に手頃な量子コンピューティングを待つことにあるようには見えません…
ソフトウェアの役割
Hadoopとデータウェアハウスのアーキテクトが知っているように、並べ替え（および並べ替えに依存するETLでの結合、集計、読み込みの操作）は、ビッグデータ処理の課題の中心であり、コンピューティングリソース。ビッグデータが2倍になると、それを並べ替えるためのリソース要件は3倍になる可能性があります。したがって、マルチプラットフォーム、マルチコアの並べ替えソフトウェアに関連するアルゴリズム、ハードウェア活用技術、および処理スキームは、スケーラブルで手頃な価格の効率的な方法でこの問題を管理するための鍵です。
CoSortの貢献
CoSortのパフォーマンスは、アムダールの法則に沿って、ボリュームが直線的に変化します。 CoSortは数十のコアで数百ギガバイトのビッグデータを数分で変換できますが、他のツールは2倍以上の時間がかかり、拡張性がほとんどなく、プロセスでより多くのメモリとI/Oを消費する可能性があります。おそらくもっと重要なのは、CoSortが並べ替えを関連するアプリケーションに直接統合し、ステージングデータの効率が低下するDBおよびBIレイヤーの外部ですべての面倒な作業を行うことです。
CoSortのコルーチンアーキテクチャは、メモリを介して、ソーターと、SortCL（CoSortのデータ変換、フィルタリング、ルックアップ、レポート、移行、保護ユーティリティ）などのプログラムとの間でレコードをインタラクティブに移動します。そのため、次の並べ替えられたレコードが利用可能になるとすぐに、アプリケーションに移動したり、読み込んだりできます。アプリは入力ファイルを読み取っているように見えますが、実際には、ソースのバックエンドはまだ生成されていません。いいえ、ソーターに先んじることはできません。
2015年の終わりに、CoSortは、IRIの最新のビッグデータ管理および操作プラットフォームであるVoracityのエンジンにもなりました。 Voracityは、CoSortエンジンとHadoopエンジンの両方をシームレスに活用します。
結論
ビッグデータの処理の問題にスケールアップするために、物理的なコンピューティングリソースだけを期待することはできません。 CoSortソフトウェア環境は、必要なビッグデータ変換と関連するジョブがスタンドアロンプロセスとしてではなく、同じI/Oパス中に並行して実行される環境です。
したがって、ソートする時間以外の目的で高速ソートが必要な場合は、ソートの下流で何が発生するか、およびそのようなプロセスをリンクするための最良の方法を検討する必要があります。そして、最適なランタイムパラダイムを決定したら、高性能ハードウェアとそのようなソフトウェアを組み合わせてパフォーマンスを最適化できますか？たとえば、Exadataのデータベースサーバー側でCoSortを使用してDWデータをステージングできますか？それとも、IBM p595を維持し、CoSortをトリプルスループットに追加する方が理にかなっていますか？または、Hadoopを使用する場合は、同じ単純なCoSortの4GLまたはVoracityの直感的なETLマッピングを使用して、MapReduce 2、Spark、Storm、またはTezのジョブを駆動することを検討してください。
予算と想像力を、データの増加に取り組むためのガイドにしましょう。