大データアーキテクチャコース復習ノート

1 導入

大データシステムの要求には、データ要求、機能要求、性能要求（高性能、高可用性、高拡張性、高耐障害性、安全性など）、計算シナリオ要求が含まれます。

分散システム/クラスターまたは大データ処理の目標要求：高性能、高可用性、耐障害性、拡張性。高性能には3つの評価指標が含まれます：応答時間（遅延）、スループット、資源使用率；高可用性指標：MTTF、MTTR、可用性=MTTF/（MTTF+MTTR）

大データとクラウドコンピューティングの関係：

• クラウドコンピューティングは大データ処理に十分な計算資源を提供できます。
• 大データはクラウドコンピューティングサービスの典型的な応用です。
• 大データはクラウドコンピューティングを使用しなくてもよいです。 大データ計算の典型的なシナリオには
• バッチ処理
• ストリームコンピューティング
• インタラクティブクエリ 静的データは有限で持続的に保存され、容量が大きく、バッチ処理に適しています。

ストリームデータは無限で継続的に生成され、データウィンドウでタイムリーに処理する必要があり、終わりが見えません。

2 クラウドコンピューティング概説

2.1 クラウドコンピューティングの定義

• クラウドコンピューティングは商業計算モデルの一種です。計算タスクを大量の計算機で構成された資源プールに分散させ、様々なアプリケーションシステムが必要に応じて計算力、保存スペース、情報サービスを取得できるようにします。
• ネットワークを通じて動的に拡張可能な安価な計算サービスを提供し、普遍的に適用可能な資源管理の思考とモデルです。
• クラウドコンピューティングは計算資源をどこにでもある雲に例え、仮想化、分散コンピューティング、ユーティリティコンピューティング、負荷分散、並列計算、ネットワークストレージ、ホットバックアップ冗長などの技術の発展進化の結果です。

2.2 クラウドコンピューティングの特徴

1. 資源の仮想化とプール化による統一管理
2. 超大規模、高可用性、高拡張性
3. 弾力性、オンデマンド、自助によるサービス提供
4. 普遍的なアクセス、正確な課金、低価格

2.3 三つのサービスモデル

1、インフラストラクチャー・アズ・ア・サービス IaaS（Infrastructure as a Service）

サーバー、ストレージ、ネットワークなどの計算資源サービスを提供

主要機能：

• ユーザーはIaaSをオンデマンドで支払い、ハードウェア全体を購入する必要がありません。
• 処理と保存のニーズに応じてインフラストラクチャを拡張できます。
• 企業がハードウェアを購入および維持するコストを節約します。
• データはクラウドにあり、単一障害点はありません。 2、プラットフォーム・アズ・ア・サービス PaaS（Platform as a Service）

開発、管理、配信のための環境ソフトウェアを提供します。オペレーティングシステム、データベース、ミドルウェア、開発プラットフォームなど。

主要機能

• ソフトウェアベンダーが迅速に開発、テスト、デプロイを行うための開発プラットフォームとツールを提供します。
• ソフトウェアベンダーは開発に専念し、基盤インフラストラクチャを心配する必要がありません。
• クラウドベンダーはプラットフォームの安全性、信頼性、安定性を保証します。 3、ソフトウェア・アズ・ア・サービス SaaS（Software as a Service）

ネットワークを通じてクラウドソフトウェアサービスを提供します。

主要機能

• ユーザーはソフトウェアをサブスクリプションで支払い、インターネットを通じてアプリケーションソフトウェアに直接アクセスし、ソフトウェアの管理、インストール、またはアップグレードを必要としません。
• データはクラウドで保護され、デバイスの故障によって失われません。
• サービスのニーズに応じて資源使用量を拡張できます。

2.4 四つのサービス形態

パブリッククラウド:第三者のクラウドサービスプロバイダーが所有および運営し、インターネットを通じてサービスを提供するITインフラストラクチャ。

利点：低コスト、メンテナンス不要、オンデマンドスケーリング、高信頼性高可用性。

欠点：安全性が制御できず、資源を自由にカスタマイズできません。

プライベートクラウド:特定の企業または組織専用のクラウドコンピューティング資源で構成されます。

利点：パブリッククラウドと比較して、資源のカスタマイズが柔軟で、安全性が高いです。

欠点：構築と運用コストが高いです。

コミュニティクラウド:複数の企業または組織

ハイブリッドクラウド:安全な接続を通じてパブリッククラウドとプライベートクラウド環境を組み合わせ、異なるクラウド環境間でデータとアプリケーションを共有できるようにします。

– 制御性が高く、敏感な資産はプライベートクラウド。

– 柔軟に利用可能で、オンデマンドでパブリッククラウドを使用できます。

– コスト効率が高く、パブリッククラウドのスケーラビリティを備えています。

2.5 クラウドコンピューティングアーキテクチャ

1、SOA構築層

クラウドコンピューティング能力を標準Webサービスとしてカプセル化し、SOAシステムに組み込みます。

2、管理ミドルウェア層

クラウドコンピューティングの資源管理を行い、多くのアプリケーションタスクをスケジュールし、資源が効率的かつ安全にアプリケーションサービスを提供できるようにします。

2.6 クラウドコンピューティングのコア技術

クラウドコンピューティングのコア技術には仮想化とコンテナ化があり、コンテナ化技術は共有されたオペレーティングシステムカーネルを利用して、アプリケーションとその実行環境をパッケージ化し、仮想化よりも軽量で迅速、低コストであるため、近年開発者に人気のある技術です。

2.6.1 仮想化技術

仮想化（Virtualization）はコンピュータ資源を抽象化して仮想の論理エンティティとしてマッピングし、物理資源の制約を超えて統一管理を行い、クラウドコンピューティング環境のコア基盤技術を構築します。

◼ サーバー仮想化：1台のコンピュータを複数の論理コンピュータに仮想化

◼ ストレージ仮想化：基盤ストレージデバイスを抽象化して統一プール管理し、外部に独立したストレージサービスを提供

