本記事の位置付け
下記読書会のための要約です。
https://gaisaba.connpass.com/event/334165/
課題図書
翻訳版
英語版
もともとは英語版をじっくり読むスタイルの読書会でしたが、進めているうちに翻訳版が出たことや、内容全体を早めにキャッチアップしたいことから、今は翻訳版を1章ずつ読み進めています。
今回の範囲
9章 アナリティクス、機械学習、リバースETLへのデータ提供
このうち、後半部分を担当します。
9.5 アナリティクスやMLに対してデータを提供する方法
9.5.1 ファイル交換
データ分析にファイルを利用する例
- データサイエンティストが顧客のメッセージのテキストファイル（非構造）を読み込んで、顧客の感情を分析する
- 事業会社が請求書データを一連のCSVファイル（構造データ）をパートナー企業から受け取り、アナリストが統計分析をする
- 小売業者がデータベンダーから競合のWebサイト上の商品画像（非構造）の提供を受け、コンピュータビジョンを使って自動分類を行う
ファイルを提供する方法を決める要因
- ユースケース
- ビジネス分析なのか、オペレーショナル分析なのか、組み込みなのか
- データ消費者のデータ取扱プロセス(最重要)
- 個々のファイルサイズと数
- アクセスするのは誰か
- データの種類
- 構造データ、半構造データ、非構造データ
データ消費者のデータ取扱プロセス が最重要なのは、データ消費者がデータ共有プラットフォームを使えないので、ファイルでデータ提供しなければならない場合が多いから。
ファイル提供の手段
- メール
- 一度送信したら二度と取り戻せない
- コラボレーションプラットフォーム
- バージョンの一貫性が保てる
- Microsoft 365 、 Google Docs など
- オブジェクトストレージ
- 大きなファイルが少数ある場合
- データレイク
- 常時ファイルが供給される場合
オブジェクトストレージとデータレイクは実体としては同じもの説もあるが、ここではどういう意味で分けている・・・？
オブジェクトストレージとデータレイクは、一般的にはファイル交換ではなく「データ共有」に分類される。
9.5.2 データベース
OLAP データベースにデータを入れ、そこにクエリをかけて利用するイメージ。
利点
- スキーマによる秩序と構造
- 行列レベルでのきめ細かいアクセス制御
- 高性能、高並行
BI システムとの連携
- 通常、データ処理のワークロードをソースデータベース共有する
- 上記の境界はさまざま
Tableau の場合
- 最初にクエリを実行し、データベースから取得したデータをローカルに保存
- OLAP/BIのスライスとダイス（対話型のフィルタリングと集計）方法
- ローカルのデータコピーを用いてサーバ常で直接実行
Looker の場合 <- その他のモダンなBIシステムも同様
- クエリプッシュダウンと呼ばれる計算モデルに依存
- データ処理ロジックを特殊な言語（LookML）にエンコード
- ⬆️を動的なユーザー入力と組み合わせてSQLクエリを生成
- ソースデータベースに対してクエリを実行し表示
⬇️Looker がわからなくて調べました。。。⬇️
-> 9.5.6 セマンティックレイヤとメトリクスレイヤ も参照
データサイエンティストとデータエンジニアの役割分担
データサイエンティスト
- DBに接続
- データを抽出
- 特徴量の選択や特徴量エンジニアリングを行う
- 変換されたデータセットをMLモデルに供給
- モデルで予測結果を生成
データエンジニア
- データサービスレイヤの管理
- 性能、コスト
- コンピュートとストレージが分離されたDBでのコスト管理は、オンプレよりも微妙な最適化問題
- 主要なユースケース（ETL、アナリティクスやデータサイエンス向けのデータ提供など）ごとにクラスタを分けることが一般的な推奨事項
- さらにチームごとにクラスタを分ける場合もある（チーム別の予算管理のため）
管理上は分けた方がスッキリするかもしれないが、クラスタを分けるとそれなりのオーバーヘッドが発生する。現実にはそんなにたくさんのクラスタを建てられない会社が多いのではないか。
性能に関する考慮事項
- データレイテンシ
- クエリ性能
- 並行性
-> 9.2.3 組み込みアナリティクス で詳述しているらしい
9.5.3 ストリーミングシステム
- 従来のクエリによるデータ提供と異なり、出力されたメトリクス (emmited metrics) が含まれる
emmited metrics がなんなのかの説明なし(T_T)
メタデータとかのことなのか？？
- オペレーショナルアナリティクスDBの役割が増えている
ストリーミングを使用する機会は増えていくので、慣れておこう！
9.5.4 クエリフェデレーション
Trino, Presto, Starburst など。
- ひとつのクエリエンジンで、複数のデータソースにアクセスしてクエリを投げられる
- クエリフェデレーションの性能が十分でない場合は、一部またはすべてのデータソースから OLAP データベースまたはデータレイクにデータを取り込むことを検討すべし
- 読み込み専用アクセスの設定も可能（特定のバージョンのデータだけを読むことができる）
- アクセス制御やコンプライアンスが重要な場合に検討すべき選択肢である
Presto も Starburst も Trino のことなので、この分野での Trino の存在感すごい
9.5.5 データ共有
組織間でのデータ交換はすべてデータ共有だが、ここでは特にクラウド環境における大規模なマルチテナントストレージシステムを通じた共有を指す。
9.5.1 によれば、データレイクやオブジェクトストレージはデータ共有の仲間らしい
データ消費者（アナリストやデータサイエンティスト、一般ユーザー、パートナー企業など）がクエリを実行する上で、データ共有という選択肢は魅力的。
Redshift, BigQuery, Snowflake など。
9.5.6 セマンティックレイヤとメトリクスレイヤ
データエンジニアはストレージや処理の性能のことばかり気にしがちだが、どんなに早く処理ができても、データ品質とクエリ品質が悪ければ、間違った結果が早く得られるだけだ。
データ品質
- データそのものの品質
- 悪いデータを除外／改善するさまざまなテクニック
クエリ品質
- ビジネス上の質問に対して正確な回答を返すために、適切なロジックを持つクエリの作成方法
メトリクスレイヤ／セマンティックレイヤ／ヘッドレスBI
ビジネスロジックを管理し計算するためのツールである。
例：Looker と dbt(data build tool)
Looker の LookML
標準的なメトリクスを定義しておいて、それを下流のクエリで参照する
-> これによって、同じようなロジックをあちこちに書かなければならない／スクリプトによって同じはずのロジックが異なる、といった問題を解決できる
SQLの一部を関数化するようなイメージを持ったのですが、UDFとはどう違うのか？
また、関数化したところで、みんながその関数を使ってくれるかどうかはどう保証するのか？
…などの疑問は、触ってみれば解決するのかもしれない！
dbt (data build tool)
セマンティックレイヤに関する著者の見解
このレイヤが、この後より上流にシフトしていくだろう。
このレイヤに関する新規参入企業も多い。
⬇️セマンティックレイヤに関して、いつか読みたい関連ブログ⬇️
9.5.7 ノートブックによるデータの提供
いま最も人気のノートブックは Jupyter およびその後継の JupyterLab である。
Jupyter は Julia + Python + R の略。
⬇️Julia って誰だよと思ったら、言語の名前でした。⬇️
言語に関わらず、考慮すべきはノートブックからデータへのアクセス方法である。
概念図
ノートブックからデータにアクセスする際の認証情報
- データエンジニアの主要な考慮事項である
- ソースコード上に認証情報を入れるべきではない
スケーラビリティ
- データサイエンティストをノートPCから開放し、クラウドの計算力とスケーラビリティを活用すべし！
- 利用するストレージとメモリの柔軟な拡張
- 分散実行システム（Dask, Ray, Spark など) を導入
- SageMaker, Google Cloud Vertex AI, Azure Machine Leaning など
9.6 リバースETL
分析側のシステム(OLAP)で算出した内容を、処理側(OLTP)に持たせること。
言葉としては最近の流行りだが、実践としては以前から行われてきたことである。
例：
- データソース が CRM （顧客関係マネジメントシステム）
- ⬆️のデータをもとに、分析システムで顧客のリードスコアを算出する
- ⬆️で算出したリードスコアをCRMにも持たせる
本文中では、リバースETLがフィードバックループを生み出すことが警告として挙げられていた。
フィードバックループ自体は基本的にはいいことだと理解していますが、ここで問題とされているのは、以下のようなケースで広告費の無駄が生じること。
例えば、Google Ads のデータをダウンロードし、あるモデルを使って新しい入札額を計算し、その入札額をGoogle Ads にロードして戻して、また同じプロセスを始めるとしよう。入札額計算モデルのエラーがあり、入札額が高くなったとしよう。すると広告はますますクリックされるようになり、あっというまに大量の広告費が無駄になる！
リバースETL自体の問題というよりは、Google Ads のようなお金がかかる機能に対する処理を自動化してガードをつけておかないと、管理者の知らないうちにコストが発生するから気をつけましょうという話だと理解。
9.7 一緒に仕事する人
以下に限定されないが、たとえば以下のような人たちと一緒に仕事をすることになる。
- データアナリスト
- データサイエンティスト
- MLOps/MLエンジニア
- ビジネス - データや技術関係以外の利害関係者。管理職や経営幹部など。
データエンジニアは、データエンジニアリングライフサイクルだけでなく、利害関係者の手に渡ったあとの利用との間のフィードバックループを意識するべきだ。
職務と関心ごとの分離
立ち上げ当初はデータエンジニアがMLエンジニア・データサイエンティストを兼任することもあるが、持続可能ではない。
データメッシュを採用すると、チームの責任が再編成され、すべてのドメインチームがデータ提供を担うことになる。
データメッシュと組織の成功のためには、以下が鍵。
- 各チームがデータ提供の役割を効果的に果たす
- 各チームが効果的に協力する
9.8 底流
- セキュリティ
- データ管理
- Data Ops
- データアーキテクチャ
- オーケストレーション
- ソフトウエアエンジニアリング
…などを検討・考慮しよう！
9.9 結論
データ提供のステージで、データエンジニアリングライフサイクルは理論的には終了する。
しかし、データエンジニアは今後も新しいフィードバックを常に受け入れ、自分の技術を向上させ、システムを改善しつづけましょう！
