6. Storage

ストレージシステムを構成する要素、ストレージシステム、ストレージ抽象について。

• Data engineering storage abstractions
  • データレイク
  • データレイクハウス
  • データプラットフォーム
  • クラウドデータウェアハウス
• Data storage systems
  • HDFS
  • キャッシュ/メモリベースのストレージ
  • RDBMS
  • オブジェクトストレージ
  • ストリーミングストレージ
• Raw ingredients of data storage
  • HDD
  • SSD
  • RAM
  • ネットワーク
  • シリアライズ
  • 圧縮
  • CPU

6.1 Raw Ingredients of Data Storage

6.1.1 Magnetic Disk Drive / 6.1.2 Solid-State Drive

HDDはコストが低く、並列処理によって高い転送速度を得ることができる。

SSDはコストが高く、性能が高い。

データレイクやクラウドデータウェアハウスにおける大規模データストレージの主要な選択肢としては、HDDを用いたオブジェクトストレージが採用される。

6.1.3 Random Access Memory

RAMは様々なストレージや処理システムで使用されており、キャッシュ、データ処理、インデックスなどに用いられる。

6.1.4 Networking and CPU

性能、耐久性、可用性を向上させるために、ストレージクラスを分散させるケースが増えている。

データエンジニアは、システムに対してネットワークがどのように影響を与えるかを理解しなければならない。

6.1.5 Serialization

シリアライズの方法は、ネットワークを経由したクエリの性能やCPUオーバーヘッド、クエリレイテンシなどに影響する。

データエンジニアは、一般的なシリアライズの手法やフォーマットに精通するようにしよう。

最も普及しているフォーマット (Apache Parquet)、ハイブリッドシリアライズ (Apache Hudi)、インメモリシリアライズ (Apache Arrow) など。

6.1.6 Compression

高効率の圧縮アルゴリズムには、ディスクの省スペース化、スキャン速度の高速化、ネットワーク性能の向上、の利点がある。

6.1.7 Caching

アクセス頻度に合わせてキャッシュを使い分けよう。

CPUキャッシュ、RAM、SSD、HDD、オブジェクトストレージ、アーカイブストレージ。

6.2 Data Storage Systems

6.2.1 Single Machine Versus Distributed Storage

単体サーバ vs 分散ストレージ。

分散ストレージは、複数サーバを強調動作させることで、データをより高速かつ大規模に保存検索、処理すると同時に、1つのサーバが停止した場合に備えて冗長性を与える。

6.2.2 Eventual Versus Strong Consistency

データエンジニアは、分散システムの一貫性パラダイムを常に意識しなければならない。

ACIDは、データの一貫性を重視し、トランザクションの信頼性と永続性を重視する。

BASEは、データの可用性と柔軟性を重視し、最終的な一貫性は保証するが、即座の一貫性は保証しない。

• Basically Available (基本的な可用性)
• Soft state (柔軟な状態)
• Eventually consistent (最終的な一貫性)

6.2.3 File Storage

ファイルストレージの特徴

• 有限長のバイトストリームである
• ファイルにバイトを追記できる
• ファイル内のどこからでも Read/Write できる。

ローカルディスクストレージ、NAS (ネットワークアタッチトストレージ)、クラウドファイルシステムサービス

6.2.4 Block Storage

データを固定サイズのブロックに分割して保存する。各ブロックには一意のアドレスが割り当てられる。ランダムアクセスが効率的。

SAN、Amazon Elastic Block Store (EBS), Google Cloud Persistent Disk など。

6.2.5 Object Storage

オブジェクトストレージは、任意のファイルタイプのイミュータブルなオブジェクトを格納できる。

ローカルディスク上のファイルと違って、オブジェクトをその場で変更することができない。

OLAPシステムのような、更新頻度が低く大規模なバッチ読み込みと書き出しに優れた性能を発揮する。

小さい変更が毎秒起こるような場合には、トランザクショナルデータベースやブロックストレージのほうが優れている。

データレイクで用いられるストレージの標準。

キーバリューストアであり、オブジェクトを見つけるためにディレクトリツリーを利用しない。バケットに多くのオブジェクトが格納されている場合、 aws ls はコストがかかる。

オブジェクトストレージに強い一貫性 (Strong consistency) をもたせるには、強い一貫性を持つデータベースを併用する、もしくは、バージョンメタデータを利用する。

オブジェクトのバージョン管理では、ストレージのコストのオーバーヘッドを考慮しなければならない。

データのアクセス頻度や可用性に応じてストレージクラスやティアを選択する。

6.2.6 Cache and Memory-Based Storage Systems

RAMベースのストレージシステムは、キャッシュ用途で超低レイテンシでデータを提供するのに有用。

Memcached、Redisなど。

6.2.7 The Hadoop Distributed File System

Hadoopはオブジェクトストレージと違って、コンピュートとストレージを同じノードで行う。

6.2.8 Streaming Storage

分散型でスケーラブルなストリーミングフレームワークでは、非常に長時間のデータの保持が可能になっている。

Apache Kafka, Amazon Kinesis, Apache pulsar, Google Cloud Pub/Sub

