品質特性から眺める データ分析基盤入門 2/13 インフラエンジニア Books 30分でわかる「エンジニアのための データ分析基盤入門」 @APコミュニケーションズ様　 YUKI SAITO

@yuki_saito_en yk-st 斎藤 友樹(SAITO YUKI) システムでも野菜でもお菓子でも作ることが好きです 2 https://menta.work/plan/2650 https://www.udemy.com/user/yuki-saito-7/ @yuki_saito_en https://note.com/yukinkoyuki

@yuki_saito_en yk-st 3 https://www.ipa.go.jp/files/0 00106872.pdf

@yuki_saito_en yk-st データエンジニア(リング)を分解してみる テクニカル/データ活用/ビジネスに対して理解のあるヤツ 4 データ+エンジニア テクニカルアーキテクチャ (TA) (Python、インフラ、クラウド、セキュ リティ) ビジネスアーキテクチャ (BA) ROI、マーケティング、事業ドメイ ン、コアコンピタンス、データ活用文 化 アプリケーションアーキテクチャ (AA) ユーザフェイシングなアプリケーショ ンの集合体との連携 (ex. リバース ETLなど) データアーキテクチャ (DA) 分析、BIツールなどの利用による 企業内データの統合、分析、再配 置、etc

@yuki_saito_en yk-st 今回の「エンジニアのためのデータ分析基盤」という本をみる視点 5 データエンジニア 保守性 使用性 移植性 信頼性 互換性 機能適合性 セキュリティ 性能効率性 品 質 特 性

@yuki_saito_en yk-st データ分析基盤入門の要素を品質特性視点で再編集 6 保守性 保守のしやすさの度合い ◉ SSoT ◉ IaC ◉ ログ管理(監査) ◉ プログラミング 信頼性 機能が正常に提供されてい る度合い ◉ データのモデリング ◉ データのテスト ◉ データの冗長化 移植性 他の環境への移動しやすさ ◉ ライフサイクルマネジ メント ◉ 構成管理 ◉ SOR/SOIとの連携 (フィードバック) 使用性 理解しやすさ、使いやすさの 度合い ◉ 形式知＆暗黙知 ◉ メタデータ ◉ リネージュ 互換性 他のシステムや構成要素と 情報交換できる度合い ◉ Fileフォーマット ◉ 後方/前方互換 ◉ データ変換 機能適合性 求められる機能が実現され ている度合い ◉ プロダクト開発 ◉ アジャイル ◉ 民主化と専門組織の ジレンマ セキュリティ 情報を保護する度合い (CIA) ◉ AAA ◉ GDPR/個人情報保護 ◉ アクセス制御 性能効率性 性能に対して使用する資源 の割合 ◉ パーティション化 ◉ ファイル利用 ◉ データマート設計

@yuki_saito_en yk-st 移植性 緊急事態のための備えやデータ活用をした結果のFBのしやすさ ◉ ランク分けに応じたABCくらいにデータをランク分けする ◉ 例: Aのみデータ移行対象とする ◉ データ活用した結果は、何かしらの結果でFBしなければ意味がない ◉ BIツールでのダッシュボード ◉ APIでの別環境へのフィードバック ◉ 直接対象システム(SOR、SOE)に書き込みにいく 7

@yuki_saito_en yk-st 信頼性 システムのテスト、ソフトウェアのテストはできている。 それでは、データのテスト(CI/CD)はできていますか？ ◉ テストは棚卸ししたテーブルにおいて、(例えば)Aランクだけ ◉ Aランクは、さまざまなデータの源泉となることが多いため ◉ RDSの制約(主キー、外部キー) ◉ 全てやるのではなくて徐々にデータの状態を定義し言語化してゆく 8

@yuki_saito_en yk-st ご参考：もう少し考えてみるデータ品質 9 id 性別 1 男 2 1 3 男 4 女 5 0 6 男 id 性別 1 1 2 1 3 1 4 0 5 0 6 1 検索の条件(where 性別=’男’ や’1’)によっては50%にも15% にもなり得る。どんな条件でも それっぽい結果が出る点が 中々にあくどい。 検索の条件(where 性別=’男’ や’1’)によっては0%か65%と なる。変な検索条件の場合は 人間の違和感を発動させる。 データセット1 データセット2

