武大胆

発展の歴史#

新しい事物の誕生は古い矛盾の解決と新しい矛盾の誕生に根ざしており、その本質は矛盾運動の段階的結果である；

矛盾は事物の内在的な普遍的属性であり、発展は矛盾の不断の「発生 - 解決 - 再生産」によって実現される動的プロセスである。

ビッグデータ技術の誕生は本質的にストレージと計算の矛盾であり、発展は「データ規模の爆発的成長と計算効率、リアルタイム性の要求との持続的な駆け引き」である。この矛盾が技術の不断の革新を促進している。

データ規模の膨張 vs ストレージと計算能力の不足#

• 矛盾の本質：従来の単一システムは指数関数的に増加するデータ量（TB から PB、さらには EB レベル）を支えることができない。
• 技術の突破：
  • 分散ストレージ（HDFS、クラウドストレージなど）はデータを複数のノードに分散させ、ストレージのボトルネックを解決する。
  • 分散計算フレームワーク（MapReduce、Spark など）は並列処理によって計算スループットを向上させる。

バッチ処理の遅延 vs リアルタイム性の要求#

• 矛盾の本質：初期の Hadoop はオフラインバッチ処理のみをサポートしており（時間 / 日単位の遅延）、ビジネスは秒単位またはミリ秒単位の応答を必要としている。
• 技術の突破：
  • メモリ計算（Spark）はディスク I/O を減少させ、バッチ処理の速度を向上させる。
  • ストリーム処理エンジン（Flink、Kafka Streams）は「データを流れの中で計算する」ことを実現し、リアルタイム分析の要求を満たす。

データの多様性 vs 処理パラダイムの単一性#

• 矛盾の本質：構造化、半構造化、非構造化データ（テキスト、画像など）の複雑性は、従来のデータベースの単一処理モデルと互換性がない。
• 技術の突破：
  • マルチモーダルストレージ：NoSQL（MongoDB など）、データレイク（Delta Lake など）は柔軟なデータモデルをサポートする。
  • ハイブリッド計算エンジン：Spark はバッチ処理、ストリーム処理、グラフ計算、機械学習をサポートし、「ワンストック」処理を実現する。

リソースの静的割り当て vs 動的弾力性の要求#

• 矛盾の本質：固定されたクラスターリソースは利用率が低く、ビジネスの変動に対応できない。
• 技術の突破：
  • クラウドネイティブアーキテクチャ：Kubernetes はコンテナ化された弾力的なスケーリングを実現し、Serverless（AWS Lambda など）は必要に応じてリソースを割り当て、コストを削減する。

集中型ガバナンス vs 分散型の複雑性#

• 矛盾の本質：データが複数のシステム（データベース、データレイク、ストリームプラットフォーム）に分散しているため、統一的な管理と品質保証が難しい。
• 技術の突破：
  • データファブリック：メタデータ管理（Apache Atlas など）や自動化パイプライン（Airflow など）を通じて、クロスプラットフォームのデータ協調を実現する。
  • レイクハウス：Delta Lake などのツールはデータレイクの柔軟性とデータウェアハウスのガバナンス能力を融合させる。

まとめ - 矛盾がイノベーションを駆動する#

ビッグデータ技術の進化は本質的に **「古いバランスを打破し、新しいバランスを築く」** プロセスである：

• **Hadoop の「ストレージと計算の交換」からSpark の「メモリと速度の交換」** へ；
• バッチ処理の確定性からストリーム処理の不確定性への対応へ；
• 固定リソースの割り当てからクラウドネイティブの弾力的スケーリングへ。

矛盾の激化は新技術の誕生を促し、未来のトレンド（エッジコンピューティング、AI ネイティブデータプラットフォームなど）は依然としてこの核心的な矛盾を中心に展開される。

技術体系#

エコシステムアーキテクチャ#

データ収集層#