◼ ネットワーク仮想化：1枚の物理ネットワークカードを複数の仮想ネットワークカードに仮想化し、仮想マシンを通じて異なるアプリケーションを隔離

◼ デスクトップ仮想化：ユーザーデスクトップ環境とその使用する端末デバイスをデカップリングし、サービスプロバイダーが各人の完全なデスクトップ環境を保存し、ユーザーは端末デバイスを使用してネットワークを通じて自分のデスクトップにアクセス

2.6.1.1 1、サーバー仮想化

仮想マシン（Virtual Machine） VM

1台のコンピュータ（物理マシン、物理サーバー）を複数の論理コンピュータに仮想化

各仮想マシンは独立した「ハードウェア」を持っています。

仮想マシン「ハードウェア」は物理マシンのハードウェアを使用してシミュレーションされています。

仮想マシンが実行する作業は、実際には物理マシンのハードウェアによって行われます。

仮想マシンモニター（Virtual Machine Monitor）VMM

VMMは物理マシンを仮想マシンにするためのオペレーティングシステムまたはソフトウェアです。主な機能は仮想マシンに仮想のハードウェア資源を提供し、これらの資源を管理および配分し、仮想マシン間の相互隔離を確保します。

VMMの2つの動作モード

1 ホストモード（寄居モード、托管モード）：VMMは物理マシンのオペレーティングシステム上で実行され、インストールと使用が簡単で便利ですが、性能は低いです。

寄居仮想化の仮想化層は通常、仮想マシンモニター（VMM）と呼ばれます。VMMはホストOSを呼び出して資源を取得し、CPU、メモリ、I/Oデバイスの仮想化を実現します。VMMが作成した仮想マシンはホストOSのプロセスとしてスケジュールに参加します。寄居モードではVMMはホストOSの機能を十分に活用してハードウェアデバイスを操作できますが、中間段階を経るためシステムの損失が大きくなります。

2 ハイパーバイザーモード（裸金属モード）：VMMは物理マシンのハードウェア上で直接実行され、物理マシンに近い性能を提供します。

アーキテクチャの中のVMMはオペレーティングシステムであり、通常はハイパーバイザーと呼ばれます。ハイパーバイザー=OS+仮想化——伝統的なオペレーティングシステムの機能を備え、仮想化機能を備え、仮想資源から物理資源へのマッピング、仮想マシンシステムの隔離を含みます。物理マシンに近い性能を提供しますが、サポートされるI/Oデバイスは限られています。

サーバー仮想化技術の分類

臨界命令の処理方法の違いに基づく

完全仮想化（Full Virtualization）

半仮想化（Para Virtualization）

ハードウェア支援仮想化（Hardware Assisted Virtualization）

完全仮想化

1. VMMはGuest OSに完全な基盤ハードウェアをシミュレートし、プロセッサ、物理メモリ、クロック、周辺機器などを含み、クライアントオペレーティングシステムは自分が仮想マシン上で実行されていることを全く知りません。

2. クライアントオペレーティングシステムおよびそのシステムソフトウェアは、物理マシン上で実行されるのと同様に、仮想マシン上で実行できます。

3. 互換性が良く、インストールと使用が簡単です。

4. 性能は低い（VMMがバイナリコードを翻訳し、敏感な命令を置き換える必要があるため）。 半仮想化

5. 半仮想化ではGuest OSのカーネルを修正し、物理マシン上で実行される特権命令または敏感な命令をVMMのスーパーコールに変更します。

6. Guest OSは自分が仮想マシン環境で実行されていることを知っており、カーネルの特権命令や敏感な命令を直接呼び出すことはできません。Hostのカーネルを通じて直接CPUを呼び出します。

7. 性能向上、

8. しかし実現が困難です。 ハードウェア支援仮想化

CPUメーカーはCPUを改造し、新しい命令と実行モードを導入してVMMが敏感な命令を効率的に識別および捕捉するのを支援し、ハードウェアレベルで仮想化をサポートします。通常、Guest OSのコア命令は計算機システムハードウェアに直接下され、VMMを経由する必要はありません。特定の命令については、システムがVMMに切り替わり、VMMが特定の命令を処理します。

2.6.1.2 2、ストレージ仮想化

基盤ストレージデバイスを抽象化して統一プール管理し、外部に独立したストレージサービスを提供できます。

1. 高いスケーラビリティ、物理容量の制約から解放されます。

2. デバイスの複雑性を隠し、統一管理とサービスを提供します。

3. 空間資源を統合し、デバイスの利用率を向上させます。

4. 高信頼性、高可用性。 技術タイプ

5. ホストベースの仮想化（異種デバイスをサポートし、コストパフォーマンスが高いが、ホスト資源を占有し性能に影響を与え、ホストの安全性と安定性に影響を与え、拡張性が低い）

6. ストレージデバイスベースの仮想化（ホストの性能に影響を与えないが、特定のメーカーの異種デバイスをサポートしない）

7. ネットワークベースの仮想化

2.6.1.3 3、デスクトップ仮想化

リモートデスクトップサービスRDS

仮想デスクトップインフラストラクチャVDI

インテリジェントデスクトップ仮想化IDV

2.6.1.4 4、ネットワーク仮想化

OpenStackのコアサービス：計算サービスnova、ストレージサービスswift、イメージサービスglance

仮想化技術の欠点

1. 仮想マシンオペレーティングシステムの実行資源消費が大きく、起動時間が長い
2. 中間段階（ハイパーバイザー）がシステムのサービス性能を低下させる
3. ユーザーは自分のデプロイしたアプリケーションプログラムに関心があるが、オペレーティングシステムと付随する依存環境のデプロイと運用を行わなければならない

2.6.2 コンテナ化技術

コンテナ化はオペレーティングシステムカーネル上の軽量な仮想化技術です。共有されたオペレーティングシステムカーネルの機能を利用して、一連の資源が相互に隔離された閉じた実行環境を構築します。これらの閉じた実行環境はコンテナ（container）のように見え、アプリケーションプログラムはその中でデプロイされ実行されます。その利点は軽量、迅速、拡張性があり、DevOpsをサポートし、資源利用率を向上させコストを節約し、製品のイテレーションを加速し、マイクロサービスアーキテクチャをサポートし、運用自動化を実現します。