@yuki_saito_en yk-st ご参考：言語化のプロセス データのテスト 10 Primary Key 重複したデータを発見すること。重 複データは算出結果のノイズや データ。操作の複雑化に繋がるの でビッグデータの世界でも PKを意 識する。 Dictionary 特定の辞書(Pythonのディクショナ リみたいな)で事前に定義した値に データが収まっているか確認す る。やってみるとボロボロ見つか る。 Record Num テーブルや日々 ETLしているデー タの件数が異常な状態になってい ないかを確認する。処理するデー タが多くなってきた際には一々全 部見切れないので必須 Check Null データのNull具合を確認。内外的 な要因でいきなり Nullが急激に増 えたりする。また、レコード内に Nullが多い場合はETLするかそも そも取り込まないなどすることも検 討する。 Zero Control 足し算の結果など、数値の整合性 が取れていることを確認すること。 エラーとなることは少ないものの 数値の計算にはミスがあると大変 なのでダブルチェックの意味でも 確認する。 Format 特定のフォーマットに沿っているか 確認をすること。 男、女、0、1、郵便番号、社内で利 用している業務用のコードなど。大 抵これらが揃っておらず大いに苦 労する。 データのテストはデータの定義を言語化するプロセスに等しい

@yuki_saito_en yk-st セキュリティ(とプライバシー) 後で大規模なデータに対するセキュリティ確保は骨の折れる作業 ◉ デジタルフォレンジクス(可監査性)を前提としてログデータ(AAA)を集め ておくと、使用性の向上にも使えて一石二鳥で良い ◉ 個人情報保護法について簡単にでも知っておくと良い ◉ 共同利用者や第三者など出口戦略も考慮したシステム作りや調整ができ るようになる ◉ 仮名加工/匿名加工などのキーワードを押さえておく 11

@yuki_saito_en yk-st 保守性 データのライフライフサイクルを考えて対策を練っておこう ◉ 柔軟な技術を選定する ◉ 前方互換/後方互換でスキーマの変更に対して柔軟に ◉ データのライフサイクルを起点に考えるのがおすすめ ◉ GDPRやTIPSRだとデータが削除されても、サービス継続に問題ないことのよう な規定もあったりする 12

@yuki_saito_en yk-st 使用性 データの使用性(使いやすさ)は財務諸表との紐付けで考える ◉ B/S的観点 ◉ Ex 売上高 = 一日のデータ量 ◉ アカデミックに寄りすぎないようコスパは意識 ◉ P/L的観点 ◉ データの出入りを管理する ◉ いわゆるリネージュ的な部分 ◉ ログの取得と利用(セキュリティのスライド) 13

@yuki_saito_en yk-st 互換性 多種多様なデータと向き合うデータエンジニアリング全開な領域 ◉ 多様なデータと向き合う ◉ プラグイン形式なライブラリがおすすめ(embulkなど) ◉ 自分たちが使うだけでなく、誰かに使ってもらうという前提を忘れずに(間 接部門であることが多いので忘れがち) ◉ Outのサービスはどの程度まで耐えられる？ ◉ Inにはどのようなインターフェースがある？ 14

@yuki_saito_en yk-st 機能適合性 専門組織と民主化のジレンマと戦おう ◉ 両機能を揃えた環境を作成するのは諦める ◉ 民主化の環境と専門組織用の環境を分離する ◉ 民主化の環境はPF開発、専門組織向けには内製で ◉ ただし、データは共通(が好ましい) ◉ データバーチャライゼーションの活用を考えてみる 15

@yuki_saito_en yk-st 性能効率性 性能効率性向上(コスト削減)は、利益創出への命綱でもある ◉ データの圧縮形式など基本的なことでも十分に対処できることもある ◉ クラウドサービスを分解して似たようなOSSを見つける ◉ OSSをいじって理解する ◉ チューニングポイントを眺める 16

@yuki_saito_en yk-st 基本的な ことが大事 17

@yuki_saito_en yk-st ありがとう ございました！ 18