5. Data Generation In Source Systems

一般的なソースシステムの運用パターンと主要なソースシステムの種類について。

システムが生成するデータと、ソースシステムで作業祭に考慮すべき点。

底流がどのように適用されるか。

5.1 Sources of Data: How Is Data Created?

データがどのように生成されるかを熟知しよう。ソースシステムのドキュメントを読み、そのパターンや癖を理解することに努めよう。

5.2 Source Systems: Main Ideas

ソースシステムの主要な概念

• ファイルと非構造化データ
• API
• アプリケーションデータベース (OLTP)
• オンラインアナリティクス処理システム (OLAP)
• 変更データキャプチャ (CDC)
• ログ
• データベースログ
• CRUD
• インサートオンリーパターン
• メッセージとストリーム
• 時間と時刻の種類

5.2.1 Files and Unstructured Data

遭遇することの多いソースファイルフォーマットは、Excel, CSV, TXT, JSON, XML など。

これらのファイルフォーマットは、構造化されたもの (Excel, CSV)、半構造化されたもの (JSON, XML, CSV)、構造化されていないもの (TXT) がある。

構造化されたファイルフォーマット (Excel)

| Name   | Age | Gender |
|--------|-----|--------|
| Alice  | 25  | Female |
| Bob    | 30  | Male   |
| Carol  | 28  | Female |

半構造化されたファイルフォーマット (JSON)

[
  {"Name": "Alice", "Age": 25, "Gender": "Female"},
  {"Name": "Bob", "Age": 30, "Gender": "Male"},
  {"Name": "Carol", "Age": 28, "Gender": "Female"}
]

構造化されていないファイルフォーマット (TXT)

Alice,25,Female
Bob,30,Male
Carol,28,Female

5.2.2 APIs

理論的には、APIはデータ取り込み作業を単純化するはずだが、実際には、APIが公開しているデータは複雑で、エンジニアは個別に対処しなければならない。

5.2.3 Application Databases (OLTP Systems)

アプリケーションデータベースは、オンライントランザクション処理 (OLTP) システムであり、複数のユーザが同時にアプリケーションとやり取りして同時にデータ更新をする。低レイテンシと高並列性をサポートする。

例えば、銀行口座の残高を保存するデータベースなど。

1つのクエリが膨大な量のデータをスキャンするような、大規模な分析には向かない。

5.2.4 Online Analytical Processing System

OLAPシステムは、大規模なアナリティクスクエリを実行するために構築される。ここのレコードに対するルックアップの効率は高くない。

OLAPは一般的にアナリティクスに用いられるストレージおよびっクエリシステムだが、ユースケースによってはOLAPからデータを読み込む必要も出てくる。例えば、データウェアハウスがMLモデルの訓練データを提供する場合、リバースETLなど。

5.2.5 Change Data Capture

CDCは、データベースで発生した変更イベントを抽出する手法。

データ同期やレプリケーション、データウェアハウスの更新、データ監査と履歴管理、ストリーミング分析とリアルタイムデータ処理、などに用いられる。

CDCツールがデータベースのバイナリログを監視し、変更データをリアルタイムでキャプチャしてKafkaに送信、のような処理になる。

5.2.6 Logs

ログのソースとして、OS、アプリケーション、サーバ、コンテナ、ネットワーク、IoTデバイスなどがある。

ログには、最低でも「誰が」「何を」「いつ」起こしたかを記録しなければならない。

5.2.7 Database Logs

WAL (Write Ahead Log) はデータベースのトランザクションログを記録する手法であり、データベースの耐久性とクラッシュリカバリを向上されるのに役立つ。

トランザクションを開始してWALに記録 → データベースへの変更とWALへの記録 → トランザクションのコミット、の流れ。

5.2.8 CRUD

Create, Read, Update, Delete

5.2.9 Insert-Only

インサートオンリーパターンは、レコードを更新せずに、テーブルに直接履歴を書き出す。

クライアントの住所が変更された場合、CRUDパターンではレコードを更新するが、インサートオンリーパターンでは同じクライアントのIDで新しい住所レコードを挿入する。読み取るときはそのIDの最新のレコードをルックアップする。