• 目標：複数のソース（データベース、ログ、センサーなど）から効率的にデータを収集する。
• ツール：
  • バッチ収集：Sqoop（リレーショナルデータベース ↔ Hadoop）、Flume（ログ収集）。
  • リアルタイム収集：Kafka（分散メッセージキュー）、Debezium（CDC 変更キャプチャ）。
  • クローラー：Scrapy、Apache Nutch（ウェブデータのスクレイピング）。

データストレージ層#

• 分散ファイルシステム：
  • HDFS：Hadoop エコシステムのコアストレージ、冷データに適している。
  • オブジェクトストレージ：AWS S3、阿里云 OSS（クラウドネイティブシーン）。
• NoSQL データベース：
  • キー・バリュー型：Redis（メモリキャッシュ）、DynamoDB（高並列）。
  • 列ストレージ：HBase（膨大なランダム読み書き）、Cassandra（高可用）。
  • ドキュメント型：MongoDB（柔軟な JSON 構造）。
• データレイク：Delta Lake、Iceberg（ACID トランザクションをサポートするレイクハウスアーキテクチャ）。

リソース管理とスケジューリング層#

• クラスター管理：
  • YARN：Hadoop リソーススケジューラ。
  • Kubernetes：コンテナ化オーケストレーション、ハイブリッドクラウドデプロイをサポート。
• ワークフローエンジン：
  • Airflow：タスク依存関係管理と定期スケジューリング。
  • DolphinScheduler：国産の可視化スケジューリングツール。

データ計算層#

• バッチ処理：
  • MapReduce：Hadoop ネイティブ計算モデル、オフラインタスクに適している。
  • Spark SQL：SQL 構文に互換性があり、複雑な ETL プロセスを最適化する。
• ストリーム処理：
  • Flink：低遅延ストリーム処理、状態管理とウィンドウ計算をサポート。
  • Spark Streaming：マイクロバッチ処理、Spark エコシステムとシームレスに統合。
• インタラクティブクエリ：
  • Presto：複数のデータソースのフェデレーションクエリ、即席分析に適している。
  • ClickHouse：列指向ストレージ、OLAP シーンでの迅速な応答。

データ分析と掘削層#

• 機械学習：
  • Spark MLlib：分散機械学習ライブラリ。
  • TensorFlow/PyTorch：深層学習フレームワーク、大データプラットフォームとの統合（Horovod など）。
• データ可視化：
  • Tableau/Power BI：ビジネスインテリジェンスツール。
  • Superset/Grafana：オープンソースの可視化ダッシュボード。
• グラフ計算：Neo4j（グラフデータベース）、GraphX（Spark グラフ処理ライブラリ）。

データガバナンスとセキュリティ#

• メタデータ管理：Apache Atlas（データ系譜追跡）。
• データ品質：Great Expectations（データ検証フレームワーク）。
• セキュリティコンプライアンス：Kerberos（認証）、Ranger（権限管理）、GDPR コンプライアンスツール。

データ層#

ビッグデータアーキテクチャにおいて、データ層（Data Layer）は、データを処理段階、用途、アクセス要求に応じて異なる層に分ける設計方法であり、データ管理の効率を向上させ、冗長性を低減し、性能を最適化し、多様な分析シーンをサポートすることを目的としている。

原始データ層#

データ運用層：Operation Data Store データ準備区、ソース層とも呼ばれる。

入力テーブル：無（データソースに直接接続）
出力テーブル：原始データテーブル（Raw Data Tables）
例：

• ユーザークリックログテーブル（ods_user_click_log）

{
  "timestamp": "2023-10-01T14:22:35+08:00",
  "user_id": "u_12345",
  "event": "click_product_detail",
  "device": "Android 12|Xiaomi 13 Pro",
  "ip": "192.168.1.100",
  "extra": "{'product_id':'p_678', 'page_num':3}"
}

• MySQL 注文テーブルのスナップショット（ods_order_mysql）

特徴：原始データのすべてのフィールドを保持し、冗長で未洗浄の情報を含む。

洗浄と標準化層#

入力テーブル：ods_user_click_log, ods_order_mysql
出力テーブル：洗浄された構造化テーブル
例：

