ビッグデータ自体は、Hadoopのエコシステム（またはパン・生態系）非常に広い概念であるスタンドアロン規模データ処理と出産以上のものを処理するために基本的にあります。あなたはそれが台所を必要とするさまざまなツールと比較することができます。鍋やフライパンは、それぞれ独自の使用を持っているだけでなく、互いに重なり合います。あなたが剥離ナイフや飛行機を使用することができたときにあなただけのスープ鍋にスープを食べることができます。奇妙な組み合わせが働くことができるものの、各ツールは、独自の特性を持っていますが、必ずしも最良の選択。
ビッグデータは、まずあなたが次の大きなデータを保存できるようにする必要があります。
従来のファイルシステムでは、スタンドアローンではなく、異なるマシン間です。HDFS（Hadoopの分散ファイルシステム）上で、本質的にマシンの数百または数千にすることができにわたる大量のデータのために設計されていますが、ファイルシステムの多くの代わりのファイルシステムを参照してくださいています。たとえば、あなたは私がデータ/ HDFSを/ tmp / file1のを取得したいと言う、あなたはファイルパスが、多くの異なるマシンに保存されている実際のデータを引用しました。ユーザーとしては、スタンドアローンのファイルに同じことは、あなたがどのような分野でのトラックを気にしないものを分散させるように、知っている必要はありません。あなたのために、これらのデータのHDFS管理。
データが下に格納された後は、データを処理する方法について考え始めます。HDFSデータの全体的な管理はあなたのために別のマシン上に置くことができますが、データが大きすぎですが。マシンは（例えばすべての高精細映画またはそれ以上の全体東京サイズの熱履歴など大暮維人データ、）P-T上のデータを読み取るために、マシンは数日あるいは数週間のためにゆっくりと実行する必要があります。多くの企業にとって、単一の治療は、マイクロブログは24時間ホットボーを更新するよう、それは24時間以内に処理を完了しなければならないなど、耐え難いです。私は、加工機の多くを取る場合は、マシンがどのように複雑な計算とを完了するために、マシン間でデータを交換するために相互に通信するために、対応するタスクを再起動する方法にハングアップしているのであれば、私は、仕事の割り当てに直面していました。これは、機能のMapReduce / TEZ /スパークです。MapReduceの計算エンジンは、第一世代、TEZスパーク及び第二世代です。MapReduceの設計、非常に単純化した計算モデル、地図を使用して（中間シャッフルシリーズ）のみ2つの計算を削減するには、このモデルを使用して、問題の大部分は、すでに大規模なデータ・フィールドを扱います。
地図の削減は何であるとは何ですか？
あなたが同様のHDFSに保存されている巨大なテキストファイルをカウントしたい場合は、テキスト内の各単語の出現頻度を知りたい考えてみましょう。あなたは、MapReduceのプログラムを開始しました。などのマシンの何百も同時にこのドキュメントのさまざまな部分を読ん地図段階、各パートに読み出された個別の単語の頻度統計、同様の（こんにちは、12100倍）、（世界、15214倍）、このようなペア（I ）一緒に地図とこれを組み合わせて、簡素化する工程と、上記のように独自のセットを持っていたマシンの数百人は、その後、マシンの何百もあります起動プロセスを減らします。マシンから減速機マッパーはA、BマシンBで始まる統計結果に、すべての語彙統計結果を受け、コースの（の初めに受け取ることになります実際には本当にベースの文字で起動しませんが、機能してハッシュ値を生成します）確かにはるかに少ない他よりもX類似した単語の初めからデータの文字列を避けるため、あなたは各マシン格差のデータ処理負荷を望んでいません。次いで、これらが再び凝集する減速、（こんにちは、12100）+（こんにちは、12311）+（こんにちは、345881）=（こんにちは、370292）。各リデューサーあなたは、文書全体の単語頻度結果を取得するには、上記のように処理されています。
これは非常に単純なモデルであるように見えますが、多くのアルゴリズムは、このモデルを説明し使用することができます。
地図+簡単なモデルを削減は使いやすいものの、非常に暴力的に非常に黄色ですが、非常に重いです。新機能のようなキャッシュメモリに加えてTEZとスパークの第二世代は、本質的には、地図/モデルを軽減させることです地図の間で境界がvaguer、より柔軟なデータ交換、少ないディスクの読み取りを削減して、より一般的ですより簡単に、より高いスループットを達成するために複雑なアルゴリズムを説明するために、書きます。
MapReduceのでは、TEZとスパークした後、プログラマーはMapReduceのプログラムは、実際のトラブルを書くために、見つけます。彼らは、このプロセスを簡素化します。あなたはアセンブラ言語を持っているようにあなたはほとんど何を行うことができますが、それは、ですが、あなたはまだ面倒に感じます。あなたは、アルゴリズムとデータ処理手順の層を記述するために、より高いレベル、より抽象的な言語を持っていると思います。その後、豚やハイブがあります。豚のMapReduceを記述するためのスクリプトの道に近い、ハイブは、SQLを使用しています。彼らは、スクリプティングとSQL言語は、MapReduceのプログラムに変換計算する計算エンジンを投げたが、あなたはプログラムを書くためのシンプルでより直感的な言語で、退屈なのMapReduceプログラムから解放されています。
あなたはハイブを持っていたら、それはSQLのコントラストJavaは大きな利点を持っていることが判明しました。一つは、それを書くのはあまりにも簡単であるということです。SQLを使用しただけで何の単語の頻度は、行の数百約書くためだけの行または2、MapReduceのを記述する。そして、もっと重要なのは、非コンピュータユーザーは、最終的には、背景の愛を感じた：私は最終的に、ヘルプジレンマエンジニアのために物乞いから解放されたSQLデータアナリスト、奇妙なワンタイム・ライト・ハンドラから解放されたエンジニアを書きます！ 。みんな幸せ。ハイブは、大規模なデータ・ウェアハウスのコアコンポーネントに成長しました。でも、SQLに完全に設定され、同社のパイプライン動作の多くは、外観は、維持しやすい理解するように変更するのは簡単書くのと同じくらい簡単記述する。
データ解析は、ハイブのデータ分析を開始して以来、彼らは、実行中のMapReduceのハイブは、ディック本当に遅い！セットが24時間以内であっても仕上げた場合、いずれにせよ、このように24時間を推奨更新などのパイプライン動作には何もないかもしれないことがわかりました。しかし、データ分析は、人々は常に高速に実行できるようにしたいです。例えば、私はどのように多くの人々の過去時間以内インフレータブル人形のページストップで見たいのですが、どのくらい滞在し、それぞれ、次の巨大なウェブサイトの膨大なデータ、この処理には数分、あるいは多くの時間がかかる場合があります。そして、この分析では、上司と報告するために、当社の顧客は、より惨めな男性Mensao女性である、あなたは、人々が愛玉ラフマニノフのCDを見てどのように多くの依存どのように多くの人々、あなたの長い行進で唯一の最初の工程であってもよいですより多くのまたは若いアーティスト/女の子より。あなたはバッタが速く、速く、そしてより速く、言うだけでハンサムなエンジニアで、待っているの拷問に耐えられません！
だから、インパラ、プレスト、ドリル生まれた（もちろん、多くのよく知られた非対話型SQLエンジンがそれらを表示されませんがあります）。それはあまりにも保守的な、あまりにも強く、一般的すぎるため、核となるアイデアは、3つのシステム、MapReduceのエンジンは、遅すぎるされていることを、私たちは、リソースへのSQL軽く、より積極的なアクセスを必要とする、より具体的に行うためにSQLを最適化するために、そしてあまり必要としません。 （全体の処理時間あれば、このような数分でのように短い言葉、タスクを再起動するため、システムエラーの大したこと）のことを確認するためにフォールトトレランス。これらのシステムは、ユーザーがより迅速に、安定性の一般的な特性を犠牲にして、SQLのタスクを処理することができます。MapReduceのはマチェーテであれば、結果的に上記の3つのボーン入りナイフ、シャープでスマートな、あまりにも多くのものを行うにはあまりにも難しいことではありませんことを、恐れていないカット。
これらのシステムは、正直に言うと、期待されるの人気に達していません。この時間なので、それは異種の2から作られます。彼らはTEZ /スパークとSparkSQLにハイブです。彼らのデザイン哲学は、MapReduceの遅いですが、私はGMスパークTEZの新世代とエンジンを計算するか、SQLを実行する場合、私はより高速に実行することができるようになります。そして、ユーザは、2つのシステムを維持する必要はありません。あなたの台所が限ら食べるために必要な、小さな、怠惰な人々、洗練された場合、あなたは、エネルギーを燃やす台所用品を大幅に節約することができ、蒸気を沸かすことができ炊飯器を買うことができるようなものです。
上記の説明は、データ・ウェアハウスは、基本的な枠組みです。上記ボトムのMapReduce / TEZ /スパーク上で実行HDFS、ハイブを実行し、豚。または直接HDFS上インパラ、ドリル、プレストを実行します。このソリューションは、低速なデータ処理が必要となります。
より速く、私はそれに対処したい場合は？
私は同様のマイクロブログの会社だったら、私が表示したい24時間ホットボーではないですが、私は刻々と変化するヒットリストを見たいと思って、1分遅れで更新し、上記の方法は有能ではありません。さらに別の計算モデルは、次に、（ストリーム）が算出されるストリーミングされ、開発されました。ストームは、最も人気のあるストリーム・コンピューティング・プラットフォームです。アイデアは、計算はあなたがよりリアルタイムの更新を達成する必要がある場合は、データの契約上の流れ？それとも単語頻度統計を、このような例は、私のデータストリームが1つの単語であるとき、なぜ私は来ていないということです流れ、私は彼らが側を通って流します私はしばらくの間をコンパイルし始めました。フロー計算非常に高速なハードウェア、ほとんど遅延が、その弱点あなたがカウントする、柔軟ではありませんが流れるすべてのデータが消えた後、あなたがカウントされませんでした物事が計算を行うことができなかったものを、事前に知っていなければなりません。だから、それは良いことですが、上記のデータウェアハウスやバッチシステムを代用することはできません。
別のモジュールは、カサンドラ、HBaseの、MongoDBは、多くの多くの多くの他の多くの（より想像を絶するへの）としてKVストアは、ややもありです。だから、私は鍵の束を持っていると述べたKV店は、私は非常に急速に低下バインディングこの鍵データを取得することができます。例えば、私はID番号を使用して、あなたのアイデンティティデータを取るために。このアクションは、また、MapReduceので行われますが、データセット全体をスキャンする可能性があることができます。KVストアと、この操作を処理するために専用の、すべてのメモリと、この目的のために特別に最適化が取られます。おそらく限り数十分の一のように、いくつかのPからID番号データを検索します。これは、特殊なデータ、同社の事業の多くが大幅に最適化されていることができます。例えば、私は、サイト全体の受注数は、スタンドアローンのデータベースストレージをすることはできませんが、私はKVストアを節約するために検討すると、ページの順序のページ数に基づいてコンテンツを見つけるための注文を持っています。KVストア哲学は、それらのほとんどは多分、強い一貫性の保証（別のマシンに分散異なるデータは、あなたが読んで毎回異なる結果を読んでいないかもしれない重合があり、参加できない、複雑な計算を処理することはできません基本的に銀行振込は、強力な適合性要件と同様の操作を処理することはできません）。ああ、それは速いです。速いです。
各異なるKVストアのデザインが異なるトレードオフがあり、いくつかのより速く、いくつかのより高い容量は、いくつかのより複雑な操作をサポートすることができます。あなたのために右がなければなりません。
また、ようにMahoutの分散データベース、データ交換いるProtobufコード及びライブラリ、ZooKeeperの高い一貫性分散協調システムへのアクセス、及び学習そのような機械のようないくつかのより特別なシステム/コンポーネントがあります。
そんなにクラッタのツールを使用すると、同じクラスタ上で動作している、私たちはお互いと整然とした作業を尊重する必要があります。スケジューリングシステムようにもう一つの重要なコンポーネントです。今、最も人気のある糸です。あなたは中央管理として彼を見ることができ、キッチンであなたのお母さんのような監督は、ちょっと、あなたの妹は、植物は、あなたが鶏にナイフを取ることができますオーバーでカット。限り、あなたは、私たちが喜んで料理をドロップすることができ、あなたのお母さんの割り当てに従うよう。
あなたはビッグデータエコシステムは、キッチンツールのエコシステムである、と考えることができます。さまざまな料理、中華料理、日本料理、フランス料理を作るために、あなたは、さまざまなツールを必要とします。宿泊客のニーズが複雑であると、あなたの台所は、これまでに発明され、またユニバーサルキッチンは、すべての状況を扱うことができ、それはますます複雑になります。
高度の記事を読んでお勧めします
40 +すべてここにビッグデータ開発[W]チュートリアルの年俸！