1. コンテナは同じオペレーティングシステムカーネルを共有します
2. コンテナはアプリケーションとその実行環境をパッケージ化します
3. 一度構築すれば、クロスプラットフォームでどこでも実行可能です
4. コンテナは軽量で迅速に起動し、低コストです コンテナの実現原理

1、namespace名前空間

名前空間は閉じたスコープ範囲を定義し、約束します：同じ名前空間にあるプロセスは、その名前空間内の資源（ホスト名、ネットワーク、プロセス、ユーザー、ファイルシステムなど）しか見ることができません。異なる名前空間のプロセスは互いに見えず、影響を与えません。コンテナは独自の名前空間を持つプロセスであり、コンテナ内で実行されるアプリケーションは独立したオペレーティングシステムで実行されているように見え、コンテナ間で相互に影響を与えません。

各プロセスは異なるタイプの資源を隔離するために7つの名前空間を持っています

2、Cgroups（制御グループ）

namespaceはプロセスを特定の環境に隔離できますが、プロセスが使用する物理資源を制限することはできません。cgroups（Control Groups）はLinuxカーネルが提供する物理資源隔離メカニズムで、Linuxプロセスまたはプロセスグループの資源を制限、隔離、統計する機能を実現できます。

コンテナはcgroupsを通じてコンテナが使用する物理資源（CPU、メモリ、IOなど）を隔離、制限、記録します。cgroupsは各コンテナを通常のプロセスとして扱います。プロセスグループまたは特定のプロセスの資源制限条件を設定することで、コンテナプロセスと他のプロセスを資源使用上で隔離する目的を実現します。

·         A. namespaceで資源を隔離します。

·         B. cgroupsで資源を制御します。

·         C. 各プロセスは異なるタイプの資源を隔離するために7つの名前空間を持っています。

·         D. cgroupsは各コンテナを通常のプロセスとして扱います。プロセスグループまたは特定のプロセスの資源制限条件を設定することで、コンテナプロセスと他のプロセスを資源使用上で隔離する目的を実現します。

3 大データ処理概説

3.1 大データ処理プロセス

大データ処理は、大データの収集と前処理、保存と管理、処理と分析、可視化表示などのタスクの総称です。

3.1.1 データ収集と前処理

データタイプ：構造化、半構造化、非構造化

データソース：ビジネスデータ、インターネットデータ、IoTデータ

収集方法：ログ収集、ウェブクローラー、API、政府企業機関の共有

データ前処理には以下が含まれます：

• データクリーニング 重複値の削除、欠損値の処理、列名の変更

• データ統合 相互に関連する分散異種データソースを論理的または物理的に統合し、ユーザーに透明なアクセスサービスを提供します。データ統合の方法には以下があります：

データ統合（ETL+データウェアハウス、物理的統一）

データフェデレーション（統一された論理ビューを作成）

データ伝播（データが複数のアプリケーション間で伝播）

混合方式

• データ変換 データをある表現形式から別の表現形式に変換します：

平滑化、集約、一般化、正規化、属性構築

• データ削減 データ分析の品質を保証した上で、データ規模を縮小します：

次元削減：ウェーブレット変換、PCA（主成分分析）、特徴選択

数量削減：クラスタリング、サンプリング、ロジスティック回帰

3.1.2 大データデータ処理と分析

• 分散コンピューティングモードとフレームワーク
  • バッチ処理：Hadoop、Spark
  • ストリーム処理：Storm、Flink
  • グラフ計算：Pregel、GraphX
• 大データ分析
  • インタラクティブクエリ：Hive、Pig、Spark SQL
  • データマイニング：Mahout
  • 機械学習：Mllib

3.1.3 大データ保存と管理

3.1.4 大データ解釈と可視化

3.2 分散コンピューティングの原理

分散システムはネットワーク内の一群のコンピュータノードが共同のタスクを完了するために構成された協調作業システムであり、高可用性、高性能、拡張性、耐障害性を要求します。分散ストレージと分散コンピューティングを含みます。シャーディングとレプリカは基本的な手段です。

HDFSがファイルをどのように保存するか

ファイルを固定サイズのユニットに分割し、ユニットを異なるノードに分散して保存し、アクセス時に各ノードから取り出して結合します。

HDFSがファイルをどのように書き込むか

クライアントはNamenodeにファイルを書き込むように要求し、Namenodeが準備を整えた後、クライアントに準備ができたことを通知します。クライアントが確認を受け取った後、データが書き込まれるまで以下の手順を繰り返します：（1）Namenodeにブロックを要求し、Namenodeがルールに基づいてData Nodeを選択し、クライアントに通知します。（2）クライアントが指定されたDatanodeにデータを送信し、Datanodeがデータを受け取り、ローカルに書き込みます。

HDFSがファイルをどのように読み取るか

クライアントはNamenodeにファイルを読み取るように要求し、Namenodeが準備を整えた後、そのファイルに対応するメタデータを返します。クライアントがファイルのメタデータ情報を受け取った後、対応するDatanodeに対応するブロックデータを要求し、最終的に完全なファイル内容を結合します。

データ分散ストレージの役割：

一、データ冗長性による可用性の向上。

二、読み書きの分離による性能の向上。

3.2.1 シャーディング

一定のルールに従ってデータセットを相互に独立した直交データサブセットに分割し、異なるノードに分散します。シャーディングは高性能、水平拡張、高可用性を実現できます。

シャーディングの要求：分布の均一性、負荷の均衡、データ移行の少なさ（拡縮容）

3.2.1.1 データ範囲に基づく

データをキーに基づいて異なる区間に分割し、各ノードが1つまたは複数の区間を担当します。

範囲クエリをサポートし、均衡を保証するのは容易ではありません。

3.2.1.2 ハッシュ方式

