Bigtable 用 Key Visualizer ツールは、クラスタ内の各テーブルを毎日スキャンし、その使用パターンを表示する
- ホットスポットになっている行や CPU の過剰使用を確認できる
読み取り、書き込みがテーブル全体に均等に分散されているときに最高のパフォーマンスになる
- 特定の行に読み取りと書き込みが集中している場合、スキーマを再設計する

Bigtable インスタンスを作成した後にストレージを変更したい

インスタンスを作成した後は、SSD/HDDストレージの変更は不可
既存のインスタンスからデータをエクスポートし、そのデータを新しいインスタンス（希望するストレージ）にインポートするしかない

行キーのベストプラクティス

「タイムスタンプのみ」は推奨していない
sensorId + timeStampという行キーを推奨

バッチ分析ワークロードを他のアプリケーションから分離する

単一のクラスタ上で、多数の大規模読み取りを実行するバッチ分析ジョブを、読み取りや書き込みを実行するアプリケーションと並行して実行すると、アプリケーションの処理が遅くなる可能性がある
アプリプロファイルにより、リクエストを異なるクラスタにルーティングする

BigQuery

バックアップ

破損の検出が 7 日以内の場合、過去の時点のテーブルに対してクエリを行い、スナップショットデコレータを利用して、破損する前のテーブルを復元します。
BigQuery からデータをエクスポートし、エクスポートしたデータを含む（ただし破損したデータは含まない）新しいテーブルを作成します。
特定の期間ごとに、データを異なるテーブルに格納します。この方法では、データセット全体ではなく、データの一部のみを新しいテーブルに復元するだけで済みます。
例えば、データを月ごとに別々のテーブルに整理し、データをエクスポートして圧縮し、Cloud Storageに保存する。これにより、データセット丸ごと復元する必要がない。
特定の期間にデータセットのコピーを作成します。データ破損のイベントが、ポイントインタイムクエリでキャプチャできる期間（7 日以上前など）を超えた場合に、そのコピーを使用できます。また、データセットをあるリージョンから別のリージョンへコピーして、リージョンのエラーの際にデータの可用性を確保することもできます。
元のデータを Cloud Storage に保存します。これにより、新しいテーブルを作成して、破損していないデータを再読み込みできます。そこから、新しいテーブルを指すようにアプリケーションを調整できます。

パフォーマンス

クエリ実行はストリーミングインサートの後、レイテンシーを考慮してそれよりも長い時間待った後に行う必要があります。ストリーミングインサート後のデータ可用性の平均レイテンシーを推定し、常に2倍の時間を待ってからクエリを実行する
パーティショニング・クラスタ化により、WHERE句を用いたクエリのパフォーマンスを向上させることができる
大量のデータを日々更新する場合は、BigQuery UPDATEよりもAPPENDの方がパフォーマンスに優れています

BigQueryのレガシーSQL

非正規化

非正規化により、クエリの速度が向上し、クエリがシンプルになる

リージョン/マルチリージョン

BigQuery は次の 2 種類のロケーションを使用します。

リージョンは、ロンドンなどの特定の地理的な場所となります。
マルチリージョンは、米国などの、2 つ以上の地理的な場所を含む広い地理的なエリアとなります。

CSV読み込み時の注意

CSV ファイルを BigQuery に読み込む場合は、次の点に注意してください。

CSV ファイルはネストされたデータや繰り返しデータに対応していません。
バイトオーダーマーク（BOM）文字を削除する。予期しない問題が発生する可能性があります。
gzip 圧縮を使用した場合、BigQuery はデータを並列で読み取ることができません。圧縮された CSV データを BigQuery に読み込む場合は、圧縮されていないデータを読み込むよりも時間がかかります。圧縮データと非圧縮データを読み込むをご覧ください。
同じ読み込みジョブに圧縮ファイルと非圧縮ファイルの両方を含めることはできません。
gzip ファイルの最大サイズは 4 GB です。
JSON または CSV データを読み込む場合、TIMESTAMP 列のタイムスタンプ値の日付部分の区切りにはダッシュ（-）を使用し、日付は YYYY-MM-DD（年-月-日）の形式にする必要があります。タイムスタンプの時間部分 hh:mm:ss（時-分-秒）には、区切りとしてコロン（:）を使用する。

クォータを超過することなく大規模なレコードの更新する

https://cloud.google.com/blog/products/bigquery/performing-large-scale-mutations-in-bigquery

クォータとは、クラウドプロジェクトが使用できる特定の共有 Google Cloud リソースの量を制限するもので、ハードウェア、ソフトウェア、ネットワークコンポーネントなどが含まれます。
今回のケースでは、UPDATE文によってこの問題が発生しているため、その他の方法を用いてこの上限に到達しないようにデータをインポートする必要があります。
Google Cloudが推奨するBigQueryへのインポートの方法は、次のBigQueryのMERGEステートメントを使用して、別のテーブル（新着情報が保管されている）の内容に基づいて既存テーブルのバッチ更新を実行する方法です。

MERGE dataset.Inventory T
USING dataset.NewArrivals S
ON T.ProductID = S.ProductID
WHEN MATCHED THEN
  UPDATE SET quantity = T.quantity + S.quantity -- 既にプロダクトが存在する場合は、在庫を追加
WHEN NOT MATCHED THEN
  INSERT (ProductID, quantity) VALUES (ProductID, quantity) -- プロダクトが存在しない場合は、新プロダクトを挿入

MERGE文の参考

メトリクス

slots/allocated_for_project
- プロジェクト内のクエリジョブに現在割り当てられているBigQueryスロットの数を確認することができます。

BigQuery Reservationsによる優先度付け

定額制(BigQuery Reservations)は、複数の事業部門があり、優先順位や予算が異なるワークロードを抱える大企業に特に適しています。
一定数のスロットがお客様のプロジェクトに割り当てられ、プロジェクト間で階層的な優先順位モデルを確立することができます

→　たぶん“予約”のことだと思われる。

Cloud Pub/Sub

Cloud Pub/Subのプッシュに対して、確認応答期限内にメッセージを確認しないと、Pub/Sub によってメッセージが再送信され、その結果重複するメッセージが送信される
- 確認応答メッセージオペレーション指標のresponse_codeラベルで、expiredとなっているのが確認応答期限切れのメッセージ

Cloud Spanner

セカンダリインデックス

Cloud Spanner により、テーブルの主キーごとに自動的にインデックスが作成されます。たとえば、Singersテーブルの主キーである SingerId は自動的にインデックスに登録されるため、操作は必要はありません。

Cloud Spannerは、他の列をセカンダリインデックスにすることもできます。

セカンダリインデックスは、ルックアップを使用することで得られるメリットに加えて、Cloud Spanner でより効率的にスキャンを実行し、全テーブルスキャンではなくインデックススキャンを行うこともできます。

セカンダリインデックスを列に追加すると、その列のデータをより効率的に検索できるようになります。

たとえば、特定の範囲の LastName 値に対して SingerId のセットをすばやく検索する必要がある場合は、Cloud Spanner でテーブル全体をスキャンしなくてもいいように、LastName にセカンダリインデックスを作成します。

CREATE INDEX SingersByLastName ON Singers(LastName)

https://cloud.google.com/spanner/docs/secondary-indexes

ホットスポットの回避
- 主キーを選択する上で重要な点は、ホットスポットを回避するという点
- 単調増加する値やエポックタイムなどは、ホットスポットを発生させる可能性があるため不適切
- キーのハッシュ値やUUIDなどのランダムな値を用いることがベストプラクティス

Cloud Storage

大量に細かいファイルがある場合のアップロード

複数のファイルをTARファイルにまとめる
または、gsutil -mで並行して複数のファイルをGCSに転送する
ただし、一部のファイルのダウンロードが失敗していても、gsutil ではどのファイルが正常にダウンロードされたかを追跡しない

Cloud SQL

HA構成

あるゾーンにCloud SQL インスタンスを作成し、同じリージョン内の別のゾーンにフェイルオーバーレプリカを作成する https://cloud.google.com/sql/docs/mysql/high-availability#normal

Compute Engine インスタンス

https://cloud.google.com/tpu/docs/tpus#when_to_use_tpus

CPU

最大限の柔軟性を必要とする迅速なプロトタイピング
トレーニングに時間がかからない単純なモデル
実際のバッチサイズが小さい小規模なモデル
C++ で記述されたカスタム TensorFlow 演算が多くを占めるモデル
ホストシステムの使用可能な I/O またはネットワーク帯域幅によって制限が課せられるモデル

GPU

ソースが存在しないモデルまたはソースを変更するのが煩雑すぎるモデル
CPU 上で少なくとも部分的に実行しなければならない多数のカスタム TensorFlow 演算を使用するモデル
Cloud TPU で利用できない TensorFlow 演算を使用するモデル（利用可能な TensorFlow 演算のリストをご覧ください）
実際のバッチサイズが大きい中～大規模なモデル

TPU

行列計算が多くを占めるモデル
メインのトレーニングループ内にカスタム TensorFlow 演算がないモデル
トレーニングに数週間または数か月かかるモデル
実際のバッチサイズが非常に大きい非常に大規模なモデル

DataProc

MySQLのダンプファイルをCloud Storageに保存することで、Cloud SQL にマウントしてDataprocにインポートをすることが可能（たぶん、Dataproc内のCloud SQLにマウントするという意味だと思われる💦）
HDFSではなくGCSに保存しておくと、クラスタを削除した後もデータが維持される
永続ディスクとして、HDFSの代わりにGCSを使用するのがコスト最適
永続ストレージとして、ソリッドステートドライブ（SSD）とハードディスクドライブ（HDD）のどちらにするかを指定します。SSD ストレージは、ほとんどのユースケースで最も効率的でコスト効果の高い選択肢です。HDD ストレージは、非常に大きいデータセット（10 TB 超）で、レイテンシがあまり重要でない場合やアクセス頻度が低い場合に適切であることがあります。
Dataprocの起動時に初期化アクションが行われ、依存関係が追加される。セキュリティポリシー上、インターネットにアクセスできない場合には、GitHub リポジトリやCloud Storage に依存関係をコピーしておく
SparkジョブでParquetファイルを使用する場合、ファイルサイズの目安は1GBと言われています。Parquetサイズが200~400MBだと小さいです。最小1GBになるようにします。

