分散環境におけるビッグデータのストレージとコンピューティングの問題を解決する方法についての個人的な理解

分散環境におけるビッグデータのストレージとコンピューティングの問題を解決する方法についての個人的な理解

• 分散: 大量のデータの計算とストレージの問題を解決するにはどうすればよいですか?

  • 質問 1: ストレージと分析の計算に MySQL を使用しないのはなぜですか?

    • データ量が多く、MySQL に保存できない
    • 保存できても処理性能が非常に悪い
      • データの価値は時間の経過とともに徐々に減少します
      • オフライン アーキテクチャ: 時間単位でデータを処理する
        • 昨日のデータを今日処理すると、適時性が比較的遅くなります [分以上]
      • リアルタイム アーキテクチャ: データ生成単位でデータを処理する
        • データは1つずつ生成・処理され、適時性が比較的高い（msレベル）
    • さまざまなデータ型

  • 質問 2: データを保存または計算できない問題を解決するにはどうすればよいですか?

    • 分散型: 分割統治
      • 先分
      • 演算処理
      • 閉店後
    • 定義: 複数のマシンのリソース[クラスター]を論理的に ==全体==にマージし、分散ソフトウェアを通じて分散サービスを提供すること
    • プロセス
      • step1: 大きなタスクがあります: 保存と計算
      • step2: 分散サービスにサブミットし、分散サービスがスコアリングのプロセスを実現します
        • この大きなタスクをいくつかの小さなタスクに分割します
      • step3: 分散サービスは、複数の小さなタスクを複数のマシンに割り当てて共同実行し、各マシンは異なる小さなタスクを処理します。
      • step4: ユーザーが結果を取得する必要がある場合、すべての小さなタスクの結果を結合して、最終結果を返す必要があります。
    • 例
      • ストレージ
        • マシン: 3: 8T = 24TB
        • ファイル: 15TB
        • プロセス
          • ユーザーが分散ストレージ サービスにストレージを送信: 15TB
          • 分散サービスはこのファイルを分割します
            • ブロック1:5TB
            • ブロック2:5TB
            • ブロック3：5TB
          • 分散サービスは 3 つの 5TB ブロックを 3 台のマシンに保存し、各マシンに 5TB を保存します。
            • メタデータ: このファイルとこれら 3 つのブロック、および 3 台のマシン上の 3 つのブロックの保存場所に関する情報を記録する必要があります。
          • ユーザーがファイルを読み取り、分散サービスにその読み取りをリクエストすると、分散サービスは、最初にファイルに分割されていた 3 つのブロックを結合して、それをユーザーに返します。
      • 計算する
        • マシン: 3: 2コア 4GB => 6コア 12GB
        • ファイル: 9GB => 蓄積: 1 + ... +9
        • プロセス
          • ユーザーは分散コンピューティング サービスに計算を送信します: 1 + ... +9
          • 分散サービスではこの計算が分割されます
            • タスク1：1+2+3
            • タスク2:4+5+6
            • タスク3:7+8+9
            • task4: 他のタスクの結果を蓄積する
          • 3 つのタスクを 3 台のマシンに割り当てて計算を実行する
            • ノード1：タスク1：6
            • ノード2：タスク2:15
            • ノード3：タスク3:24
          • タスク 4 を開始して 3 台のマシンの結果をマージします。
            • ノード3：タスク4:45
          • 最終結果をユーザーに返す

  • 質問 3: 分散はどのような問題を解決しますか?

    • 大量のデータの保存と計算の問題を解決する
    • 単一マシンのリソースが不足している
    • 単体マシンのリソースパフォーマンス低下の問題 [メイン]

  • 質問 4: 分散型の一般的なアーキテクチャはどのようなものですか? 【飼育員を除く】

    • マスター/スレーブ アーキテクチャ: マスター/スレーブ ノードプロセス
    • マスターノード: 管理ノード
      • 主に分散型サービスの管理業務を担当
        • すべてのスレーブ ノードの存続と停止を管理する
        • 管理タスクの割り当て
      • ピックアップ: クライアントのリクエストを受け入れる
      • 異なる分散スレーブ ノードのプロセス名は異なります: Leader、NameNode、ResourceManager、Master...
    • スレーブ ノード: 各マシン独自のリソースの管理を担当します。
      • いくつかのマシンがあり、いくつかのスレーブノードがある
      • 異なる分散スレーブ ノードのプロセス名は異なります: Follower、DataNode、NodeManager、Worker...
      • マスターノードによって割り当てられたタスク[小さなタスク]を受け入れ、自分のマシンを呼び出してタスクを実行します

  • 質問 5: 分散アーキテクチャに問題はありますか?

    • 単一障害点の問題: マスター ノードが 1 つしかないため、マスター ノードのプロセスまたはそれが配置されているマシンに障害が発生すると、分散サービス全体が利用できなくなります。
    • 分散データの一貫性の問題: 複数のマシンが同じデータを共有したい場合、読み取りデータの一貫性を確保する方法
    • 解決策: 動物園の飼育員

  • 質問 6: 動物園の飼育員は 2 つの分散された問題をどのように解決しますか?

    • 問題: データの一貫性の問題
      • ZK を使用して一貫したストレージを実現し、データを ZK に保存します
      • すべてのノードが ZK からデータを読み取ります
    • 問題: マスターノードの単一障害点
      • 解決策: 分散フレームワークは複数のマスター ノードを構築して、同時に動作するマスター ノードが 1 つだけであることを保証できます。
      • 州
        • アクティブ: 動作ステータス
        • スタンバイ: バックアップ状態
    • 質問: 誰が作業し、誰がバックアップであるかをどのように決定しますか?
      • 解決策: 補助選挙に動物園管理者の一時ノードを使用する
      • 実現: 2 つのマスター ノード A と B を ZK に移動させて、同じ名前の一時ノード ファイルを作成します。作成に成功した人がアクティブになり、もう 1 人はノードがすでに存在するため作成に失敗します。
        • A が正常に作成されたと仮定すると、A はアクティブになります
        • Bはスタンバイとしてファイルノードの監視を設定します。Aが失敗するとZKとのセッションが切断され、一時的なノードファイルが削除されます。Bは監視情報を受け取り、Aが失敗すると切り替えます。アクティブ状態へ

• Zookeeper: 分散した問題の解決

  • 関数
    • 共有データの保存に使用: メタデータ、インデックス データ
    • 補欠選挙
  • すべての分散フレームワークは、zk を使用して分散問題を解決するか、ZK のようなソリューションを独自に実装します。
  • 質問 7: Zookeeper 自体も配布されていますが、その問題は独自に解決する必要がありますか?
    • 質問: ZK に障害が発生した場合、影響を受けますか?
      • 影響しません
      • ZK は公正なノードであり、ZK の各ノードに格納されているコンテンツは一貫しており、どの ZK も読み取りおよび書き込みリクエストを受け入れることができます。
    • 質問: zk は各マシンのコンテンツの一貫性をどのように保証しますか?
      • 他のノードと同期できるのはリーダーとリーダーのみに制限されています
    • 質問: リーダーが失敗したらどうなりますか?
      • 公平なノード: 各マシンをリーダーとして選出でき
        、リーダーは他のノードと同期されます。
    • 質問: リーダーが失敗したらどうなりますか?
      • 公平なノード: すべてのマシンがリーダーとして選出可能

【外部リンク画像転送…(img-l9kYu1r2-1606877554427)】

• Hadoop: ビッグ データ ストレージとコンピューティングの問題 = 「設計: 分散ソリューション」