ハッシュ値とシステムノードの間にマッピング関係を構築し、異なるハッシュ値のデータを異なるノードに分散します。

不均衡問題を解決できます。

範囲クエリの性能に影響を与えます。

拡縮容には多くのデータを移行する必要があります。

3.2.1.3 一貫性ハッシュ

• ノード（サーバー）を特徴に基づいてハッシュリングにマッピングします。
• データを特徴に基づいて同じハッシュリングにマッピングします。
• データをリング上の時計回りの最初のノードに保存します。
• 各物理ノードに仮想ノードを設定し、仮想ノードにマッピングされたデータを対応する物理ノードに保存し、仮想ノードをハッシュリング上に均等に分散させ、データの偏りとノードの雪崩を回避します。 拡縮容にはわずかなデータを移行するだけで済みます。

データの偏りが発生する可能性があります。

データの偏りによるノードの雪崩が発生する可能性があります。

3.2.2 レプリカ

冗長レプリカを構築することは耐障害性と高可用性を実現する基本的な手段です。

3.2.2.1 レプリカの構築戦略

シングルマスター複製

シングルマスター複製には1つのマスターレプリカしかなく、他はすべて予備のスレーブレプリカです。マスターレプリカを維持するノードが中心ノードとして機能し、データの更新、並行制御、レプリカの一貫性の調整を担当します。

プロセス：マスターレプリカがダウンした後、スレーブから1つのマスターを選出し、ダウンしたマスターが復旧した後はスレーブに降格し、新しいマスターに同期します。スレーブレプリカがダウンした場合、復旧後にマスターからデータを再同期します。

存在する問題：

（1）可用性の問題：マスターがダウンした後のフェイルオーバー操作、スレーブの選出、サービスの新しいマスターへの切り替えには時間がかかり、その間システムがブロックされ、サービスを提供できません。

（2）データの一貫性の問題：マスターがダウンし、あるスレーブが選出を通じて新しいマスターになった場合、新旧のマスター間でデータがまだ同期されていないため、新しいスレーブが新しいマスターよりも多くのデータを持っている場合、データが不一致になります。

（3）コストの問題：スレーブレプリカは失敗時の移行にのみ使用され、ある程度の無駄があります。

マルチマスター複製

*すべてのレプリカがマスターであり、レプリカ間で相互に主従関係があります。*書き込み操作は任意のマスターによって処理され、他のマスターに同期されます。

マルチマスター複製では、並行操作時にデータの一貫性の問題が存在します。

マスターレス複製

マスターとスレーブレプリカを区別せず、クライアントがデータを更新する際に複数のレプリカに書き込み要求を送信します。クライアントがデータを照会する際に複数のレプリカに読み取り要求を送信します。

クライアントはデータ補償作業を行うことができますが、依然としてデータの一貫性の問題が存在します。

3.2.2.2 レプリカ同期戦略

同期複製（synchronous replication）

データがすべてのレプリカに複製された後にのみ、複製が完了したと見なされます。レプリカ間で強い一貫性を持ちますが、性能は高くありません。

非同期複製（asynchronous replication）

データがマスターレプリカに複製されるだけで、複製が完了したと見なされ、他のレプリカは非同期で処理されます。性能は高いですが、データが失われたり、データが汚染される可能性があります。

半同期複製（semi-synchronous replication）

データが一定数のレプリカに達したときに、複製が完了したと見なされます。性能と一貫性を兼ね備えています。

3.2.2.3 レプリカ一貫性モデル

CAP定理

分散システムは一貫性、可用性、分区耐障害性を同時に満たすことはできず、最大でそのうちの2つを満たすことができます。

• 一貫性（Consistency）：すべてのデータレプリカのデータが一貫していること。
• 可用性（Availability）：すべての要求が正しい応答を得られること。
• 分区耐障害性（Partition tolerance）：ネットワーク分区が発生しても、システムが一貫性と可用性を満たすサービスを提供できること。

ネットワーク分化はネットワークリンクに問題が発生し、クラスタノードが複数の分区に隔離され、分区間のネットワークが到達不能になることです。分区内部は正常です。

分散システムは分区耐障害性を保証する必要があります。そうでなければ、分散の意味が失われるため、一貫性と可用性の間でトレードオフを行う必要があります。

ACID

• Atomicity（原子性）：トランザクション内のすべての操作がすべて完了するか、すべて完了しないかのいずれかであり、中間の段階で終了しません。
• Consistency（一貫性）：トランザクションの開始前と終了後に、データベースが一貫した状態から別の一貫した状態に変わり、データの完全性が損なわれないこと。
• Isolation（隔離性）：複数の並行トランザクションが同時に実行されても、互いに干渉せず、データの不一致が発生しないこと。
• Durability（持続性）：トランザクション処理が終了した後、データの変更が永続的であり、システム障害が発生しても失われないこと。 BASE原理

BASEは一貫性を弱め、分区耐障害性と可用性を追求し、ACIDとは異なる2つの設計哲学を代表しています。

• 基本可用性（Basic Availability） システムが基本的に稼働し、常にサービスを提供できることを要求します。予測不可能な障害が発生した場合、一部の可用性の損失を許容します。たとえば、応答の遅延やサービスの低下などです。

• 软状态（Soft State，柔性状态） システム内のデータが中間状態にあることを許容し、その状態がシステムの全体的な可用性に影響を与えないと考えます。すなわち、異なるノードのレプリカ間で一時的な不一致が存在することを許容します。

• 最終的一貫性（Eventually Consistency） 更新が成功した後、すべてのレプリカのデータが最終的に完全に一致する状態に達することを要求しますが、完全に一致する状態に達するまでの時間は保証されません。

一貫性モデルは、分散システムでデータを複製する際に一貫性を維持するための基本的な制約を定義します。

• 強い一貫性 いつでも、どのユーザーまたはノードでも、最近の更新が成功したレプリカデータを読むことができます。一貫性の要求が最も高く、実際には最も実現が難しいです。