Dialogflow

Dialogflowは会話型アプリが音声コマンドや音声会話に応答することを可能にします。
音声認識と自然言語理解を組み合わせ、1つのAPIコールで利用できます。

Datastore

結果が「すべて成功」と「何も起こらない」のどちらかになるオペレーションが実行できる
Datastore は、大規模な構造化データに対して可用性の高いアクセスを必要とするアプリケーションに最適です。Datastore は、次のようなタイプのすべてのデータを保存、クエリする目的で使用できます。
- 小売店向けにリアルタイムな在庫と商品の詳細を提供する商品カタログ
- ユーザーの過去の行動と好みに応じてカスタマイズされたエクスペリエンスを提供するユーザープロフィール
- ある銀行口座から別の口座への送金など、ACID プロパティに基づくトランザクション
  
   https://cloud.google.com/datastore/docs/concepts/overview#what_its_good_for

Data Loss Prevention API (DLP)

ユースケース：
Pub/Subトピックを読み取ってCloud Data Loss Prevention APIに渡すようCloud Functionを構築する。DLPによるタグ付けと信頼度を使用して、Cloud Functionがバケットにデータを渡すか、隔離するかを判定する。

Dataflow

Apache Beam

サイドインプット
- Apache Beamでは、データ分析のためのエンリッチメントを行う際には、サイドインプットパターンが推奨されています。https://beam.apache.org/documentation/patterns/side-inputs/
  Apache Beam入門
ParDo
- Apache Beam SDK のコア並列処理オペレーション
- 入力 PCollection の各要素に対してユーザー指定の関数を呼び出す
- ParDoトランスフォームで要素を個別に、場合によっては並行して処理します

監視

ユースケース：
Cloud Pub/SubからDataflowでCloud Storageに集約する場合に以下のメトリクスを監視する

送信元のSubscription/num_undelivered_messagesの増加
送信先の使用済みストレージのの増加率の減少

ウィンドウ

タイムスタンプに従って、Pcollectionを分割することをウィンドウ化と呼ぶ。GroupByKeyといった複数のエレメントを集約する変換は暗黙的にウィンドウベースで行われる。
ストリーミングデータのように新しいエレメントが定常的に追加され続けるデータセット、つまりUnbounded PCollectionの場合に、ウィンドウは役立つ。
Apache Beamのデフォルトでは、PCollectionの全エレメントに対して１つのウィンドウのみが割り当てられる。これをグローバルウィンドウと呼ぶ。たとえ、ストリーミングデータの場合でも、グローバルウィンドウは後から入ってきたデータを無視する。ストリーミングデータのようにUnbounded PCollectionの場合には、非グローバルウィンドウ関数を設定する必要がある。もし、非グローバルウィンドウ関数の設定なしでUnbounded PCollectionにGroupByKeyを適用する場合、IllegalStateExceptionエラーを出す。
たとえば、5分間ウィンドウ（または30秒ごとの4分間スライディングウィンドウ）をPCollectionのすべてのエレメントに適用していく。これが非グローバルウィンドウ。
https://beam.apache.org/documentation/programming-guide/#windowing

ウィンドウの種類

タンブリングウィンドウ（Apache Beam では固定ウィンドウ）
ホッピングウィンドウ（Apache Beam ではスライディングウィンドウ）
セッションウィンドウ
- セッションウィンドウは時間だけでなく、KEY単位でトラッキングしたい場合です。配信間隔が不規則なデータに対して役立ちます。セッションウィンドウは最小ギャップ時間を設定することができ、最小ギャップ時間以降に到着したウィンドウは別ウィンドウとして処理されます。
- 「時間」単位で処理していたのに対し、「KEY」単位で処理を行うことができます。活用用途としてはユーザの行動に基づくアクションを集計したい場合などです
- 例1 ：WEBページごとのアクセス数を各ユーザーごと集計したい場合
- 例2 ：WEBサイトで1時間に渡ってユーザーのインタラクションがない際に対象のユーザにPUSH通知を出したい場合
https://www.case-k.jp/entry/2019/11/08/173450#%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%A6%E3%82%A3%E3%83%B3%E3%83%89%E3%82%A6

パイプラインの更新

Dataflowジョブは２つの方法で停止することができる。ストリーミングパイプラインの停止時にデータの消失を防ぐには、ジョブのドレインが最適な方法。

キャンセル
ストリーミングパイプラインとバッチパイプラインの両方に適用可能。
ジョブをキャンセルすると、Dataflow サービスはバッファデータなどのデータの処理を停止。
ドレイン
ストリーミングパイプラインにのみ適用可能。
ジョブをドレインすると、Dataflow サービスはバッファ内のデータの処理を完了すると同時に、新しいデータの取り込みを中止できる
https://cloud.google.com/dataflow/docs/guides/stopping-a-pipeline#drain

GUIDによる重複排除

送信側で、各データエントリにGUIDを割り当てる
受信側で、既知のGUIDだった場合には受信したエントリを破棄する
これにより、複数回同じレコードが送信されたとしても重複排除できる

InsertIDによる重複排除

参考

挿入された行に対して insertId を指定した場合、BigQuery はこの ID を使用して、ベストエフォート型の重複排除を最大 1 分間サポートします。つまり、その期間内に同じ insertId の同じ行を同じテーブルに複数回ストリーミングしようとすると、BigQuery はその行の複数のオカレンスを重複排除して、それらのオカレンスの一つだけを保持する可能性があります。

このシステムでは、同じ insertId が指定された行も同一のものであると想定されます。2 つの行が同じ insertId を持つ場合、どちらの行を BigQuery が保持するかは非決定的になります。

ストリーミングの実行後に重複行が残らないようにするには、次の手動プロセスを使用する。

テーブルスキーマ内の列としてinsertId を追加し、各行のデータに insertId 値を含める
ストリーミングが停止した後に、クエリを実行して重複をチェックする

#standardSQL
SELECT * EXCEPT(row_number)
FROM (
  SELECT
  *,
  ROW_NUMBER() OVER (PARTITION BY ID_COLUMN) row_number
  FROM `TABLE_NAME`
)
WHERE row_number = 1

SQL解説
- ROW_NUMBER() OVER (PARTITION BY ID_COLUMN) row_number
同じInsertIdをもつレコードのグループ（パーティション）に対して、行ごとに連番を振っている。参考 - 同じID_COLUMN値を持つパーティション内で、行番号が1のものを取り出す。これで重複が削除された - SELECT * EXCEPT(row_number)
最後にrow_number列を宛先テーブルから除外する。

例外処理

Dataflowでは、パイプラインコードのDoFnに try … catchブロックを追加することで例外をキャッチできる
例外がキャッチされた際は、詳細なエラー分析が必要になるため、sideOutputを用いてPCollectionを作成することが有効。PCollectionに保存した後は、Pub/Subに改めて保存することも可能なため、失敗データの再処理できる
失敗した要素を追跡することもできる
- 失敗した要素をログに記録し、Cloud Logging を使用して出力をチェックできます
- ログの表示の手順に沿って、Dataflow ワーカーログとワーカー起動ログで警告やエラーを確認できます
- 失敗した要素を ParDo で追加出力に書き込み、後で調査できます

コード例

BigQueryIO.read.from()は、BigQueryからテーブル全体を直接読み取ります。
BigQueryIO.read.fromQuery() は、クエリを実行し、クエリ実行後に受け取った結果を読み込みます。

間違ったフォーマットや破損している行の処理

Google Cloudが推奨するより良い方法としては、デッドレターキュー（またはデッドレターファイル）と呼ばれるパターンを使用することです。

DoFn.ProcessElement メソッドで例外をキャッチして、エラーを通常どおりにロギングする。

ただし、失敗した要素をドロップする代わりに、分岐出力を使用して、失敗した要素を個別の PCollection オブジェクトに書き込みます。

その後、これらの要素はデータシンクに書き込まれ、別の変換を使用して、後で検査や処理を行うことができます。

Kafka

Google Cloud上でKafkaクラスタを展開する際は、VM インスタンスの使用が最適。

Logging

ログフィルターを使用して、特定のBigQueryテーブルに関連するログのみをフィルタリングし、ログルーティングシンクをCloud Pub/Subに設定できる。これにより、INSERTにより特定のテーブルにデータが追加されたときに、通知を送信できる
ログルーティングについて
監査ログを有効にすると、セキュリティ、監査、コンプライアンスエンティティが Google Cloud のデータとシステムをモニタリングして、脆弱性や外部データの不正使用（ポリシー違反）の可能性を確認できる
データアクセスログの保護
- プロジェクトのCloud IAMオーナーロールを持つ担当者からデータアクセスログを保護する
- 新しく作成したプロジェクトにCloud Storageバケットを作成し、そこにエクスポートシンクする。プロジェクトへのアクセスを制限しておく。

Monitoring

VMインスタンスにMariaDBのSQLデータベースを導入した場合
- Cloud Monitoringでは、ネットワーク接続、ディスクID、レプリケーションの状態などのカスタムメトリクスはデフォルトで収集することができない
- その場合、OpenCensusを使ったカスタムメトリクスの収集が推奨される
  - 無料のオープンソースプロジェクト
  - メトリクスおよびトレースデータをさまざまな言語で収集するための、ベンダーに依存しないサポートを提供できます。
  - 収集したデータを、Cloud Monitoring を含むさまざまなバックエンドアプリケーションにエクスポートできます。

Natural Language API

