nokoのブログ

こちらは暫定のメモ置き場ですので悪しからず

データエンジニアリング実践

技術全般

はじめに

  • データエンジニアリングまわりを復習したときのメモです。
  • Webアプリから発生するデータを使ってモデルを継続的に学習させるためのデータ基盤を想定しています。

データエンジニアリング導入以前ver

概要

  • CSVファイル
    • PoC時点などのシンプルな実装だと、サーバ腹持ちCSVファイルのみでデータを管理する、ということもあると思います
  • リレーショナルデータベース（RDB）
    • 同時実行制御・耐障害性
    • 一貫性・拡張性・信頼性・速度

関連技術要素

課題

  • Webアプリケーションデータベースとは疎にしたい（分ければ良いが）
  • 性能が出ない
    • 統合データ環境として作られていると、分析用途のクエリは性能が出にくい（アドホックな分析を想定して設計されていない）
  • インフラコストが高い
    • 利用するデータを格納する→事前に必要になりそうなデータをとにかく集めておく

データウェアハウス導入ver

概要

  • データウェアハウス
    • ELTがメイン
    • SQL/非構造化データを扱わないなら
    • 集約することで、データのサイロ化を防ぐ（Dx条件の一つ）
    • 設計のポイント
      • データ保存量の拡張手段（制約がないか）
      • データの取り出し手段

関連技術要素

  • 【DWH】BigQuery（GCP）
    • コスト
      • マルチテナント方式であるため、事前のプロビジョニングのコストが発生しない
        • コンピュートまたはストレージのどちらか大きいほうのピークに合わせてサイジング調整する必要などがない
      • クエリでスキャンした容量に対して課金
        • カラム指向ストレージなので、LIMITは意味なし
        • デフォルトで作られるキャッシュテーブル（24h）は、スキャン料金の対象にならない
    • データ取り込み
      • バルクロード: BigQuery Data Transfer Service, など
      • ストリーミング挿入: Fluentd, Dataflowのコネクタ, StriimなどのCDCソリューション（MySQLなどと同期）
      • フェデレーション: 外部テーブルを指定
    • データマート用途での利用
      • クエリキャッシュ、データマートテーブル作成、ビュー、マテリアライズドビュー
      • INSERTはいいが変更DMLは苦手なので、中間テーブルを次々にCTASで作成するのが良い（テーブル有効期限も合わせて設定）
      • データマートも兼ねたり。中間データの作成など。
    • 1レコード500バイトと仮定すると、1千万レコードで5GBで、それくらいならRDBをデータマートにしても良い？
    • cdc

課題

  • 非構造化データを扱うことが増えてきている
    • 顧客接点のデジタル化
    • 「2025年までに、全世界のデータのうち80%が非構造化データを占めるようになる」

データレイク導入ver

構成イメージ

スクリーンショット 2021-03-14 11.56.15.png

概要

  • データレイク
    • 未加工のデータを収集して蓄積するための場所
    • 「データを中心としたアーキテクチャとなっており、データのサイロが最小化され、スケーラブルな分散環境でデータの処理が互いに干渉し合うことなく実行される場所」
  • データマート
  • ストリーミング処理
  • ETL
    • 1ファイルあたり128MB-512MBが良い
    • パーティション含めたデータの持ち方の設計が大事
  • ワークフロー管理
    • 処理の依存関係を制御、処理のタイミングを適切にコントロールする
  • メタデータ管理
    • データリネージ
      • あるデータがどのデータからどういう過程を経て作られたか

関連技術要素

  • 【データレイク】S3
    • オブジェクトストレージに格納するデータは、1MB~1GBくらいが良い
  • 【ストリーミング処理】Fluentd
  • 【ストリーミング処理】Kafka
  • 【ストリーミング処理】Pub/Sub（GCP）
    • データ量の急なバーストに耐え得るスケーラビリティ
  • 【ストリーミング処理】Dataflow
    • Apache Beam
    • リアルタイムに整形・集計などのデータ処理をするパイプラインを構築する
    • 外部サービスとのI/Oコネクタが標準で提供されている
    • Pub/Subで収集→Dataflowで処理→BQで蓄積、など
    • S3に書き出すこともできる
    • DataflowSQLもある
    • ノートブックもある
    • SpotifyはリアルタイムレコメンドにApacheBeamを利用
  • 【ストリーミング処理】Kinesis Data Firehose
  • 【ETL】DataProc（GCP）
    • マネージドHadoop/Spark
    • ファイルパスの接頭辞をhdfs://からgs://へ変更するだけでGCSにアクセスすることができる
    • 90sで起動
    • メモリを追加してPresto, GPUを追加してSparkで機械学習もできる
    • DataProcHubでJupyterNotebookも利用可能
    • DataProcでGCS上にHiveパーティションデータを作る→それをBQで直接触る、などもできる
    • BQのストレージをDataProcから直接触ることもできる（BigQueryStorageAPIの利用）
  • 【ETL】Glue（AWS）
    • DataCatalogとETLという2つのコンポーネントから構成されるサービス
    • 「S3のデータファイルから、AWS Redshift Spectrum と AWS Athenaのテーブルを作成する」ツール
      • Glueでデータカタログと呼んでいるテーブル定義は、Apache Hive のTableのことで、 Glueは、S3のファイルから、Hive Tableを作るツール
    • Glueはクローリングによるテーブル定義作成・更新に加えて、Apache Sparkを使って、プログラミングにより、ユーザーがより細かくデータ加工することもできます。
    • AWS GlueのジョブにはSparkとPython Shellの2つのジョブタイプがあります。
    • データの圧縮やParquet変換
    • マスキングやパーティション化
  • 【ETL】Athena（AWS）
    • Presto
      • Hiveと違って、速い分、エラーが起きると最初からやり直す（Hiveは大規模なバッチ処理を着実に実行することに長けたクエリエンジン）
        • データの構造化は、HiveやSparkで実行する
    • S3以外もデータソースにできる
    • 読み込むサイズで料金が変わる→gzipするだけでも安くなる
  • 【ワークフロー管理】CloudComposer
    • Airflowに必要なコンポーネントが自動で起動する
      • GKE
      • GCS
      • CloudLogging
      • CloudMonitoring
      • CloudSQL（バックエンドDB）
  • 【メタデータ管理】DataCatalog（GCP）
    • GCSのデータやBQのデータを横断的に検索・管理することができる

その他メモ

参考