🌊

【Medium】7 Best Practices for Data Ingestion

2022/09/20に公開

がく@ちゅらデータエンジニア です。
※2022年9月よりちゅらデータ株式会社にJoinしました

データエンジニアリングな話題などをMediumで毎朝、サジェストされるんですが、これちゃんと読んでいかんとなーということで、読んだメモなどを残しておこうと思って書いて行こうと思います。

概要

https://medium.com/codex/7-best-practices-for-data-ingestion-f336c6b5128c
今日はこちら
「データインジェスト(取り込み)に関わる7つのベストプラクティス」


原文より拝借

"Data Engineering is the new Sexiest job in 2022"
2022年、データエンジニアリングは、最もセクシー(最高)な仕事である。
また、需要とキャリアにおいて、データサイエンスを上回った。
データエンジニアリングの需要が天文学的に増加している。

(田代コメント)
AIやMLなどでデータをつかって、なにかできない!?なんかすごい解決方法あったりしない??っていう話があり、データアナリストやデータサイエンティストに分析をしてもらい、問題を解決する・・・データコンサルティング的なことをしたりしていますが、そもそも「データを分析するための基盤」が整備されていない
なので、データサイエンスの仕事の8割はデータの前準備・・・なんて、まことしやかに言われたりしてますね・・・

データエンジニアリングとは?

データエンジニアリングとは 、データを 収集、 保存、 分析 するためのシステムを 大規模に設計、構築 すること

様々なソースからデータを収集する

収集するデータは様々、こんなにいっぱいなのは史上初めて!これらを収集するのはとても大変

  • 構造化データ(CSVとか)
  • 半構造化データ(JSONとか)
  • 非構造化データ(画像や動画)

スタンダードレポジトリにデータを格納する(?)

生データを共通の場所に保存することが重要。そして使い物になるようにするために、前処理(クレンジング=きれいにする)が必要。
さらに、コンプライアンスに準拠する必要あり。(PII=個人情報データの扱いとか)

最終的なステークホルダー/データ消費者

関係者は

  • ビジネス関係者
  • アプリケーション開発
  • プログラマー
  • アナリスト
  • データサイエンティスト

皆、ビジネスを理解し、意思決定のためにデータを分析して、インサイトを得ようとしている

インフラストラクチャーの拡大

最後にスケーリングは、データエンジニアにとって最も重要なタスクの1つです。データは指数関数的に増大します。データをロードし、保存し、分析するためのインフラは、データとともに成長する必要があります。

(田代コメント) Snowflakeなら、StorageとComputeが無限?に増やせるので、ここを考慮しなくても良くなりますね(ニコニコ あ、クラウドDWHなら、そこまでスケーリングを考えなければならないってことは少なそう、無いとは言ってない

データの取り込み

データエンジニアは、データをある場所から別の場所に移動させるさまざまなパイプラインを書くことに50%以上の時間を費やしている。

方式は

  • ELT
  • ETL
    がある。

(田代コメント)
クラウドDWHになると、ELTがよくて、一旦全部取り込んじゃって、DWHのパワーを生かして、「T(変換)」をする のが良き

  • バッチ式データ取り込み
    • 最も一般的
  • リアルタイム/ストリーミングデータ取り込み
    • CDC(Change  Data  Capture)を使ったリアルタイム
    • 株式市場分析、ダイナミックプライシング などで重要
    • ※Snowflakeなら、Snowpipeだね
    • ※Pub/Subといったものからの取り込みもこれに含まれるか
  • Lambdaベースの取り込み
    • ※よくわからん・・・
    • バッチ取り込みとリアルタイム取り込みの両方のベストプラクティスを利用するモノ
      • バッチ層
        • 全体をみる、より正確、遅い
      • スピード層
        • リアルタイム処理、正確性はそこまで保証しない
      • サービング層
        • バッチレイヤーからの出力はバッチビューの形で、スピードレイヤーからの出力は準リアルタイムビューの形で、サービングに転送される。この層はバッチビューにインデックスを付け、アドホックに低レイテンシーでクエリできるようにする。
        • ※よくわからん・・・

データ取り込みにおける課題

  • 多様なデータソースに対応するため、カスタムプロトコルが必要
  • ソースに含まれるデータの形式や規格が異なる
  • 読み出し時、保存時のデータ整合性
  • データの品質と重複

(田代コメント)
このような問題を解決するためにELTのSaaSサービス(Fivetranや troccoといった)が出てきてると思う
読み出し時、保存時のデータ整合性については、一旦取り込みの成功重視でDWHに取り込むのが重要と考えている(基本、文字列型と数値型 日時型は文字列型とまずとりこむ)

データ取り込みでのベストプラクティス

  • データの問題に対してソースでアラートを追加
  • 変換を適用する前に、すべての生データのコピーをとっておく事
  • データ取り込みはかんたんではないので、余裕を持ったスケジュールを
    • クライアントの期待値コントロールは特に重要
  • パイプラインの自動化、オーケストレーションの利用、SLAの設定
    • SLAの設定はとくに重要
  • データインジェストパイプラインは冪等性を担保しなければならない
    • Idempotence(=冪等性)とは、ある操作を複数回実行しても、最初の実行後は結果が変わらないことを意味する
    • リバッチしてもデータが変な状態にならない、何度も同じデータがInsertされないみたいなことを指してます。対象日のリバッチの先頭で対象日のレコードをDELETEして、改めてデータを入れ直すみたいな挙動のこと(識者に教えてもらいました、ありがとぉ)
    • 最も重要なのは、重複したレコードを読み込まないようにすること
    • ※スナップショットを毎日全部って、DWHに投入。最新版をViewで見る・・・といったことはしてました
  • テンプレート化、開発用フレームワークの再利用
    • データ取り込みのパイプラインの多くは繰り返しが多いため、パイプライン開発のためのテンプレートを作成することが重要
  • パイプラインの文書化
    • とても重要
    • ※私は、ここをMiroを使って記載してます

Discussion