エンティティ分析を使用し、ドキュメントに題名ラベルを付ける
センチメント分析により、ドキュメントに感情ラベルをつける

Video Intelligence API

LABEL_DETECTION 機能を使用して動画映像に表示されるエンティティを識別し、それらのエンティティにラベル（タグ）でアノテーションを付けることができます。
この機能は、物体、場所、活動、動物の種類、商品などを識別できます。
オブジェクトトラッキングとは異なり、ラベル検出ではフレーム全体（境界ボックスなし）にラベルを付けます。
たとえば、踏切を通過する列車の動画では、「train」、「transportation」、「railroad crossing」などのラベルが返されます。
各ラベルには時間セグメントがあり、エンティティが検出された時点を、動画の先頭からの時間オフセット（タイムスタンプ）として示す

機械学習

ファッション
- ECサイトでユーザーに衣服を推薦するためのモデルを構築しています。ユーザーのファッションの好みは時間とともに変化することがわかっているので、新しいデータが利用可能になったときにモデルにストリーミングするためのデータパイプラインを構築します。
- 定期的に再トレーニングを行う必要があります。このような場合、新しいデータを追加するだけでなく、以前学習に使用されていたデータも利用することが一般的に有効とされています。
サブサンプル
サブサンプリングとは主に不均衡データに対して用いられるデータ処理手法で、特定のクラスのデータから新しいサブセットを生成する処理です。これによって、特定のクラスのデータセットが減少し、学習パフォーマンスが向上する。

その他DB

数百TB規模のNoSQLデータベースだったらこいつら

HBase
MongoDB
Cassandra

HBase

Googleのビッグテーブルに似たNoSQLデータベース
膨大な量の構造化データへの迅速なランダムアクセスを実現するために設計された

MongoDB Atlas

Google のグローバルにスケーラブルで信頼性の高いインフラストラクチャ上で、フルマネージドサービスを提供
Atlas を使用すると、UI を数回クリックするか API 呼び出しを実行するだけでデータベースを簡単に管理できる
移行は簡単で、グローバルクラスタなどの高度な機能を備え、世界中のどこにいても低レイテンシの読み取りおよび書き込みアクセスが可能

Apache Cassandra

オープンソースのNoSQL分散型データベースで、パフォーマンスを損なうことなく拡張性と高可用性を実現できる
コモディティ・ハードウェアやクラウド・インフラ上で直線的なスケーラビリティと実証済みのフォールトトレランスを実現し、ミッションクリティカルなデータに最適なプラットフォーム

その他ツール

Pig / Pig Latin

Pigは大規模なデータセットを分析するためのプラットフォームです。

Hadoop上に構築されており、プログラミングの容易さ、最適化の機会、拡張性を提供する。

Pig Latinはリレーショナルデータフロー言語であり、Pigのコアなコンポーネントの1つです。

データパイプラインの構築の際には、いくつかの理由からSQLよりもPig Latinの方がより優れた選択になります。

Pig Latinでは、パイプラインの開発者が、パイプラインのどこにデータをチェックポイントするか決めることができます。
Pig Latinでは、オプティマイザに頼らず、特定の演算子の実装を直接選択することができます。
Pig Latinはパイプラインの分割をサポートする。
Pig Latinでは、開発者がデータパイプラインのほとんどどこにでも独自のコードを挿入することができます。

DB一般

自己結合ｓ

自己結合とは同じテーブル同士の結合のことをいいます。結合は 2つ以上のテーブルに対して行われますが、それらが別のテーブルである必要はありません。自己結合は 2つのまったく同じテーブルの結合として実行されます。

DBサービス

常に生成されて書き込まれる時系列データ　→　Cloud Bigtable

PDEワークショップ

Dataproc 分析とデータ処理でDataprocクラスタを個別に作成するのがベストプラクティスエフェメラルクラスタを作成することで、ジョブ終了時に削除 GCSへの接続はGCSコネクタを利用する

Bigtable ワイドカラムNo SQL（ワイドカラムストア型：キーバリュー型のバリュー部分が、さらに任意の数のキーバリューの集合（列名と値）になったような構造） HBase互換性 Bigtable cbtツールで外れ値を見つける IoTの時系列データが得意

DataprocとBigQueryの連携 BigQuerコネクタを使用することで読み書きアクセス可能

CloudSpanner トラヒックの急増→ストレージ使用量ではなく、CPUリソースが枯渇するので、CPU使用率をモニタリングする手動スケール：コンソール上で設定自動スケール：コーディングが必要

Cloud SQLは水平方向にスケールしない

GCPだとDBのことをストレージと呼んだりする。

Cloud Spannerではデフォルトだとプライマリキー以外で検索すると、全件検索するため時間がかかる検索したいカラムに対して、セカンダリインデックスを作成し、索引を作ることで検索を早くすることができる。 Dataproc 分析とデータ処理でDataprocクラスタを個別に作成するのがベストプラクティスエフェメラルクラスタを作成することで、ジョブ終了時に削除 GCSへの接続はGCSコネクタを利用する

DataprocとBigQueryの連携 BigQuerコネクタを使用することで読み書きアクセス可能

CloudSpanner

スケールアップではなく、スケールアウトできる
トラヒックの急増→ストレージ使用量ではなく、CPUリソースが枯渇するので、CPU使用率をモニタリングする

手動スケールアウト：コンソール上で設定
自動スケールアウト：コーディングが必要

Cloud SQL

Cloud SQLは水平方向にスケールしないあくまで縦方向のスケールのみ（スケールアップのみ）スケールアップ時にはサービスが停止する

GCPにおける「ストレージ」という呼称

GCPだとDBのことをストレージと呼んだりする。

Cloud Spannerのセカンダリインデックス

Cloud Spannerではデフォルトだとプライマリキー以外で検索すると、全件検索するため時間がかかる検索したいカラムに対して、セカンダリインデックスを作成し、索引を作ることで検索を早くすることができる。

Bigtableにおける行キーの設計

BigQueryのワイルドカードテーブル

テーブル名にワイルドカードを使用する（テーブル名プレフィックス+アスタリスク）ことで、複数のテーブルに対してクエリを実行できる

<project名>.<Dataset名>.<テーブル名プレフィックス>*

2022-08-20

読書メモ〜Google Cloudではじめるデータエンジニアリング入門

GCP データエンジニア

概要

「Google Cloudではじめるデータエンジニアリング入門」を読んだので、忘備としてメモしておく。
8章~11章のBigQueryへのデータ集約、BI、リアルタイム分析、発展的な分析はスキップする。
メモの順番は章立てと一致してない。なるべくサービス毎にメモを記述した。

BigQuery

BigQueryの内部構造

コンピュート、ストレージ、さらにメモリがそれぞれ独立してスケーリングできる。

コンポーネント

マスタ/スケジューラ
ワーカ：コンテナで動作する分散コンピュート環境。クエリが終了すると瞬時に破棄
ネットワーク：Jupiterと呼ばれる独自のデータセンター内部NW。1.3Gpbsの帯域
分散ストレージ：複数のゾーンにまたがる。Capacitorファイルというカラム志向のファイルフォーマットにデータを圧縮して格納。複数のCapacitorファイルを束ねて、テーブルとして表示
分散インメモリシャッフル：分散処理ではシャッフルと呼ばれるワーカ間のデータ移動処理が発生。オーバヘッドがでかい。分散インメモリシャッフルをワーカではなく、分散インメモリ上で行うことで効率化。

BigQueryサンドボックス

Google Cloudの無料枠とは別。クレカ登録不要。

クエリの応用機能

以下の応用機能がある。

クエリの保存と共有ができる。
クエリのスケジューリングができる。
ユーザ定義関数が利用できる（SQLまたはJavaScriptで定義し、SQLから利用可能）
ストアドプロシージャが利用できる（UDFとは異なり、独立したステートメントとして実行される）
クエリプランの可視化により、パフォーマンスチューニングができる（詳細は公式ドキュメントを確認のこと。BQ Visualizeといったツールもある）

クエリの最適化

クエリ最適化のポイントは以下の通り。

SELECT等で、必要なカラムのみ選択する
パーティション分割/クラスタ化（詳細は後述）
クエリのキャッシュ：24時間保管され、同じクエリが実行されるとキャッシュが返される（スキャン料金の対象にはならない）。キャッシュ自体もテーブルとしてアクセスできる。CREATE TEMP TABLE…により、明示的にキャッシュ（一時テーブル）を作成可能

BigQueryにおけるパーティション分割

パーティションを設定しないとカラムをフルスキャンしてしまう。パーティションにより効率的なスキャンができる。
さらにパーティション毎にデータの有効期限を設定可能。一定期間が過ぎたパーティションを自動的に削除することができる。

パーティションの分割方法

カラムの値によるパーティション分割。ただし、時間（年、月、日付、時間）と整数値のみパーティション分割に利用可能
データの取り込み時間による分割（あまり使われない）

BigQueryにおけるクラスタ化

パーティションの場合1つのカラムしか指定できないが、クラスタ化では複数のカラムを指定して分割できる。例えば、日付と製品IDの両方で1つのグループとすることができる。これにより、さらにスキャン量を減らし、高速に結果を返すことができる。
ただし、BigQuery上でのスキャン量はパーティション分割と同じように見えてしまう（実際はパーティション分割より、スキャン量が小さい）

BigQueryのコストコントロール

以下の方法でコストをコントロールできる。

BigQueryカスタムコスト管理
- プロジェクト、あるいはユーザ単位で1日あたりの最大値を設定
Cloud Billingの予算・予算アラート

BigQuery Reservationsによるパフォーマンス担保