• 標準化クリックログテーブル（cleaned_user_click）

処理ロジック：

• extraフィールドの JSON を解析し、product_idとpage_numを抽出する。
• user_idを純数字に統一する（接頭辞u_を除去）。
• ipフィールドをハッシュ化してデータを脱敏する。
• deviceフィールドをオペレーティングシステムとデバイスモデルに分割する。

• 統一注文テーブル（cleaned_order）

処理ロジック：

• 通貨を CNY に変換する（1 USD=7.0 CNY と仮定）。
• ステータスコードをマッピングする（pending→1, completed→2）。

統合とモデリング層#

データ詳細層：データウェアハウスの詳細、DWD/次元モデル
この層はビジネス層とデータウェアハウスの隔離層であり、ODS 層と同じデータ粒度を保持する；主に ODS データ層に対してデータの洗浄と標準化の操作を行い、空データ、汚れたデータ、外れ値などを除去する。
データ中間層：データウェアハウスミドル、DWM；
この層は DWD 層のデータに基づいて、データに対して軽微な集約操作を行い、いくつかの中間結果テーブルを生成し、共通指標の再利用性を高め、重複加工の作業を減少させる。

入力テーブル：cleaned_user_click, cleaned_order
出力テーブル：次元テーブル + 事実テーブル
例：

• 次元テーブル：ユーザー次元（dim_user）

• 事実テーブル：注文取引事実テーブル（fact_order）

モデリングロジック：

• user_idを通じて事実テーブルと次元テーブルを関連付け、「性別による注文金額分析」などのシーンをサポートする。

集計と集約層#

データサービス層：データウェアハウスサービス、DWS/データマート；
この層は DWM の基礎データに基づいて、特定のテーマ領域のデータサービス層を統合し、集約するものであり、一般的には幅広いテーブルを提供し、後続のビジネスクエリ、OLAP 分析、データ配信などに使用される。
一般的に、この層のデータテーブルは比較的少なく、1 つのテーブルが比較的多くのビジネス内容をカバーし、フィールドが多いため、この層のテーブルは幅広いテーブルとも呼ばれる。

入力テーブル：fact_order, dim_user
出力テーブル：事前集約された幅広テーブル
例：

• 毎日のユーザー消費集計テーブル（dws_user_daily_spend）

計算ロジック：

• 日ごとに各ユーザーの注文総額、注文数、平均額を集約する。
• 次元テーブルを関連付けて性別フィールドを取得し、「異なる性別のユーザー消費比較」レポートを迅速に生成する。

アプリケーションとサービス層#

データアプリケーション層：アプリケーションデータサービス、ADS；
この層はデータ製品とデータ分析に使用されるデータを提供するものであり、一般的には ES、Redis、PostgreSql などのシステムに保存され、オンラインシステムで使用される；また、hive や Druid に保存され、データ分析やデータ掘削に使用されることもある。例えば、一般的なデータレポートはここに保存されている。

入力テーブル：dws_user_daily_spend
出力テーブル：ビジネスインターフェースまたはレポート
例：

• BI レポートデータ（ads_bi_gender_spend）

• API 応答（ユーザー画像インターフェース）

{
  "user_id": 123,
  "last_purchase_date": "2023-10-01",
  "total_spend_7d": 299.00,
  "favorite_category": "電子製品"
}

特徴：データは高度に集約され、フィールド名はビジネス用語に準拠しており、展示や意思決定に直接使用できる。

ETL#

コア定義#

ETL は、データがソースシステムからターゲットストレージに移動する標準化されたプロセスであり、3 つの段階を含む：

1. Extract（抽出）：異種データソースから原始データを抽出する。
2. Transform（変換）：データを洗浄、標準化、加工する。
3. Load（ロード）：処理されたデータをターゲットストレージに書き込む。

技術スタックとツール#

参考#

データウェアハウスにおけるデータ層の詳細：ODS、DWD、DWM、DWS、ADS