利点は、アプリケーションが履歴にアクセスする必要がある場合に便利、書き込みスループットが高い。

欠点は、テーブルサイズが大きくなる、レコードのルックアップに余分なオーバーヘッドが発生する。

5.2.10 Messages and Streams

メッセージは、2つ以上のシステム間で通信される生のデータ。メッセージが受信されアクションが実行されると、メッセージはメッセージキューから削除される。

ストリームは、イベントレコードの追記のみのログ。多くのイベントにわたって起きたことを知りたい場合に使われる。ストリームを処理するシステムはメッセージを処理することができる。

5.2.11 Types of Time

イベント時刻 (Event time) は、イベントがソースシステムで生成された時刻。

取り込み時刻 (Ingestion time) は、イベントがソースシステムから後続に取り込まれた時刻。

処理時刻 (Processing time) は、取り込まれたあとにデータが処理 (変換など) された時刻。

5.3 Source System Practical Details

5.3.1 Databases

データベーステクノロジの理解に役立つ観点

• データベース管理システム (DBMS)
• ルックアップ
• クエリオプティマイザ
• スケーリング、分散
• モデリングパターン
• CRUD
• 一貫性

データベースは、リレーショナルデータベース (RDBMS) と非リレーショナルデータベース (NoSQL) に分類される。

NoSQL

• キーバリューストア
• ドキュメントストア
• ワイドカラムデータベース
• グラフデータベース
• 検索データベース
• 時系列データベース

キーバリューストア

各レコードを一意に識別するキーを使ってレコードを検索する非リレーショナルデータベース。

キーに対応する値を高速に検索・取得することができる。

Redis, Memcached。

キャッシュ、セッションストア、メッセージキューなどで利用される。

ドキュメントストア

JSONやBSONなどの形式でデータを保存するデータベース。

ドキュメントはネストされたオブジェクトで、キーと値のペアの集合で構成される。

コレクションはリレーショナルデータベースのテーブルに対応する。

柔軟なスキーマ設計ができる。その分、時間経過でデータの一貫性に問題が出てくる可能性がある。

ジョインをサポートしておらず、データを簡単に正規化できない。

アナリティクスのためにはフルスキャンが必要になる。

MongoDBなど。

Webアプリケーション、コンテンツ管理システム、ログ管理などで利用される。

ワイドカラムデータベース

行ごとに異なる列を持つことができるデータベース。

大量のデータを高いトランザクションレートと極めて低いレイテンシで保存するために最適化されている。

柔軟なスキーマ設計ができる。

Apache Cassandra, HBaseなど。

時系列データの保存、分散データの処理などで利用される。

グラフデータベース

データをノードとエッジの集合となるグラフ構造で保存するデータベース。

要素感の複雑なトラバースを理解するのが得意。

Neo4j, ArangoDBなど。

ソーシャルネットワーク解析、推薦システムなどで利用される。

検索データベース

データから意味的・構造的特徴を検索するために使用されるデータベース。

テキスト検索とログ検索に利用される。

Elasticsearch, Apache Solrなど。

ウェブ検索エンジン、ログ解析などの用途に利用される。

時系列データベース

時系列データの検索と統計処理に最適化されたデータベース。

InfluxDB, Apache Druidなど。

センサーデータのモニタリング、アプリケーションのパフォーマンスモニタリング、IoTデータの収集などに使われる。

5.3.2 APIs

• REST
• GraphQL
• Webhook
• RPC, gRPC

GraphQL

アプリケーションデータのクエリ言語として、REST APIに変わるものとして設計されており、RESTよりも柔軟なクエリが可能になる。

エンドポイントは、RESTはリソースごとに固定されたエンドポイントに対して、GraphQLでは1つのエンドポイントがすべてのリクエストを処理する。以下の例だと /graphql でユーザ情報を取得している。

クライアントが必要なデータをリクエストボディのクエリで指定する。以下の例だと query フィールドにGraphQLクエリを記述している。

1つのリクエストで複数のデータモデルを取得できる。

REST HTTPリクエスト