BigQuery Reservationsでは、スキャン量による従量課金ではなく、占有するコンピュートリソースに対して課金することができる。
ワーカ上のコンピュートユニットをスロットと呼ぶ。BigQuery Reservationsでは、コミットメントという単位でスロットを購入する。秒、月、年という単位で購入できる。契約期間が長いほど、割引率は高い。
クエリプランで1秒間で4,000スロットを処理したいとなっても、2,000スロット/秒しか利用可能なリソースがない場合には、2秒かけて処理することになる。
並列で複数のクエリが実行された場合には、フェアスケジューリングによって、クエリ間でスロットを均等に割り当てることで同時に処理する。これにより、クエリが長時間待機状態になることを防ぐ。
予約は、スロットを名前を付けてまとめておく概念。予約しておくことで他で勝手に使われないようスロットを確保しておくことができる。
割り当てプロジェクトは予約に紐づくプロジェクトのこと。割り当てプロジェクト内でフェアスケジューリングが働く。
予約により、使われていないスロット（＝アイドルスロット）がある場合、他の予約のスロットとして一時的に貸し出される（デフォルト動作）。アイドルスロットを貸し出したくない場合には、ignore_idle_slotsというオプションをtrueにする。

BigQuery Reservationsでのコストコントロール

以下の方法でコストをコントロールできる。

BigQuery Slot Recommenderを利用して、最適なスロット数を調べる。
BigQuery Slot Autoscalingで、予約したスロットを使い切った場合にスケーリングするよう設定する。これにより、スロットの事前購入量を必要最小限にしておくことができる。
「プロジェクトあたり同時実行クエリ数」を設定する。

マテリアライズドビュー

自動で更新されるビューのこと。デフォルトでは30分間隔で更新される。行の挿入は5分程度で反映される。
ただのビューとは違い、パフォーマンスの向上が見込める、らしい（仕組みはよくわからなかった。。。）

BigQueryの可用性

BigQueryの可用性SLAは99.99%。ストレージは、ゾーンをまたいでレプリケーションされているので、ゾーン障害でも大丈夫。

BigQueryのメンテナンス

BigQueryではメンテナンスによるダウンタイムは発生しない。ローリングアップデートしているため。
（パブリッククラウドのDBマネージドサービスでは、一般的にSLAからメンテナンスウィンドウは除かれるらしい）

Disaster Recovery

やり方としては以下の2通りがある。

BigQueryをコピー
- DRサイトにBigQueryを作成しておき、BigQuery Data Transferサービスにより、最短12時間毎にデータを定期コピーする。
Cloud Storageに保管しておき、災害時にBigQueryにロード
- ローカルサイトにCloud Storage（GCS）を作成し、BigQueryからエクスポートする。
- Cloud Storage Transferサービスにより、DRサイトのGCSに転送する。転送後ローカルサイトのGCSデータを削除する。
- 災害時にDRサイトのGCSからBigQueryにロードする。

BigQueryのバックアップ/リストア

タイムトラベル機能により、最大7日間まで任意のタイムスタンプの時間帯の状態に戻せる。
SELECT * FROM FOR SYSTEM TIME AS OF
タイムトラベル分のストレージコストは課金されない。
タイムトラベルを利用して、別テーブルに保管することでバックアップがとれる。

BigQueryにおけるトランザクションの仕組み

DML処理は全て成功する、またはコミットされずに全ての変更が戻されるのどちらか。
DMLの結果をテーブルにコミットする前に、変更が現在のテーブルに競合しないか確認する。競合があった場合にはDMLの実行を3回までリトライする。
DML処理の対象パーティションが異なる場合には、DML処理は競合しない。
同時に同じパーティションに対してDML処理が発行された場合、最初に完了したDML処理のみコミット（適用）される。
DML処理をなるべき大きなジョブとしてまとめることで、トランザクションが失敗して再実行が必要となるケースを減らすことができる。
裏では、DML処理毎に小さなテーブルファイルが生成されており、それらを統合して1つのテーブルとして見せている。

BigQueryにおけるオーバヘッド

UPDATE、DELETE、MERGEといった変更DMLには無視できないオーバヘッド有り
一方、INSERTのオーバヘッドは大きくない

BigQueryのアクセス制御

IAMを利用してプロジェクト、データセット、テーブル単位でアクセス制御ができる。
さらにData Catalogのポリシータグを作成し、カラムに対してポリシータグを付与した上で、プロジェクト毎に「きめ細かい読み取り」ロールをユーザーに付与することで、カラムへのアクセス権を付与できる。組織オーナー、プロジェクトオーナーであっても、このロールなしではカラムのデータを読み取ることはできない。
承認済みビューを試用すると、ビューが参照するテーブルへのアクセス権限を付与することなく、クエリの実行結果のみを共有できる。

INFORMATION_SCHEMAを活用した監査

INFORMATION_SCHEMAは、データセットやテーブルのメタデータを参照できるビュー。
INFORMATION_SCHEMAで、「いつ、誰が、どのようなクエリを実行したか」というデータアクセス履歴が取得できる。

INFORMATION_SCHEMA.JOBS_BY_USER：現在のユーザが送信したジョブ
INFORMATION_SCHEMA.JOBS_BY_PROJEECT：現在のプロジェクトで送信されたジョブ
INFORMATION_SCHEMA.JOBS_BY_FOLDER：プロジェクトの親フォルダで送信されたジョブ
INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION：プロジェクトに関連付けられた組織で送信されたジョブ

Dataproc

Dataprocとは、マネージドHadoop/Sparkサービスのこと。
ストレージとコンピュートが分離されている。
高速な起動（90秒以内）ができる。
ストレージ分離、高速起動という特徴を生かしてエフェメラルクラスタとして利用できる。ジョブ実行時にクラスタを起動し、ジョブが完了したらクラスタを破棄する
Hadoop/SparkクラスタのVMは自動スケーリングを設定できる。

Dataproc Hub

Dataprocクラスタを起動し、JubyterLab環境を提供する。

Data Catalog

テクニカルメタデータ、ビジネスメタデータの管理を提供するマネージドサービス。
テクニカルメタデータは自動的に連携される。一方、ビジネスメタデータはユーザがタグ付けを行って管理する。

Dataflow

Apache Beamを利用した、フルマネージドでサーバレスな分散データ処理基盤。
PythonでETL処理を記述する。
ジョブグラフ（ジョブの流れ）をCloud Console上で確認できる。
最適かつ利用可能なゾーンを自動で選択する。
データ処理量に応じて自動でスケール（オートスケールさせずに、ワーカ数を指定した方がより早く処理が完了するケースもある）
バッチ、ストリーミング両方とも処理できる。

補足）Apache Beamについて

データ処理に特化した統一プログラミングモデル。
バッチとストリーミングを同じ書き方で記述できる。
Apache Beamは、Dataflow以外にもApache SparkやApache Flinkといった分散処理基盤上で実行可能。
Java、Python、Goなどのプログラミング言語で記述できる。
Built-in I/Oと呼ばれる、様々なデータソースとのコネクタが提供されている。

Cloud Composer

Apache Airflowを利用した、フルマネージドのワークフロー管理サービス。
Cloud Composer環境は、Kubernetes Engineクラスタ、Cloud Storageバケット、Cloud Logging、Cloud Monitoringで構成される（バックグラウンドではCloud SQLも利用されている）
Airflowウェブサーバやデータベースのマシンタイプを選択できる。
Pythonでワークフローを定義する。
PythonファイルをCloud Storageにアップロードすることで、自動的にワークフローがデプロイされる。
AirflowのWeb UIで作成されたワークフローを見ることができる。
ベストプラクティスとして、変換処理はワーカ側（BigQueryなど）にやらせて、なるべくDAGはシンプルに保つことが推奨される。

DAG：一連のタスクを有効非巡回グラフとしてまとめたもの
タスク：DAGにおけるひとつひとつの処理。個々のタスクにはオペレータを利用して処理内容を記述する
オペレータ：Bashコマンドを実行するBashOperatorやPythonコードを実行するPythonOperatorなど。幅広いオペレータが提供されている

Cloud Composerにおけるアクセス制御

環境オプションで、ウェブサーバにアクセスできるIP範囲を指定できる。プライベートIPのみを指定することも可。

DAGで利用する接続情報の管理

DBやAPIの接続情報は、AirflowのAdminメニューでConnectionsとして保存することができる。しかし、Web UI上にアクセス可能なユーザ全員が接続情報を閲覧・編集できるのはよろしくない。Secret Managerに接続情報を保存することで、より安全に管理できる。

Cloud Data Fusion

CaskData社のCDAPと呼ばれるOSSのデータパイプライン構築サービスを利用した、フルマネージドなデータ統合サービス。
ノーコードでETLパイプラインを構築できる。
データ読み取りや変換といった個々のタスクをノードとして定義し、ノード間をつないでパイプラインを表現する。
ノードの定義にはプラグインを用いる。クラウドサービス、DB、ストレージ等と連携するための多様なプラグインが用意されている。
パイプラインの実行環境として、Dataprocを利用してエフェメラルクラスタが作成される。
データリネージを管理できる。

Data Fusionの利用手順

まずインスタンスを作成する。
GUI上で、パイプラインを作成する。
パイプラインを実行する。

Cloud ComposerとCloud Data Fusionの比較

Cloud Composerはワークフロー制御が主眼。個々のETLジョブはBigQueryやDataflowを利用する。
一方、Cloud Data Fusionはデータ統合に軸足がある。作成した個々のパイプラインは独立しているので、複数のパイプラインでオーケストレーションが必要な場合には、Cloud Composerを利用する。

VPC Service Controlsによるアクセス制御

Cloud Storage、BigQueryなどのGoogle Cloudサービスに対して仮想的なセキュリティ境界を設定し、「特定のVPCネットワークや送信元IPアドレスからのアクセスのみ許可する」、「境界外の未承認リソースへのデータコピーを防ぐ」といったコンテキストベースのアクセス制御ができる。
サービス境界内では自由に通信できるが、境界を超える通信はデフォルトでブロックされる。
例えば、BigQueryにIP制限をかけたかったら、VPC Service Controlsを使えばよい。
対応サービスはこちらを参照のこと。
https://cloud.google.com/vpc-service-controls/docs/supported-products?hl=ja