• 単調一貫性 いつでも、どのユーザーがあるデータの更新後の値を一度読んだ場合、そのユーザーはそれより古い値を再び読むことはありません。強い一貫性よりも弱いです。

• セッション一貫性 あるユーザーがあるデータの更新後の値をあるセッション内で一度読んだ場合、そのユーザーはそのセッション中にそれより古い値を再び読むことはありません。単調一貫性よりも弱く、異なるユーザー間の一貫性や同じユーザーの異なるセッション間の一貫性は保証されません。

• 最終的一貫性 最終的一貫性は、更新が成功した後、各レプリカのデータが最終的に完全に一致する状態に達することを要求しますが、完全に一致する状態に達するまでの時間は保証されません。

• 弱い一貫性 ある更新が成功した後、ユーザーは一定の時間内にその更新の値を読むことができず、特定のレプリカで新しい値を読んだとしても、他のレプリカで新しい値を読むことができる保証はありません。弱い一貫性のシステムは通常、実際には使用が難しく、弱い一貫性のシステムを使用するには、アプリケーションプログラムがシステムを利用可能にするために多くの作業を行う必要があります。

3.2.3 分散システムの一貫性プロトコル

‘

Lease、2PC、PAXOSは完全な一貫性を実現できます

3.2.3.1 Leaseメカニズム

中心ノードがメタデータを保存および管理し、各ノードのキャッシュされたメタデータが常に中心ノードのメタデータと一致することを保証する必要があります。

使用シナリオ：

（1）クライアントがキャッシュノードのメタデータを読み取る

メタデータがすでにキャッシュノードにあり、Leaseが有効期限内にあるかどうかを判断します。

もしそうであれば、メタデータを直接返します。

もしそうでなければ、中心ノードにデータの読み取りを要求します。中心ノードが読み取り要求を受け取ると、メタデータに対応するLeaseを返します。

キャッシュノードが受信に失敗またはタイムアウトした場合、読み取りが失敗し、プロセスを終了して再試行します。

受信が成功した場合、中心ノードが返したメタデータとそのLeaseを記録し、クライアントにメタデータを返します。

（2）クライアントがメタデータを変更する

クライアントが中心ノードにメタデータの変更を要求します。

中心ノードが要求を受け取ると、すべての新しいデータ読み取り要求をブロックし、読み取り要求を受け入れますが、データを返しません。

中心ノードがそのデータに関連するすべてのLeaseのタイムアウトを待ち、データを変更し、クライアントに変更成功の情報を返します。

3.2.3.2 法定人数

総計N個のレプリカがあると仮定し、書き込み操作が少なくともW個のレプリカを成功裏に更新する必要がある場合、更新が成功したと見なされ、読み取り操作が少なくともR個のレプリカを読み取る必要があります。要求：

W + R > N

ビジネスに応じてWとRを調整することで、信頼性と性能の面でトレードオフを行うことができます

3.2.3.3 二段階コミットプロトコル（2PC）

分散トランザクションの一貫性を維持するためのプロトコルであり、同期複製プロトコルに属し、すべてのレプリカデータが同期完了した後にのみクライアントに結果を返します。

2PCはデータの複製を2つの段階に分けます

表決段階：マスターノードがデータをすべてのレプリカに送信し、各レプリカがコミットまたはロールバックを表決します。レプリカがコミット票を投じた場合、データを一時領域に配置し、最終的なコミットを待ちます。

コミット段階：マスターノードが他のレプリカの応答を受け取った場合、すべてのレプリカがコミット票を投じた場合、すべてのレプリカにコミットを確認するメッセージを送信し、更新をコミットさせます。データは一時領域から永続領域に移動されます。1つのレプリカがロールバックを返した場合、全体がロールバックされます。

2PCは典型的なCAシステムであり、一貫性と可用性を保証するために、ネットワーク分区やノードの利用不可が発生した場合、書き込み操作を拒否し、システムを読み取り専用にします。

ノードがダウンした場合、2PCはシステムをブロックし続けるため、データの複製シナリオではあまり使用されず、通常は分散トランザクションで使用されます。

3.2.3.4 Paxosプロトコル

多主複製の一貫性を保証するためのアプリケーションシナリオ（状態機械複製+コンセンサスアルゴリズム）。

3つの役割

• Proposer（提案者）：提案を提出する役割で、複数存在することができます。
• Acceptor（表決者）：提案に対してaccept表決を行う役割。
• Learner（同期者）：決定された提案を同期する役割。 提案：データ更新要求であり、[提案番号n、提案内容value]として表現できます。

手順：

• 各提案者Proposerは提案を提出する際に、全局的に一意で増加する提案番号Nを取得し、その番号を提案に付与します。
• 各表決者Accepterはacceptした提案後、その提案の番号Nをローカルに記録し、最大の提案番号をMaxNとします。各表決者は自分のローカルMaxNより大きい番号の提案のみをacceptします。
• 1回の選挙で、最終的に1つの提案だけが選定されます。
• 1つの提案が選定されると、他のノードはその提案を自動的に同期（learn）します。
• 提案が提出されなかった場合、提案は選定されません。 prepare-promise, propose-accept or learn, learn

Basic PaxOSの問題は、1つの値に対してのみ決定を形成できることです。決定の形成には少なくとも2回のネットワーク往復が必要であり、高並行性の状況ではさらに多くのネットワーク往復が必要になる可能性があります。極端な場合には活性ロック（livelock、2つのノードが1つの値を競争すること）が発生する可能性もあります。

Multi-PaxosはBasic Paxosに基づいて2つの改善を行いました：

1. 確定する必要のある各値に対して、1回のPaxosアルゴリズムインスタンス（Instance）を実行して決定を形成します。各Paxosインスタンスは一意のInstance IDで識別されます。
2. すべてのProposersの中から1つのリーダーを選出し、リーダーが唯一のProposalをAcceptorsに提出して表決を行います。これにより、Proposerの競争がなくなり、活性ロックの問題が解決されます。システムに1つのリーダーだけがValueを提出する場合、Prepare段階をスキップできるため、2段階を1段階に変え、効率を向上させます。 このようにして、ネットワーク分化の状況でも複数のリーダーが存在する場合、multi-paxosは最大でbasic-paxosに退化します。