GET /api/users/123 HTTP/1.1
Host: example.com

REST HTTPレスポンス

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "name": "John Doe",
  "email": "john@example.com",
  "age": 30
}

GraphQLクエリ

POST /graphql HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "query": "query GetUser($id: ID!) { user(id: $id) { id name email age } }",
  "variables": { "id": "123" }
}

GraphQLレスポンス

HTTP/1.1 200 OK
Content-Type: application/json

{
  "data": {
    "user": {
      "id": "123",
      "name": "John Doe",
      "email": "john@example.com",
      "age": 30
    }
  }
}

Webhook

ソースシステムで指定されたイベントが発生すると、データ消費者がホストするHTTPエンドポイントへの呼び出しがトリガーされる。

HTTP POSTリクエストでイベントデータを送信する。

RPC (Remote Procedure Call) / gRPC

RPCは、ネットワーク上でプロシージャの呼び出しを行うためのプロトコル。

gRPCは、Protocol Buffers をシリアライズを利用して HTTP/2 プロトコルをベースにバイナリ形式のgRPCメッセージでデータのやり取りをするプロトコル。

gRPCリクエスト

POST /UserService/GetUser HTTP/1.1
Host: example.com
Content-Type: application/grpc

[Binary gRPC request payload]

gRPCレスポンス

HTTP/1.1 200 OK
Content-Type: application/grpc

[Binary gRPC response payload]

5.3.3 Data Sharing

マルチテナントシステムでデータ共有をするためのアクセス権限のセキュリティポリシーをサポート。

デー組織の各ユニットがそれぞれデータを管理し、それを他のユニットと共有することができるようになる。

5.3.4 Third-Party Data Sources

自社データを顧客やユーザに提供したいと考えるようになった。

サードパーティへのデータのアクセスは、API、クラウドプラットフォーム上でのデータ共有、データのダウンロードを通じて行われる。

5.3.5 Message Queues and Event-Streaming Platforms

イベント駆動アーキテクチャにおいて重要なレイヤであるメッセージキューとイベントストリーミングパイプライン。これらはソースシステムとして数多くの方法で利用されている。

メッセージキューは、Pub/Subモデルでシステム間で非同期にデータを送信する仕組み。メッセージキューで留意すべき点は、メッセージの順序、配送頻度、スケーラビリティ。

イベントストリーミングプラットフォームは、記録されたログのデータを順番に取り込んで処理するために使用される。重要な特徴は、トピック、パーティション、耐障害性。

5.4 Whom You’ll Work With

利害関係者とコミュニケーションをとることが重要。

利害関係者医は、システム利害関係者とデータ利害関係者がある。

システム利害関係者は、ソースシステムを構築し維持管理する人。ソフトウェアエンジニア、アプリケーション開発者、サードパーティ。

データ利害関係者は、必要なデータへのアクセスを所有し管理する人。IT部門、データガバナンスグループ、サードパーティ。

ソースシステム所有者とのデータコントラクト、SLA確立を師ておくことが重要。

5.5 Undercurrents and Their Impact on Source Systems

セキュリティ: 非常に重要。暗号化、、認証情報の管理、ソースシステムが信頼できるか。

Data Management: 考慮すべき点は、データガバナンス、データ品質、スキーマ、マスターデータ管理、プライバシーと倫理、規定。

DataOps: データエンジニアリングチームとソースシステムをサポートするチームとの間に、明確なコミュニケーションチェーンを構築しよう。考慮すべき点は、自動化、可観測性、インシデント対応。

Data Architecture: 上流のアーキテクチャがどのように設計されているか、その長所と短所を理解しておく必要がある。考慮すべき点は、信頼性、耐久性、可用性、人材。

オーケストレーション: オーケストレーションがソースシステムにアクセスできることを確認しよう。考慮すべき点は、ケーデンスと頻度、共有フレームワーク。

ソフトウェアエンジニアリング: データエンジニアがソースシステムにアクセスするコードを書く必要がある。考慮すべき点は、ネットワーク、認証認可、アクセスパターン、オーケストレーション、並列化、デプロイ。