Cloud Loggingでの監査

以下の3種類のログを保管、検索、管理するサービス。

管理アクティビティログ
システムイベントログ
データアクセスログ

管理アクティビティログには、IAM権限変更や、VM インスタンス作成などが含まれる。デフォルトで有効で無効化できない。

システムイベントログは、Google Cloudによるシステムイベントのログ。利用者の操作に関係なくシステム上のイベントが記録される。デフォルト有効で、無効にできない。

データアクセスログは、BigQueryやCloud Storageなどのデータを含むリソースへのアクセスログのこと。BigQueryはデフォルトで有効だが、他サービスはは無効。読み取りアクセスは量が多いので注意が必要。「IAMと管理」→「監査ログ」で有効/無効にできる。

Cloud Loggingの集約シンク

組織、あるいはフォルダにシンクを作成し、その配下のリソース全てのログをエクスポートする機能。もれなくログを収集できる。

Cloud Asset Inventoryでの監査

Google Cloud上のすべてのリソースの状態、つまり「いつの時点で、どんなリソースが、どのような設定であったのか」を、アセットとして検索、エクスポートできる。

なぜデータレイクが考案されたか

将来的に発生し得る未知の質問に答えるため。データマートでは事前に定められた質問にしか答えることができない。

2022-07-31

読書メモ～エンジニアのためのデータ分析基盤入門

データエンジニア

概要

エンジニアのためのデータ分析基盤入門を読んで、重要そうなところをメモする。

データ分析基盤とは何か

データ分析のために作られたシステム
- つまり、データ基盤とは異なるシステムである。
  以下の書籍によると、データ基盤はデータ分析だけを目的にしてない。
  ビジネスアプリケーションからの利用も想定している。
  
  Google Cloudで始めるデータエンジニアリング入門
データレイク、データウェアハウス、データマートの３つを合わせたもの
- データレイク
  - 構造化＆非構造化データ
  - ローデータをそのまま保管
- データウェアハウス
  - 構造化データ
  - 整理されて管理された状態のデータ
- データマート
  - 構造化データ
  - データウェアハウスと、データマートには明確な線引きはない
  - ダッシュボードなど、特定の目的のために作られている

データ分析基盤の変遷

シングルノード　→　マルチノード　→　クラウド
シングルノード
- CPU毎にスレッド単位で並列処理
- 複数のCPUで手分けして処理
マルチノード
- Apache Hadoop/Sparkなどのプロダクト
- 複数のノードで手分けして処理

データ分析基盤を取り巻く人

データエンジニア
- データを集めて統合
- データ分析基盤やデータパイプラインの整備
- 分散システムの構築管理
- データの取り込みやETLを通したデータパイプラインの最適化
- データが格納されているストレージの管理
- ユーザへのアクセス提供
データサイエンティスト
- 機械学習、深層学習
- Python、Java
データアナリスト
- ビジネスプロセスに詳しい
- SQL、BIツール
- データから価値を見出す

セルフサービスモデル

従来のモデル
- データマートやダッシュボードの作成もデータエンジニアが担う
セルフサービスモデル
- データエンジニアはパイプラインの新規作成、システム不具合対応、コスト最適化に集中
- データマート作成はデータアナリストが、ダッシュボード作成はユーザが行うという風に分担する
  # 正直あまりイメージが湧かない、、、

データエンジニアリングで心に留めておくべき事項

さまざまなインターフェースを提供
メタデータの取得（データの在り処をわかりやすく示す）
データ品質の可視化
パフォーマンスの向上（パーティション、ファイルフォーマット、圧縮を駆使する）
コストの最小化
障害が起こりにくい
すぐに復旧できる

データ世界のレイヤー

コレクティングレイヤー：データを集める（バッチ、ストリーミング）
プロセシングレイヤー：データを処理する
ストレージレイヤー：データを保持する
アクレスレイヤー：データを利用する

プロセシングレイヤー

ETLとデータラングリング

データラングリング（データプリパレーションとも呼ばれる）
- データストラクチャリング：非構造化　→　構造化
- データクレンジング：重複削除、フォーマット化、名寄せ
- データエンリッチング
ETLとデータラングリングの違い
- どちらもデータを変換するという点では一緒
- 「データラングリングでデータから価値を見つける。データラングリングで見つけたルールを、ETLにてワークフローとして定義する」という感じ

暗号化

トランスペアレントエンクリプション：書き込み時に暗号化、読み出し時に復号
エクスプリシットエンクリプション：読み込み、書き込みも元のデータがわからなくしてしまう
ディアイデンティフィケーション：個人を特定しにくくする。データを入れ替えたり、別の値に置き換える
- コーホートパターン
  - データを入れ替える
- サブトラクトパターン
  - 四則演算して値を変換してしまう。例：引き算する、割り算する

データ品質/メタデータ計算

ツールも存在するが、Apache Spark向けのDeequライブラリ等で、
データ品質やメタデータ取得処理を自前で実装するのが現段階では多い

ストレージレイヤー

5つのゾーンに分けて管理することで、ライフサイクル設定やアクセス権限の整理が容易になる - ローゾーン - 集めたデータをそのまま保存しておく（データレイク） - ゴールドゾーン - データウェアハウス、データマート - ステージングゾーン - データを不変な状態で保管。オリジナルのデータを修正してしまうと戻せなくなる。ステージングゾーンのデータをもとにゴールドゾーンを修復する。 - クォレンティンゾーン - 機密情報を保持する隔離されたゾーン。アクセス権限を絞る。 - テンポラリゾーン - 気が向いたときに好きなデータを取り込む。自動的に削除される設定を入れておくと良い。

タグによるゾーン管理

物理的なゾーン分け
- 例えば、ゾーンごとにストレージを分ける
- ゾーン間のデータ移動に時間や費用といったコストがかかる
タグによるゾーン分け
- タグを変更するだけで、ゾーンを変更できる
- 物理的なデータの移動が発生しない。瞬時にゾーンが切り替えられる
- 例えば、タグ毎にアクセス制御を設定することで、アクセス管理が容易になる

アクセスレイヤー

GUI
BIツール
ストレージへの直接アクセス
APIアクセス
メッセージキュー

SSOT (Single Source of Truth)

フィジカルSSOT：物理的にデータを1か所に集める
ロジカルSSoT：データを1か所に集めたように見せる

バックアップ

フルバックアップ：すべてのデータをバックアップする
一部のデータをバックアップする
バージョニング：コストは高くなるが効率的にバックアップと復元が可能

アクセス制御

以下の粒度で制御を行う - ゾーン - データベース - テーブル - カラム

技術スタック

コレクティングレイヤー

バッチ
- Embulk
- ダンプ
ストリーミング
- Apache Kafka
- Amazon Kinesis
- Google Cloud Pub/Sub

プロセシングレイヤー

バッチ
- Apache Spark
- Apache Hive
ストリーミング
- Spark Streaming

ワークフローエンジン

Digdag
Apache Airflow
Rundeck

ストレージレイヤー

フォーマット

Paruquet
圧縮形式
Snappy
gz
bz2

スプリッタブルとは - 1つのファイルを複数のノードに分けて処理可能

◆ スプリッタブルなフォーマットと圧縮形式の組み合わせ | | Paruquet | Avro | CSV/JSON | | ---- | ---- | ---- | ---- | | Snappy | Y | Y | - | | gz | Y | Y | N | | bz2 | - | - | Y | | 無圧縮 | Y | Y | N |

データ保管時の注意点

スモールファイル：小さすぎるファイルが沢山ある
データスキューネス：ファイル間でファイルサイズに偏りがある。1つのファイルが巨大で、もう一方のファイルが相対的に小さい

アクセスレイヤー

BIツール
- Redash
- Metabase
- Power BI
- Tableau
- Looker
ノートブック
- Jupyter Notebook
API
- API Gateway

アクセス制御

chmod/chown
IAM

メタデータ管理

ビジネスメタデータ：テーブル定義やドメイン知識など
テクニカルメタデータ：データ品質、プロファイルなど
オペレーショナルメタデータ：操作履歴など

ビジネスメタデータ

データベース名
テーブル名
カラム名
データ型
パーティション
テーブルステータス
テーブルオーナー

テクニカルメタデータ

テーブルの抽出条件：テーブル取り込み時の抽出方法
リネージュ、プロバナンス
テーブルのフォーマット（Paruquet、Avro）
テーブルのロケーション
ETL完了時間
テーブル生成予定時間

リネージュとプロバナンス

リネージュ：データの紐付き
プロバナンス：データの生まれ、起源

オペレーショナルメタデータ

テーブルステータス
- In-Service：当日のワークフローが完了
- Error：当日のワークフローでエラーが発生
- Investigating
メタデータの更新日時
ファイルサイズの中央値
誰がアクセスしているか

データプロファイリング

カーディナリティ
- どれくらいデータがばらけているか
- 性別はカーディナリティ低。IPアドレスはカーディナリティ高
- データ分析基盤では特に意識する必要なし
セレクティビティ
- カラムの値がどれくらいユニークか。値が高いほどユニーク。最大値は１
- 全５レコード中、５レコードとも異なる値　→　セレクティビティは、1 = 5/5
- 全５レコード中、２レコードが同じ値。つまり、カラムには４種類の値が存在　→　0.8 = 4/5
デンシティ NULL
- NULLの密度
- NULLの密度が高ければ、そもそもカラムをクエリ―の対象から除外するという判断につながる
コンシステンシー
- データの表現に一貫性があるか
- 例えば、UTCとJST
参照整合性
- IDのフォーマットや、カラムの論理名に一貫性があるか
コンプリートネス
- 全レコード中、すべてのカラムに値が入っているレコードがどれくらいあるか
データ型
レンジ：特定の範囲内の値に収まっているか
フォーマット：郵便番号の桁など
形式出現頻度
データ冗長性
- 最小値は１。小さいほど良くて、１だとベスト。
- 数値が高いと、色んなところにコピーが存在してしまっている
- 数値が低ければ、データが１か所に集まっている。つまり、SSoTが実現できている
バリディティレベル
アクセス頻度
- テーブルがどれだけアクセスされているか
- 不要なデータを検知する
その他
- 合計、最大値、最小値、平均値、標準偏差