3.2.4 参考記事

時計

分散システムにおける3種類のイベントは、いずれも時計を増加させることができます

1. ノード内部イベント
2. 送信イベント
3. 受信イベント 分散システムで論理時計を構築する2つの方法

Lamportは因果関係のみを表現できます

ベクター時計（vector clock）は因果関係と並行関係を表現できます

①Lamportタイムスタンプは論理時計の表現法の1つで、単調に増加する整数です。一定のルールに従って分散システム内の各イベントにLamportタイムスタンプを付与し、タイムスタンプの数値の大小を比較することで、イベントの偏序関係を確定できます。

ルール

• 各ノードにはローカルのタイムスタンプがあり、初期値は0です。
• イベントがノード内で発生した場合、ローカルタイムスタンプを1増加させます。
• 送信イベントの場合、ローカルタイムスタンプを1増加させ、メッセージにそのタイムスタンプを付与します。
• 受信イベントの場合、ローカルタイムスタンプ = Max（ローカルタイムスタンプ、メッセージ内のタイムスタンプ） + 1です。 イベントの先後関係：タイムスタンプで並べ替え、同じ場合はノード番号で並べ替えます（特に注意してください。ノード番号は問題によって与えられます！！！！！！！！！！！！）

②ベクター時計はLamportタイムスタンプに基づいて進化した別の論理時計方法で、ベクター構造（Vector）を使用してローカルノードのLamportタイムスタンプと他のノードのLamportタイムスタンプを記録し、同時発生関係やイベントの因果関係をよく表現できます。ベクター時計アルゴリズムは、ベクターというデータ構造を利用して、グローバルな各プロセスの論理タイムスタンプを各プロセスにブロードキャストします：各プロセスが送信イベントを行う際に、現在のプロセスが知っているすべてのプロセスの時間をベクターに書き込み、メッセージに添付します。

イベントの先後関係：Tb[Q] > Ta[Q] かつ Tb[P] < Ta[P] の場合（つまり、Qノードでイベントbが先に発生し、Pノードでaが先に発生した場合）、aとbは同時に発生したと見なされ、a <-> bと記録されます。これはLamportタイムスタンプでは表現できない並行関係（concurrent）です。

3.3 大データシステム構造

大データシステムとは何かを簡単に説明し、大データシステムを構築する際に考慮すべき要求をどのようにバランスさせるか）

大データシステム：データ収集と前処理、保存と管理、処理と分析、可視化表示などの大データ処理機能を統合した高性能、拡張性、高可用性、高耐障害性、安全で使いやすいソフトウェアとハードウェアのシステムです。ユーザーが大データの中に潜在する価値のある情報と知識を発見し、ビジネスの現実を把握し、ビジネスの方向性を予測するのを支援します。

大データシステムの構造は、大データシステムの構築要求とマクロ的な意思決定に依存します。これにはビジネス目標、データソースのタイプと特徴、性能要求、バッチ処理/ストリーム処理（計算フレームワーク）、技術選択などが含まれます。

3.3.1 伝統的なBIアーキテクチャ

データソース+ETL+データウェアハウス+分析レポート

• データウェアハウスを中心とした構造化分析であり、非構造化分析が不足しています。
• ETLデータ前処理機能が複雑で臃腫です。
• ACID特性があり、性能に影響を与え、大規模なデータに対応できません。

3.3.2 バッチ処理アーキテクチャ

データソース+ETL+データ保存+バッチ処理+分析レポート

• 長所：簡単で使いやすく、技術選択時にBIコンポーネントを大データコンポーネントに置き換えることができます。
• 短所：①データウェアハウスがビジネスをサポートする柔軟性がなく、多くのレポートや複雑なドリルダウンシナリオには手動でカスタマイズが必要です。②バッチ処理が主であり、リアルタイムのサポートが不足しています。
• 適用シナリオ：BIシナリオを主とし、大規模な履歴データのオフライン分析に適しています。

3.3.3 ストリーム処理アーキテクチャ

**データソース+リアルタイムデータチャネル+ストリーム処理+**メッセージプッシュ

• 長所：臃腫なETLプロセスがなく、データの即時性が高いです。
• 短所：バッチ処理が存在せず、データのリプレイと履歴統計を十分にサポートできません。オフライン分析にはウィンドウ内の分析のみをサポートします。
• 適用シナリオ：警告、監視、データに有効期限の要求がある場合。

3.3.4 Lambdaアーキテクチャ

Lambdaアーキテクチャ：バッチ処理層+ストリーム処理層+サービス層。データは追加の方法で2つのパスを通じてバッチとストリーム処理システムに並行して書き込まれます。バッチとストリームの2つの処理パスに対応するデータ計算ロジックを提供します。最終的にサービス層を通じて計算結果ビューを統合し、外部サービスの出力を行います。

• 長所：リアルタイム+オフライン分析であり、データ分析シナリオを包括的にカバーします。
• 短所：バッチ処理層と速度層の2つのシステムを維持する必要があります：Hadoop & Storm。同じビジネス計算ロジックを2つの層でそれぞれ実装および運用する必要があります。クエリ結果の統合が複雑であり、運用が複雑です。
• 適用シナリオ：リアルタイムとオフラインのニーズが同時に存在する場合。

3.3.5 Kappaアーキテクチャ

Lambdaアーキテクチャを簡素化し、バッチ処理システムを削除し、すべてのデータをリアルタイムパスで処理し、すべてのデータをストリームとして扱います。ストリーム処理システムを通じてリアルタイムデータと履歴データを全体的に処理します。データはイベントとして順序に従ってフォールトトレラントな分散統一ログに導入されます。イベントストリームはリアルタイムデータとして速度層に入り、ストリーム処理を行い、リアルタイムビューを生成します。イベントストリームは同時に長期保存されます。必要に応じてイベントストリームをリプレイし、ストリーム計算エンジンを通じて履歴データのビューを再計算します。