リプレイは、ストリーミングシステムが過去に保存したデータの指定した範囲を返すことを可能にする。

6.2.9 Indexes, Partitioning, and Clustering

インデックスsからパーティション分割とクラスタリングへ。

6.3 Data Engineering Storage Abstractions

データ中小は、データストレージシステムの上に構築される、データんジニアライフサイクルの中心に位置するデータ構成法とクエリのパターン。

6.3.1 The Data Warehouse / 6.3.2 The Data Lake / 6.3.3 The Data Lakehouse

データウェアハウスは、企業が異なるソースからデータを収集し、統合、格納、分析するための中央のデータリポジトリ。

データレイクは、企業内外のさまざまなデータソースから取り込まれた構造化データ、半構造化データ、非構造化データを保存、統合するためのストレージプラットフォーム。

データレイクハウスは、データレイクとデータウェアハウスの両方の機能を組み合わせたプラットフォーム。堅牢なテーブルとスキーマのサポート、増分更新と削除を管理する機能、テーブルの履歴やロールバックをサポートする。様々なツールがメタデータレイヤに接続し、オブジェクトストレージから直接データを読み込むことができる。

6.3.4 Data Platforms

ベンダがデータストレージのコア部分に統合された相互運用可能なツールのエコシステムをデータプラットフォームと呼ぶケースが増えている。

6.3.5 Stream-to-Batch Storage Architecture

Stream-to-Batch Storage Architectureは、ストリーミングデータをリアルタイムで処理し、バッチ処理によって永続的なストレージに保存するアーキテクチャ。Lambdaアーキテクチャと多くの類似点がある。

6.4 Big Ideas and Trends in Storage

6.4.1 Data Catalog

データカタログは、組織全体の全データを一元的に管理するメタデータストア。

データエンジニアは、データカタログと統合するデータパイプラインやストレージシステムのさまざまなデータ統合のセットアップと保守、およびデータカタログ自体の一貫性を担当することになる。

6.4.2 Data Sharing

データ共有は、組織や個人が特定のデータを共有し、特定の対象に対してアクセス許可を与えることを可能にする。

各組織は、流出を防ぐために誰と誰がデータを共有できるかを規定するポリシーを管理する。

6.4.3 Schema

書き出し時スキーマ (Schema on write) と読み込み時スキーマ (Schema on read) がある。

Schema on write はデータ標準を矯正することで、将来的にデータを利用しやすくする。

Schema on read は、柔軟性が重視され、どんなデータでも書き出すことができるが、将来データを消費することが難しくなる。

6.4.4 Separation of Compute from Storage

コンピュートとストレージを分離する理由は、短命性 (ephemerality) とスケーラビリティ、データの耐久性と可用性にある。

6.4.5 Data Storage Lifecycle and Data Retention

ホットデータ、ウォームデータ、コールドデータ。

ホットデータは、即時もしくは頻繁なアクセスが要求される。

ウォームデータは、月に1海など半定期的にアクセスが要求される。

コールドデータは、アクセス頻度の低いデータ。

データのストレージティアを検討する際には、各ティアのコストを考慮する必要がある。

クラウドベースのオブジェクトストレージを使っているのであれば、データのライフサイクルポリシーを自動化しよう。

データエンジニアはどのようなデータをどのくらいの期間保持すべきか。価値、時間、コンプライアンス、コストから考える。

6.4.6 Single-Tenant Versus Multitenant Storage

シングルテナントアーキテクチャとマルチテナントアーキテクチャ。

シングルテナントアーキテクチャでは、個々のテナントがそれぞれのデータベースを持つ。

マルチテナントアーキテクチャでは、複数のテナントが1つのデータベースを共有する。

6.5 Whom You’ll Work With

企業のデータ成熟度が低い場合、データエンジニアがストレージシステムとワークフローを管理することになる。

成熟度が高ければ、データエンジニアがストレージシステムの一部だけを管理することになり、データエンジニアは、ストレージの両側にいるエンジニアと交流することになる。

データエンジニアは、下流ユーザが使用するストレージシステムが安全に利用でき、高品質のデータが格納され、十分なストレージ用ろ湯があり、クエリや返還が実行されたときに実行されることを保証する必要がある。

6.6 Undercurrents

セキュリティ: 最小権限の原則。

Data Management: メタデータ管理はデータガバナンスを大幅に強化する。データカタログ、リネージだけでなく、データで何が起きているかを明確かつ能動的に把握できるようにしよう。データのバージョン管理をしよう。データ削除要求に対して、選択的に削除できるようにしておこう。匿名化とマスキングでプライバシーとセキュリティに対応しよう。

DataOps: FinOps、セキュリティ監視、アクセス監視、データの統計情報の監視をしよう。

Data Architecture: 上流のソースシステムを理解する、下流のデータモデルとクエリタイプを理解する。データ増加のスケールに備える。フルマネージドシステムに頼り、プロバイダのSLAを理解しよう。

オーケストレーション: オーケストレーションはストレージと密接に関わっている。

ソフトウェアエンジニアリング: 書いたコードはストレージシステム上でうまく動作しなければならない。ストレージインフラストラクチャをコードとして定義し、データ処理には短命な計算資源を使うようにしよう。