データカタログ

どのようなデータが存在しているか。以下のような情報をカタログに記載する - データタイトル - 形式（CSV、JSON） - データのオーナー

2022-07-10

メモ　〜　Azureの基本をマスターする：データの基礎

データエンジニア Azure

概要
コアデータの概念を探る
- コアデータの概念を調べる
- データロールとサービスを調べる
  - データの世界における仕事上の役割について調べる
  - データサービスを特定する
Microsoft Azureデータの基礎: Azure でリレーショナルデータを探索する
- 基本的なリレーショナルデータの概念を調べる

概要

Microsoft LearnでAzureの基本をマスターする：データの基礎を自己学習する
このコースは以下の４つのラーニングパスからなっている。今回は２ポチ目までをメモ
- コアデータの概念を探る
- Azureでリレーショナルデータを探索する
- Azureの非リレーショナルデータを探索する
- Azure で最新のデータウェアハウス分析を調べる

コアデータの概念を探る

コアデータの概念を調べる

データ形式

構造化データ：表など
半構造化データ：JSON
非構造化データ：画像、ビデオ

ファイル形式

区切りテキストファイル（CSVなど）
JSON
XML
BLOB（画像、ビデオなど）
Avro
ORC
Parquet

Avro

行ベース。Apache によって作成された。各レコードには、レコード内のデータの構造を説明するヘッダーが含まれる。ヘッダーは JSON として格納。データはバイナリ情報として格納。アプリケーションでは、ヘッダー内の情報を使用してバイナリデータを解析し、格納されているフィールドを抽出する。データを圧縮し、必要なストレージとネットワーク帯域幅を最小限に抑えることができる。

ORC (Optimized Row Columnar)

列ベース。HortonWorks によって開発。Apache Hive での読み取り、書き込み操作を最適化する。ORC ファイルには、データの "ストライプ" が含まれる。各ストライプには、列または列のセットのデータが保持される。

Parquet

列ベース。Cloudera と Twitter によって作成。 Parquet ファイルには、行グループが含まれる。各列のデータは、同じ行グループにまとめて格納される。

データベースの詳細

リレーショナルデータベース

エンティティ：リレーショナルデータベースの表のこと
インスタンス：表の各行のこと。レコード
主キー (Primary Key)：インスタンスの識別子
外部キー (Freign Key)：参照先

非リレーショナルデータベース

NoSQLデータベースとも呼ばれたりする。

キーバリューデータベース
ドキュメントデータベース：値がドキュメントであるキーバリューデータベース
列ファミリデータベース：列が、列ファミリと呼ばれるグループになってる。
グラフデータベース：ノードとしてのエンティティと、その関係を定義するリンクが格納される

トランザクションデータ処理

トランザクションデータの例：銀行口座間のお金の移動
処理中のデータに、即時アクセスできることが必要
オンライントランザクション処理 (OLTP) と呼ばれる
ACID セマンティクス（トランザクションの4つの基本的特性）のサポート要

原子性 (Atomicity)

各トランザクションは 1 つの単位として扱われ、完全に成功するか、完全に失敗しなければならない。たとえば、1 つの銀行口座の資金を引き落とし、別の銀行口座に同額を入金するトランザクションでは、両方のアクションが完了する必要がある。いずれかの操作を完了できない場合、もう一方のアクションは失敗しなければならない。

一貫性 (Consistency)

トランザクションでは、1 つの有効な状態から別のそれに移る場合のみ、データベースのデータを取得することができます。上記の借方と貸方の例を続けると、トランザクションの完了状態に、あるアカウントからもう一方のアカウントへの資金の転送が反映されている必要があります。

分離性 (Isolation)

同時実行トランザクションが相互に干渉することはなく、一貫性のあるデータベースの状態になる必要があります。たとえば、あるアカウントから別のアカウントに資金を転送するトランザクションが処理中である場合、これらのアカウントの残高を確認する別のトランザクションでは、一貫性のある結果が返される必要があります。残高確認のトランザクションでは、送金 "前" の残高を反映する 1 つのアカウントの値や、送金 "後" の残高を反映する他のアカウントの値を取得することはできません。

持続性 (Durability)

トランザクションがコミットされると、トランザクションはコミットされたままになります。アカウント送金トランザクションが完了すると、変更されたアカウントの残高が保持されます。これにより、データベースシステムをオフにした場合でも、コミットされたトランザクションは再びオンになったときに反映されるようになります。

分析データ処理

一般的なアーキテクチャ
- データレイク/OLTPデータベース　→　ETL　→　データウェアハウス　→　オンライン分析処理（OLAP）モデル　→　クエリ実行
  - データレイク：構造化データだけでなく、非構造化データも保管する。データは加工されてない。 ‐ データウェアハウス：読み取り用に最適化された構造化データを保管する
  - OLAP モデル：分析ワークロード用のデータストレージ。ドリルアップ、ドリルダウンできる。

データロールとサービスを調べる

データの世界における仕事上の役割について調べる

データベース管理者

ユーザーにアクセス許可を割り当て
データのバックアップ/リストア

データエンジニア

データの統合
データクリーニング
データガバナンスルールの策定
データを転送および変換するのに必要なパイプラインの実装

データアナリスト

データを調査および分析して視覚化やグラフを作成
組織が情報に基づいた意思決定を行えるようにする

その他

データサイエンティスト
データアーキテクト
アプリケーション開発者
ソフトウェアエンジニア

データサービスを特定する

Azure SQL

Azure SQL Database: フルマネージドのPaaS型DB
Azure SQL Managed Instance: SQLサーバをホストしたインスタンス。Azure SQL DB よりも柔軟な構成が可能
Azure SQL VM: SQLサーバがインストールされている仮想マシン。最も柔軟な構成が可能

Azure Database

オープンソースのリレーショナルデータベース用。

Azure Database for MySQL
Azure Database for MariaDB
Azure Database for PostreSQL

Azure Cosmos DB

非リレーショナル (NoSQL) データベース
JSON ドキュメント、キーと値のペア、列ファミリ、およびグラフとしてデータを格納

Azure Storage

複数のデータを格納できる。データレイクをホストできる。

BLOB コンテナー: バイナリファイル用のスケーラブルでコスト効率の高いストレージ
ファイル共有: 企業ネットワークにあるようなネットワークファイル共有
テーブル: データ値の読み取りと書き込みを迅速に行う必要があるアプリケーションのキー値ストレージ

Azure Data Factory

データを転送および変換するデータパイプライン
ETLソリューションを構築するために使用される
ETLはExtract Transform Loadの頭文字

Azure Synapse Analytics

統合されたデータ分析ソリューション。次の分析機能に対して単一のサービスインターフェイスを提供

パイプライン
SQL
Apache Spark
Azure Synapse Data Explorer: Kusto クエリ言語 (KQL) を使用して、ログおよびテレメトリデータにリアルタイムでクエリを実行する

Azure Databricks

一般的な DatabricksプラットフォームをAzure に統合したもの
Apache Spark データ処理プラットフォームと SQL データベースセマンティクスおよび統合管理インターフェイスを組み合わせて大規模なデータ分析を実現

Azure HDInsight

Apacheのビッグデータ処理テクノロジをホストするクラスターを提供

‐ Apache Spark - Apache Hadoop - Apache HBase - Apache Kafka - Apache Storm

Azure Stream Analytics

リアルタイムのストリーム処理エンジン
データストリームを取り込み、クエリでデータ抽出。クエリ結果を出力に書き込む
リアルタイムの視覚化のためにストリーミングデータを取り込む

Azure Data Explorer

ログおよびテレメトリデータのクエリを提供するスタンドアロンサービス

Azure Purview

企業規模のデータガバナンス
データマップを作成し、複数のデータソースとシステム間でデータ系列を追跡
データの整合性を確保

Microsoft Power BI

分析データモデリングおよびレポート用のプラットフォーム ‐ 対話型でデータの視覚化
Power BI サービスの Web ベースのレポートとアプリ、および Power BI モバイルアプリを使用して公開・配信

Microsoft Azureデータの基礎: Azure でリレーショナルデータを探索する

基本的なリレーショナルデータの概念を調べる

リレーショナルデータを理解する

エンティティ＝テーブル
インスタンス＝テーブル内の行
各列には特定のデータ型で格納される。例）Order テーブルの Quantity 列は整数の数値に制限される

正規化について理解する

正規化はデータベースの専門家によって使用される用語
データの重複を最小限に抑え、データの整合性を強制適用するスキーマ設計プロセスを表す
以下の規則により、正規化できる
- 各 "エンティティ" を独自のテーブルに分離します。
- 個別の "属性" を独自の列に分離します。
- "主キー" を使用して各エンティティインスタンス (行) を一意に識別します。
- "外部キー" 列を使用して関連エンティティをリンクします。

SQL を探索する

SQL は、"構造化照会言語" を表す
リレーショナルデータベースとの通信に使用される
SQL ステートメントを使用して、データベース内のデータの更新や、データベースからのデータの取得などのタスクを実行
SQL を使用する一般的なリレーショナルデータベース管理システムには、Microsoft SQL Server、MySQL、PostgreSQL、MariaDB、Oracle などがある

一般的な SQL 言語

Transact-SQL (T-SQL)。このバージョンの SQL は、Microsoft SQL Server と Azure SQL サービスによって使用されます。
pgSQL。この言語には、PostgreSQL で実装されている拡張機能が含まれています。
PL/SQL。 Oracle によって使用される言語です。 PL/SQL とは、手続き型言語/SQL を意味します。