• 長所：Lambdaアーキテクチャの冗長部分を解決し、データのリプレイの考え方で設計され、アーキテクチャがシンプルです。
• 短所：実施の難易度が高く、特にデータリプレイ部分が難しいです。
• 適用シナリオ：リアルタイムとオフラインのニーズが同時に存在する場合。

4 Hadoop

Hadoopのバージョンの進化：

2.0でYarnを追加

3.0でMapReduceがメモリベースの計算をサポートし、複数のNameNodeをサポートし、カーネルを簡素化

Hadoopの3つのコアコンポーネント：HDFS、MapReduce、YARN

役割：5731

◼ HDFSは分散ストレージフレームワークであり、ファイルを複数の計算機ノードに分散して保存し、海量データの保存に適しています。

◼ MapReduceは分散計算フレームワークであり、大規模クラスター上の並列計算プロセスを2つの関数：Map、Reduceに抽象化し、「分割して治める」戦略を採用し、分散ファイルシステムに保存された大規模データセットを多数の独立したスプリットに分割し、これらのスプリットを複数のMapタスクが並行して処理します。

◼ Yarnは資源スケジューリングプラットフォームとして機能し、さまざまな計算フレームワークの負荷要求に応じて、それぞれが占有する資源を調整し、クラスター資源の共有と資源の弾力的な収縮を実現します。

4.1 HDFS

4.1.1 HDFSの体系構造

HDFSの体系構造は主従（Master/Slave）構造モデルを採用しており、通常、1つのHDFSクラスターには以下が含まれます：

（1）1つの名称ノード（NameNode）：名称ノードは中心サーバーとして機能し、ファイルシステムの命名空間およびクライアントによるファイルへのアクセスを管理します。

（2）複数のデータノード（DataNode）：各データノードはdatanodeプロセスを実行し、クライアントの読み取り/書き込み要求を処理し、名称ノードの統一スケジューリングの下でデータブロックの作成、削除、複製などの操作を行います。データノードのデータは実際にはローカルのLinuxファイルシステムに保存されています。

4.1.2 HDFSの保存原理

システムの耐障害性と可用性を保証するために、HDFSはデータを冗長に保存するために複数のレプリカ方式を採用しています。通常、1つのデータブロックの複数のレプリカは異なるデータノードに分散されます。クライアントは優先的に同じラック内のデータを使用します。利点：

（1）データ転送速度の向上

（2）データエラーの容易な検出

（3）データの信頼性の保証

レプリカ保存戦略：

（1）最初のレプリカ：アップロードされたファイルのデータノードに配置されます。クラスター外からの提出の場合、ランダムにディスクがあまり満たされておらず、CPUがあまり忙しくないノードを選択します。

（2）2番目のレプリカ：最初のレプリカとは異なるラックのノードに配置されます。

（3）3番目のレプリカ：最初のレプリカと同じラックの他のノードに配置されます。

（3）それ以上のレプリカ：ランダムなノードに配置されます。

4.1.3 データの読み書きプロセス

ファイルの書き込み

クライアントがNamenodeにファイルの書き込みを要求し、namenodeが準備を整えた後、クライアントに通知します。クライアントが確認を受け取った後、データが書き込まれるまで以下の手順を繰り返します：

1、Namenodeにブロックを要求し、Namenodeがルールに基づいてDataNodeを選択し、クライアントに通知します。

2、クライアントが指定されたDatanodeにデータを送信し、Datanodeがデータを受け取り、ローカルに書き込みます。

ファイルの読み取り

クライアントがName Nodeにファイルの読み取りを要求し、Namenodeが準備を整えた後、そのファイルに対応するメタデータ情報を返します。クライアントがファイルのメタデータ情報を受け取った後、対応するDataNodeに対応するブロックデータを要求し、最終的に完全なファイル内容を結合します。

4.1.4 データエラーと復旧

1、名称ノードのエラー

名称ノードはすべてのメタデータ情報を保存しており、エラーが発生するとHDFSクラスター全体が無効になります。HDFSはチェックポイントメカニズムを設定し、これらのメタデータを定期的にバックアップサーバーSecondaryNameNodeにコピーします。名称ノードがエラーを起こした場合、SecondaryNameNodeに基づいてNameNodeメタデータデータを復旧できます。

2、データノードのエラー

• 各データノードは定期的に名称ノードにハートビート情報を送信し、自分の状態を報告します。
• データノードが故障またはネットワーク異常が発生し、名称ノードがデータ集ノードからのハートビート情報を受信できない場合、データノードはダウンとしてマークされ、そのノード上のすべてのデータは読み取り不可としてマークされ、名称ノードはそれらに対してI/O要求を送信しません。
• 名称ノードは定期的にデータブロックのレプリカ数をチェックし、冗長因子より少ない場合、データ冗長複製を開始します。 3、データのエラー

ネットワーク転送やディスクエラーなどの要因でデータエラーが発生する可能性があります。クライアントはデータを読み取った後、md5コードとsha1を使用してデータブロックを検証し、正しいデータを読み取ったことを確認します。

4.2 Map Reduceの体系構造

4.2.1 計算モデル

• 大規模クラスター上の並列計算プロセスを2つの関数：Map、Reduceに抽象化します。
• プログラミングが簡単であり、分散並列プログラミングの煩雑な詳細を習得することなく、自分のプログラムを分散システム上で実行し、海量データの計算を実現できます。
• 「分割して治める」戦略を採用し、分散ファイルシステムに保存された大規模データセットを多数の独立したスプリット（split）に分割し、これらのスプリットを複数のMapタスクが並行して処理します。
• 設計理念は「計算をデータに近づける」ことであり、「データを計算に近づける」ことではありません。なぜなら、データを移動するには大量のネットワーク転送コストが必要だからです。
• Master/Slaveアーキテクチャを採用し、1つのMasterと複数のSlave（またはWorker）を含みます。Master上でJobTrackerが実行され、ジョブのスケジューリング、処理、失敗後の復旧を担当し、Slave上でTaskTrackerが実行され、JobTrackerからのジョブ指令を受け取ります。

