仕事でデータ基盤のことを知る必要がでてきそうなのでこの本を手に取りました。
タイトルにもある通り著者の経験をもとにした実践的なシステム構成や勘所などが記載されています。よい本でした。
気になったところをメモ。
業務レイヤー（p.17）
データを生成または扱う人やシステムという業務とロール/オペレーション/アプリケーション/ストレージのレイヤーのマトリックスを作ります。 書籍にもあるように業務とレイヤーに分析・分割することでどの場所に対する改善案を行うのかが明確になります。
なんとなく全体を漠然とみて偶発的・思いつきの施策をやることを防げそうです。いい図。
履歴データ（p.24）
商品価格や商品説明などの変更を履歴として保存していないシステムの多々ありそうですが、「データ分析」という目線でみると非常に重要なのはその通りだなと思いました。
1か月前、1年前の価格がわからない（今の価格しかわからない）ようでは分析のしようがありません。言われるとその通りなのですがどの項目の変更をどこまで履歴として持つのかという要件はしっかり議論をすべきかと思います。
3層 データレイク層 / データウェアハウス層 / データマート層（p.26～）
言わずと知れた3層です。ぞれぞれの層での目的、注意点や勘所などが記載されています。基本として押さえておきたい知識です。
データマートはユースケースを想定して作る（p.38）
「データマートはユースケースを想定して作る」という視点はなかったので良いインプットとなりました。
これも言われてみるとその通りです。データマートを作るにはデータ活用をするユースケース（誰が何の目的でどのデータを見たいのか）を定義する必要があります。ユースケースが定義されていないとそのデータはいずれ活用されなくなるはずです。
メタデータ（p.48）
「メタデータ」はあまり意識していませんでした。これも非常に重要な要素ですね。
データの作成された日や属性（個人情報の有無、文字列or数値、単位、etc...）などはデータがどのように加工されたのかによってわからなくなってくるので定義しておくことは重要です。
また「そのデータは誰がどのくらい見ているのか」のようなメタデータはデータ基盤の運用や改善に必須だと感じました。
データスチュワード（p.58）
データ基盤の整備を推進し、利用者からの相談窓口する役割を「データスチュワード」と言うそうです。
聞きなれない役割名ですが思えばこれも重要な役割であり、過去に名前は違えどこういう人がいるデータ基盤はうまくいっていたと思い起こされます。
データ基盤に関する要件を聞き出し、システム構成やコストなどを考慮しつつ仕様を策定し利用者に提供するようなイメージでしょうか。プロダクトマネージャーのような存在だと理解しました。
データソースから収集方法（p.71）
書籍ではデータソースごとに収集の方法は異なるよ、と記載されています。CSVや画像などのファイル、API、ログ、端末データ（IoTなど）によって収集方法が異なるため多くの知識やノウハウがあるとのこと。（このあたりは経験上よく知っていました）
データソースの正しさはデータ分析の命です。そこを担保するためにデータフォーマットを定義する「AVRO（Apache AVRO）」のような存在は重要かもしれません。意図しない誤りを防ぐにはこうした型の定義を担保する仕組みを導入するのは検討に値すると思いました。
同様に「Apache Perquet」のようなデータ圧縮の仕組みも視野に入れるべきかと思いました。
列指向型圧縮（p.137）
分析用DBは更新処理に向いていない、というのはなんとなく知っていましたが列指向型圧縮や列の統計情報を使っていることが学べました。なるほど、と。
分析に最適化されたDBの中で何をしているのかを少し理解できました。ありがたや。
データ活用組織の文化・土壌（p.158）
組織の偉い人、クライアントの大きな声に惑わされることなくデータを活用した意思決定ができる組織の文化・土壌についても書かれています。
・データに関する文化：データを使った意思決定、データを使った業務改善を行う文化があるかどうか
・業務の実行と組織構造：データ活用を推進する部門と業務遂行する部門に乖離がないか
・必要なスキルと人材：意思決定を行うCDO、仕組みを作るデータエンジニア、業務部門との橋渡し役のデータスチュワード、分析を意思決定に生かすデータアナリストの存在
集権型、分権型、ハイブリット型（p.160）
データ活用組織のありかたが提言されています。
・初期は「集権型」：データ活用を一気に推進するために集権型の組織を作る。人数も少ないので分散させるより集中的な組織とする。
・中期は「分権型」：人数が増えると本当に必要な業務部門に人材を分散させる。業務部門への展開を狙う。
・成熟期は「ハイブリット型」：各業務部門に展開しつつ、横串的に実施する施策もある。両面で活用が推進できるようにする。
理想的な展開とは思いますが、業務部門への展開、人材の採用では課題が多くありそうです。頑張りどころなのでしょう。
データ組織の成功要因（p.162）
「データマネジメント知識体系ガイド 第二版」（日経BP, 2018）の10要素（の中の9要素）を解説してます。どれも重要な要素です。
- 幹部からの支援
- 明確なビジョン
- 前向きに取り組むべきチェンジマネジメント
- リーダーシップ統制
- コミュニケーション
- ステークホルダーの関与
- オリエンテーションとトレーニング
- 導入状況の評価
- 基本理念の遵守
- 革命ではなく進化
データ活用とセキュリティ（p.176）、セキュリティポリシー（p.181）
技術的な話ではなく、組織としての運用の話です。エンジニア寄りの仕事をしているとこのあたりは「降りてくる」ものという意識ですが、データ組織としてはセキュリティなどの各種ポリシーを制定することはとても重要な仕事です。
まとめ
以上、気になったところのメモでした。
データ基盤、データ組織と簡単に言っても、業務の分析、システム構成や技術・勘所やノウハウ、メタデータなどの考え方、組織作り、セキュリティポリシーなど検討すべきポイントは多岐にわたることがよくわかりました。
皆さまもデータ基盤に関わる際にはご一読を。