SQL ステートメントの種類

DDL ステートメント

データベース内のテーブルやその他のオブジェクトを作成、変更、および削除

CREATE
ALTER
DROP
RENAME

CREATE TABLE Product
(
    ID INT PRIMARY KEY,
    Name VARCHAR(20) NOT NULL,
    Price DECIMAL NULL
);

DCL ステートメント

ユーザーまたはグループに対する権限を許可、拒否、または取り消して、データベース内のオブジェクトへのアクセスを管理

GRANT
DENY
REVOKE: 以前に許可されたアクセス許可を削除

GRANT SELECT, INSERT, UPDATE
ON Product
TO user1;

DML ステートメント

テーブル内の行を操作します。データの取得 (クエリ)、新しい行の挿入、または既存の行の変更、不要になった行の削除。

SELECT
INSERT
UPDATE
DELETE

SELECT FirstName, LastName, Address, City
FROM Customer
WHERE City = 'Seattle'
ORDER BY LastName;

WHERE: 条件と一致する行だけが選択、更新、または削除される ‐ ORDER BY: 指定した列でデータが並べ替え
JOIN: 1 つのテーブル内の行を他のテーブル内の行と接続

SELECT o.OrderNo, o.OrderDate, c.Address, c.City
FROM Order AS o
JOIN Customer AS c
ON o.Customer = c.ID

SET: 特定の列の値を更新

UPDATE Customer
SET Address = '123 High St.'
WHERE ID = 1;

DELETE FROM Product
WHERE ID = 162;

INTO: テーブルと列を指定
VALUES: INTO句で指定した列に格納する値のリストを指定

INSERT INTO Product(ID, Name, Price)
VALUES (99, 'Drill', 4.99);

データベースオブジェクトについて説明する

ビュー

SELECT クエリの結果に基づく仮想テーブル

ビューを作成する。

CREATE VIEW Deliveries
AS
SELECT o.OrderNo, o.OrderDate,
       c.FirstName, c.LastName, c.Address, c.City
FROM Order AS o JOIN Customer AS c
ON o.CustomerID = c.ID;

作成したビューに対し、クエリを実行。

SELECT OrderNo, OrderDate, LastName, Address
FROM Deliveries
WHERE City = 'Seattle';

ストアドプロシージャ

データベースに対する連続した複数の処理を一つのプログラムにまとめ、データと共に保存できるようにしたもの
外部からクエリを実行するのと同じ手順で実行できる。

ストアドプロシージャを作成する。

CREATE PROCEDURE RenameProduct
    @ProductID INT,
    @NewName VARCHAR(20)
AS
UPDATE Product
SET Name = @NewName
WHERE ID = @ProductID;

作成したストアドプロシージャを実行。

EXEC RenameProduct 201, 'Spanner';

インデックス

インデックス無：集合住宅を歩き回り、各戸の表札を見て配達先かどうか確かめる
インデックス有：住民の情報が書かれた見取り図で配達先を確認して向かう
インデックスは以下のような列に設定すると、効果を得やすい
- SQLの検索条件で頻出する列や、結合条件に指定されている列
- テーブル内の全データの量に対して、取得対象のデータが少ない列
- Bツリーインデックスの場合はカーディナリティが高い列（格納されている値の種類が多い列）、ビットマップインデックスの場合はカーディナリティが低い列

CREATE INDEX idx_ProductName
ON Product(Name);

products.sint.co.jp

2022-07-10

読書メモ　〜　実践Terraform

Terraform

概要
バージョン
コマンド
記号
ファイル
variable
変数の型
local
output
data
provider
リスト []
組み込み関数
モジュール
三項演算子
count
randomプロバイダ
dynamicとfor_each
ベストプラクティス
構造化、リソース参照パターン（２２〜２３章）

概要

「実践Terraform」を読んで、忘れたくないところをかいつまんでメモしておく
主に１〜３章の内容と１７章以降の内容をメモする
for文については言及なし。for_eachについてもそれほど詳しくないので別途調べる必要あり
公式ドキュメントはここ　Overview - Configuration Language | Terraform by HashiCorp

バージョン

2019年5月にリリースされたTerraform 0.12は、0.11以前のバージョンと互換性がないので要注意。

コマンド

terraform init
terraform plan
terraform apply
terraform destroy
terraform fmt -recursive
terraform validate

記号

「+」 : 追加されるリソース
「-」：削除されるリソース
「-/+」：削除後に再度追加になるリソース

ファイル

tfstateファイル：terraform planを一度でも実行すると、terraform.tfstateファイルが作成される。現在のリソースの状態を記録。tfstateファイルとHCLコードに差分があれば差分のみ変更する。

variable

変数は、variableとlocalの２種類がある
terraform apply -var 'variable名'という形で、実行時に変数を上書き可能
デフォルト値を設定することも可能

variable "example_instance_type" {
  default = "t3.micro"
}

resource "aws_instance" "example" {
  ami = "ami0c3fd0f5d33134a76"
  instance_type = var.example_instance_type
}

変数の型

全7種類
string, number, bool, list, tuple, map, object
以下に、list、object、tupleの例を記載

variable "ports" {
  type = list(number)
}

variable "person" {
  type = object({ name=string, age=number})
}

variable "person" {
  type = tuple([string, number])
}

local

上述の通り、変数はvariableとlocalの２種類がある
実行時に上書き不可
デフォルト値設定不可

locals {
  example_instance_type = "t3.micro"
}

resource "aws_instance" "example" {
  ami = "ami0c3fd0f5d33134a76"
  instance_type = local.example_instance_type
}

output

terraform apply実行後に、出力される値を定義
以下の例だと、example_instance_id = i02bd77505ab68856fというのがディスプレイに出力される

resource "aws_instance" "example" {
  ami = "ami0c3fd0f5d33134a76"
  instance_type = "t3.micro"
}

output "example_instance_id" {
  value = aws_instance.example.id
}

data

AWS AMIイメージ等の外部データを参照
以下の例では、イメージ名とイメージの状態（available）でフィルタし、most_recentで最新のAMIを取得している

data "aws_ami" "recent_amazon_linux_2" {
  most_recent = true
  owners = ["amazon"]

  filter {
    name = "name"
    values = ["amzn2-ami-hvm-2.0.????????-x86_64-gp2"]
  }

  filter {
    name = "state"
    values = ["available"]
  }
}

resource "aws_instance" "example" {
  ami= data.aws_ami.recent_amazon_linux_2.image_id
  instance_type = "t3.micro"
}

provider

AWS、GCPなどのAPIの違いを吸収してくれる
terraform initによりプロバイダのバイナリファイルがダウンロードされる
暗黙的に検出もしてくれるが、明示した方が管理上好ましい
デフォルトのリージョンなども指定可能

provider "aws" {
  region = "apnortheast1"
}

リスト []

[ ]によりリストを渡すことができる
以下の例だと、ingressとegressのセキュリティグループ2つをリストとして、[aws_security_group.example_ec2.id]で渡している

resource "aws_security_group" "example_ec2" {
  name = "example-ec2

  ingress { 
    from_port = 80
    to_port = 80
    protocol = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port = 0
    to_port = 0
    protocol = "-1" 
    cidr_blocks = ["0.0.0.0/0"]
  }
}


resource "aws_instance" "example"{
  ami = "ami0c3fd0f5d33134a76"
  instance_type = "t3.micro"
  vpc_security_group_ids = [aws_security_group.example_ec2.id]
}

組み込み関数

文字列操作などのよくある処理が組み込み関数として提供されている
file('ファイルのパス')で、外部ファイルを読み込むことができる

モジュール

ディレクトリ配下

module "web_server" {
  source        = "./http_server"
  instance_type = "t3.micro"
}

./http_serverディレクトリ配下にmain.tfを作成して次のコードを実装する。モジュール呼び出し側で指定したinstance_typeを引数にとって、モジュールからインスタンスを作成している。

variable "instance_type" {}

resource "aws_instance" "default" {
  ami                    = "ami-0c3fd0f5d33134a76"
  instance_type          = var.instance_type
}

三項演算子

三項演算子で条件分岐を実現できる。
以下の例では、terraform plan -var 'env=prod'とすると、instance_typeはm5.largeになる。envがprod以外の値だと、instance_typeはt3.microになる。

variable "env" {}

resource "aws_instance" "example" {
  ami           = "ami-0c3fd0f5d33134a76"
  instance_type = var.env == "prod" ? "m5.large" : "t3.micro"
}

count

複数のリソースをいっぺんに作成するのに利用できる。
count = 3の場合、count.indexの値は{0, 1, 2}となる。
以下の例では、3つのVPC（10.0.0.0/16、10.1.0.0/16、10.2.0.0/16）が作成される。

resource "aws_vpc" "examples" {
  count      = 3
  cidr_block = "10.${count.index}.0.0/16"
}

randomプロバイダ

ランダム文字列を自動で生成できる
文字列長と特殊文字の有無を指定可能
以下の例だと、32文字のランダム文字列（特殊文字なし）を生成している
random_string.password.resultに値が返ってくる

provider "random" {}

resource "random_string" "password" {
  length  = 32
  special = false
}

dynamicとfor_each

dynamicにより動的にリソース生成可能
以下の例だと、for_eachにセットした値は、ingress.value、つまり<動的ブロック名>.valueで取り出している

variable "ports" {
  type = list(number)
}

resource "aws_security_group" "default" {
  name = "simple-sg"

  dynamic "ingress" {
    for_each = var.ports

    content {
      from_port   = each.value
      to_port     = ins.value
      cidr_blocks = ["0.0.0.0/0"]
      protocol    = "tcp"
    }
  }
}

ベストプラクティス