4.2.2 4つの構成要素

1、クライアント：

• aユーザーがMapReduceプログラムを作成し、クライアントを通じてJobTrackerに送信します。

• bユーザーはクライアントが提供するインターフェースを通じてジョブの実行状態を確認できます。 2、Job Tracker：

• a資源の監視とジョブのスケジューリングを担当します。

• bすべてのTask Trackerとジョブの健康状態を監視し、失敗が発生した場合、対応するタスクを他のノードに移動します。

• c JobTrackerはタスクの実行進捗、資源使用量などの情報を追跡し、これらの情報をタスクスケジューラ（TaskScheduler、プラグイン可能、カスタマイズ可能）に伝えます。スケジューラは資源が空いているときに、適切なタスクを選択してこれらの資源を使用させます。 3、Task Tracker：

• a Task Trackerは周期的に「ハートビート」を通じて本ノード上の資源の使用状況とタスクの実行進捗をJobTrackerに報告し、JobTrackerから送信された命令を受け取り、対応する操作を実行します（新しいタスクの起動、タスクの停止など）。

• b Task Trackerは本ノード上の資源量（CPU、メモリなど）を「スロット（slot）」で等量に分割します。タスクはスロットを取得して初めて実行の機会を得ることができ、Hadoopのタスクスケジューラの役割は各TaskTracker上の空いているスロットをタスクに割り当てて使用させることです。（スロットはMapスロットとReduceスロットの2種類に分かれ、それぞれMapTaskとReduce Taskに使用されます。） 4、Task：Map TaskとReduce Taskの2種類があり、Task Trackerによって起動されます。

作業フロー

（1）プログラムのデプロイ；（2）MapタスクとReduceタスクの割り当て；（3）mapノードがデータを読み取り、mapタスクを実行して中間結果を溢れさせる；（4）reduceノードが中間結果データを受け取り、reduceタスクを実行する；（5）実行結果をHDFSに書き込む。

4.3 Yarnの体系構造

4.3.0.1 Resource Manager

クライアント要求の処理、NodeManagerの監視、Application Masterの起動と監視、資源のスケジューリングと割り当て

全体的な資源管理者であり、システム全体の資源管理と割り当てを担当します。2つのコンポーネントを含みます：スケジューラ（Scheduler）とアプリケーション管理者（Applications Manager）。

（1）スケジューラは、クラスター資源を「コンテナ」の形でアプリケーションに割り当て、通常、アプリケーションが処理するデータの位置を考慮して、近くの選択を行い、「計算をデータに近づける」ことを実現します。スケジューラはプラグイン可能なコンポーネントであり、YARNは多くの直接使用可能なスケジューラを提供するだけでなく、ユーザーが自分のニーズに応じてスケジューラを再設計することも許可しています。

（2）アプリケーション管理者は、システム内のすべてのアプリケーションを管理し、アプリケーションの提出、スケジューラとの資源交渉によるApplicationMasterの起動、ApplicationMasterの実行状態の監視、失敗時の再起動などを行います。

4.3.0.2 Application Master

主な機能は：

（1）ユーザージョブが送信された後、ApplicationMasterはResource Managerと協議して資源を取得し、ResourceManagerはコンテナの形でApplication Masterに資源を割り当てます。

（2）ApplicationMasterは取得した資源を内部の各タスク（MapまたはReduceタスク）にさらに割り当て、資源の「二次割り当て」を実現します。

（3）NodeManagerと相互通信を行い、アプリケーションの起動、実行、監視、停止を行い、取得した資源の使用状況を監視し、すべてのタスクの実行進捗と状態を監視し、タスクが失敗した場合に失敗復旧（つまり、資源を再取得してタスクを再起動）を実行します。

（4）ResourceManagerに「ハートビート」メッセージを定期的に送信し、資源の使用状況とアプリケーションの進捗情報を報告します。

（5）ジョブが完了した場合、ApplicationMasterはResourceManagerのアプリケーション管理者にコンテナを登録解除し、実行サイクルを完了します。

4.3.0.3 Node Manager

NodeManagerはYARNクラスター内の各ノードに常駐するエージェントであり、主に以下を担当します：

1. コンテナのライフサイクル管理、各コンテナの資源（CPU、メモリなど）の使用状況の監視
2. ノードの健康状態の追跡、「ハートビート」の形でResourceManagerと通信を保ち、ジョブの資源使用状況と各コンテナの実行状態を報告し、ApplicationMasterからのコンテナの起動/停止要求を受け入れます。 注意：NodeManagerは主に抽象的なコンテナの管理を担当し、各タスク（MapタスクまたはReduceタスク）の状態管理を具体的に担当しません。タスク状態の管理作業はApplicationMasterが行い、ApplicationMasterはNodeManagerと継続的に通信して各タスクの実行状態を把握します。

JobHistoryServer：YARNの歴史的なジョブを統一管理します。

WebAppProxyServer：ジョブ実行時のWebページプロキシ。具体的なMapReduceジョブの実行全過程を監視し、Containerから収集したジョブ実行情報をまとめてWebインターフェースに表示します。

4.3.0.4 Yarnの作業フロー

ステップ1：ユーザーがクライアントアプリケーションを作成し、YARNに送信します。送信内容にはApplicationMasterプログラム、ApplicationMasterの起動コマンド、ユーザープログラムなどが含まれます。

ステップ2：YARNのResourceManagerはクライアントからの要求を受け取り、処理し、アプリケーションにコンテナを割り当て、そのコンテナでApplicationMasterを起動します。

ステップ3：ApplicationMasterが作成されると、まずResourceManagerに登録します。

ステップ4：ApplicationMasterはポーリング方式でResourceManagerに資源を要求します。

ステップ5：ResourceManagerは「コンテナ」の形で要求を提出したApplicationMasterに資源を割り当てます。

ステップ6：コンテナ内でタスクを起動します（実行環境、スクリプト）。

ステップ7：各タスクはApplicationMasterに自分の