Terraformのバージョンは固定すべき
providerのバージョンも固定すべき（パブリッククラウドは進化が早く、環境差異が出やすい）
削除操作を抑止
でも、.tfファイルからリソース定義を削除してterraform applyするとリソースが削除されてまう（※マジで要注意！！！）
コードフォーマットすべし
コードのバリデーションをすべし（サブディレクトリ配下まで実行するにはコマンドに工夫要）
TFLintで不正なコードを検出すべし（tflint --deep）
暗黙的な依存関係を把握し、depends_onで依存関係を定義する

構造化、リソース参照パターン（２２〜２３章）

手間なのでスキップするが、大事なので忘れたら読み返そう

2022-05-07

読書メモ～達人に学ぶDB設計徹底指南書　（第1章～第3章）

DB設計データエンジニア

概要

達人に学ぶDB設計徹底指南書を読んで、重要そうなところを忘備のため、メモする。
第9章まであるが、まずは第3章までメモ

１章

POA v.s DOA

POAはProcess Oritented Approachのこと。従来のシステム開発ではプロセス主流だった。現在ではDOA（Data Oriented Approach）が一般的。POAでは受注、発注、仕訳といったプロセスごとにデータを管理するのに対し、DOAではすべてのプロセスでデータを共用する。

DB v.s DBMS

DBは「データの集まり」を指す概念。DBMSはDBを管理するためのシステム。

主なDBMS

以下を参照のこと。Oracle、MySQL、Microsoft SQL Server、PosgreSQLがRDBMSの４強。

db-engines.com

３層スキーマ

外部スキーマ（外部モデル）＝ビュー（ユーザから見たデータベース）
概念スキーマ（論理データモデル）＝テーブル（開発者から見たデータベース）
内部スキーマ（物理データモデル）＝ファイル（DBMSから見たデータベース）

２層スキーマ（外部と内部スキーマのみ）だと、変更に対する柔軟性がない。概念スキーマは緩衝材の役割。論理的データ独立：外部スキーマ　⇔　概念スキーマ物理的データ独立：概念スキーマ　⇔　内部スキーマ

２章　論理設計と物理設計

概念スキーマと論理設計

論理設計のステップ

エンティティの抽出
エンティティの定義
正規化
ER図の作成

内部スキーマと物理設計

物理設計のステップ

テーブル定義
インデックス定義
ハードウェアのサイジング
ストレージの冗長構成決定
ファイルの物理配置決定

サイジング

キャパシティとパフォーマンス両方の観点から行う
データベースの性能の問題の8割はストレージのI/Oネックによって起きる
データ量はシステムの運用開始から増加していくのが基本
パフォーマンスの指標は２つ
- 処理時間＝「特定の処理が何秒以内に終了するか」
- TPS（Transaction Per Second）＝「1秒あたりにどれだけたくさん処理できるか」
類似のシステムのデータを流用する、またはプロトタイプを構築して検証するといった方法でサイジングを行う
精度の高いサイジングは難しいので、安全率をかけること、スケーラビリティの高い構成にすることが重要

冗長構成

少なくともRAID5で構成する。お金に余裕があればRAID10にする

ファイルの物理配置

ファイルには以下の5種類がある。

データファイル
インデックスファイル
システムファイル
一時ファイル
ログファイル

一時ファイルはサブクエリを展開したデータやソートデータなど
DBMSはデータファイルへの変更を受け付けたあと即座にデータファイルを変更するわけではない。ログファイルにいったん変更リクエストをためて、一括して変更を反映している。ログファイルはDBMSごとに呼び名が異なる。
- Oracle: REDOログ
- PostgreSQL, SQL Server, DB2: トランザクションログ
- MySQL: バイナリログ
①データファイル、②インデックスファイル、③システムファイルは継続的にデータ量が増加する
5つのファイルのうち、I/O量が最も多いのは①データファイル。次は②インデックスファイルと④一時ファイル
理想的にはすべてのファイルを異なるディスク（RAIDグループ）に配置すること。I/O分散という点で望ましいが、ディスク増
妥協案として、I/Oコストの低いファイルを１つにまとめる。つまり、③システムファイル、⑤ログファイルを１つのディスクに配置し、それ以外は各々ディスクを用意する

バックアップ設計 主要なバックアップ方式は以下の3種類

増分バックアップが最も無駄が少ないが（同じデータを何度もバックアップしない）、リカバリ時に必要なファイルの個数が増えるため、リカバリに要する時間が長くなる。また完全にデータを復旧できる可能性が最も低い（すべてのバックアップファイルが正常である必要があるため）
「完全バックアップ＋差分バックアップ」、または「完全バックアップ＋増分バックアップ」が一般的
バックアップウィンドウ（バックアップに使用できる時間）、リカバリウィンドウ（リカバリに使用できる時間）、何世代前までのデータを残すか、いつ時点の状態に復旧させる必要があるかを考慮して、バックアップ設計を行う

リカバリ設計

復旧手順は厳密には以下のように分けられる。この３つをすべて実施することで障害直前の状態に復旧できる。

リストア：完全バックアップのファイルをもとにデータベースを復旧
リカバリ：差分（または増分）バックアップしていたトランザクションログを適用する
ロールフォワード：データベースサーバーに残っているトランザクションログを適用する

3章　論理設計と正規化

テーブルの構成要素

‐ テーブルの行をレコードとも呼ぶ（ほかの資料ではインスタンスと呼んでいる場合もあった） ‐ テーブルの列をカラム、あるいは属性とも呼ぶ - キーには、主キーと外部キーがある - 外部キーの役割は、参照整合性制約を課すこと - 外部キーが設定されている場合、データの削除は子から順に行うほうが良い - それ以外には、親レコードを削除する際に「親がいない子」もあわせて削除する、あるいは削除SQL文をエラーにする、といった方法もある。こういった一連の削除動作を「カスケード」と呼ぶ - キーとなる列にはコードやIDなどの表北池野定まった固定長文字列を用いる - 列ごとに以下の制約を設定できる - NOT NULL制約：値がNULLでないこと - 一意制約：値に重複がないこと - CHECK制約：とりうる値を制限する。例：「１～５までの整数」、「"開発"、”人事”、”営業”のいずれかの文字列」 - テーブル定義において、可能な限りNOT NULL制約を付加すること - テーブル名、列名には以下の制約がある（DBMSによっては標準外の独自拡張として、日本語や特殊文字をサポート） - 使用できる文字は、半角アルファベット、半角数字、アンダーバーのいずれか - 先頭の文字はアルファベット - 同じテーブル名、同じ列名は存在できない

正規化とは何か？

正規化の目的は、一つの情報が複数のテーブルに存在して無駄な領域と煩雑な更新処理を発生させてしまうことを防ぐ。データの冗長性を排除してデータの不整合を防ぐ ‐ 正規化によって作られるのが正規形 ‐ 正規形にはレベル５まであるが、レベル３まで覚えておけばとりあえずOK
基本的には正規化＝テーブルの分割
正規化とは元に戻すことができる可逆的な操作 i.e. 非正規形 ⇔ 正規形
正規化の逆操作は、結合（JOIN）

第１正規形

行と列が交差するマス（エクセルだとセルと呼ばれる）には、一つの値しか含まない

第２正規形

第２正規形は、部分関数従属の解消によって得られる i.e. 部分関数従属 → 完全関数従属
部分関数従属とは、主キーの一部の列がほかの列に従属していること
テーブルの分割によって解消できる
部分関数従属があると、何が悪いのか？
- 主キーが不明な場合に（NULLの場合に）、主キーが従属している列の値を登録できない

第３正規形

‐ 第３正規形は、推移的関数従属の解消によって得られる i.e. 推移的関数従属 → 完全関数従属 ‐ あるテーブルに社員ID、部署コード、部署名の列がある。それぞれは{社員ID} → {部署コード} → {部署名}という関数従属性がある。この場合、テーブルに推移的関数従属があるという - テーブルの分割によって解消できる

第3.5・4・5正規形

これはスキップする
第3.5正規形は、正式にはボイスーコッド正規形、またはBCNF （Boyce-Codd normal form）と呼ばれる

2022-04-20

CKAに合格しました【22年4月】

CKA Kubernetes

結論

Udemyだけではダメ、ぜったいにKiller.shの模擬試験もやる！

道のり

21年12月、仕事でKubernetesに触れる。まったく知識がなく、さっぱりわからない
22年１月、Kubernetes完全ガイドを買う。インターネットで調べつつ、チラチラと本を読む。なんとなく、PodとかServiceについて理解する。
22年2月、初旬にUdemyを購入してCKAの勉強を始める。この講座は最高、超おススメ！授業を全部観て、その後Practice Testを2周。LightningTestとMockTestも2周。
22年3月、下旬に初めてCKAを受験。うまく試験が開始できず、パニックになる。複数のクラスターにアクセスする形式になれず、ノードにSSHせず作業してしまい、うまく問題が解けない。結果、さらにパニックになる。案の定、58点で不合格。（合格には66点必要）
22年4月、仕事や転職活動で時間が取れない。勉強する気もおきない。なんとか時間をとって勉強する。どうやれば受かるか調べたところ、Killer.shという模擬試験が無料で試験に付帯されていたことを知る。Killer.shの無料問題と模擬試験を2周ずつ実施。並行して、UdemyのLightningTestとMockTestも2周実施。中旬に再度受験して92点で合格。

雑記

CKA試験はおススメ
Kubernetesの初歩がわかる
よく考えたらCKAの試験はそれほど難しくない
試験で実際にコマンド叩くの楽しい、記憶にも定着するので最高！もっとこういう試験が増えてほしい
MumshadさんのUdemy講座は最高！
Killer.shも最高！ ‐ CKAの試験はエイリアスがデフォルトで設定されてる。k run test-pod --image=nginxでOK
合格だけを目指すなら本は買わなくてもいい。Udemyだけで十分
一応、Kubernetes.ioはブックマークしておく