概要
- 今年のデータ基盤に関する自分の活動を勝手に振り返る記事です。つまりポエム。
- 所属チームが対外的な広報を出していないので具体的な業務には触れません。ごめんね。
- 前日まで放置して一気に書いたので文章にまとまりが無いかも。許して。
- 中の人は都内某企業にてデータ基盤担当に従事しています。さしみたんぽぽ歴が5年(これは前職)、データ基盤の専任になってから2年目です。真っ黒なコンソール画面はさしみたんぽぽ担当になってから知った文系です。
輪読会
データ基盤ネタで2つ参加しました。今月から3つ目が動きます。
Data Governance: The Definitive Guide
the self service data roadmap
Data Management at Scale
これから
社会人学生
- さらっと触れて終わらせます。
- 前半は放送大学、後半は帝京大学で科目履修しています。目的は理工情報出身じゃないというコンプレックス解消と、将来的な進学可能性を考えた準備。
- 学び直しに流行の兆し?がありますが、楽では無いです。元々文系だったところにいきなり理系科目の大学講義ですから当たり前ですが、履修を始めてから実感しました。大学文系はあまり高校文系と接続が無いのですが、大学理系は高校理系がしっかり前提になってます。
- 大学で勉強してますってカッコ良さそうですが、学部です。どこまで頑張ったところで上限22歳相当には変わりないです。自分は30代ですが、仮に完璧に講義が理解できたとしても22歳相当の30代です。そのまま修士進学とか完全に余暇活動としてなら良いですが、就職目的だと「30代新卒」になります。社会人学生にはこの自覚が必要だった。
- 特に帝京大学の理工通信での話ですが、仕事外時間はフル投入が必要です。ご自身の大事にしたいことは何なのか、よく考えて「それでも」と振り切れるなら進学すべきだと思います。個人的には、1期1科目が適量。
- 放送大学は「教養」学部です。何がとは言わないですが、そういう内容です。大学院進学を想定しない情報系目的ならIPA高度試験を狙った方が良いです。
お仕事
仕事ネタも書きますが、具体的な状況には触れられないので「感じたこと」に留めます。
何ら裏取りのない話ですので議論の種まきポエム感覚で受け取ってください。
人で大体決まる
- 「俺たちが作ったスゴい基盤」「最新のOSSをこんなに使い倒してます」なプレゼンは多いですが、仕事していて思うのは「そこじゃないんだよな」。
- 詳細おいておきますが、何が生まれるか、どういう成果になるか、それらは所属する人の平均的気質で決まります。厄介なのは「どう使われるか」であり、これは作り手を超えた使い手集団の気質で決まってしまうため往々にして登壇での話題にはならないということです。
- 何を導入した開発したところで、迂回路は構築できます。モノをモノたらしめるのは存在自体でなく存在に対する振る舞いです。
- そもそも論ですが、数人がかりで実施した1年以上の活動結果から上澄みを拾えばある程度綺麗なプレゼンに落ち着きます。これ以上は闇なので止めておく。
- データ基盤は高い確率で個人情報や営業機密系に触れることになると思います。そこへのフォーカスが増えると嬉しいな。
- 世間的には個人情報が注目されますが、電気通信事業法、金融商品取引法、不正競争防止法も刺さる現場は多いと思います。対応してる?
- セキュリティファーストが言われるようになりましたが、ガバナンスも同じです。組織の活動スタイル(当たり前水準と言っても良い)を後から変えるのは困難です。
- 社内弁護士はお友達。新しいことをやりたくなった時に、最初に握るのはリーガルチェックです。
データ基盤の3層構造?
- 3層構造ではなくて、3種のデータ品質ラベル程度に見ておくべきだと思っています。
- データ基盤に限らず、必ず境界に位置する存在は発生するのであって、線を引けば綺麗な状態に世界を区分し固定できるという発想が無謀。
- 必要なのは「正しい状態」が常に検証できることと、その「正しい状態」の定義自体が不都合な場合に変更容易であること。変更容易は実装も含みます。ここでの「正しい」とはツールが提供するテスト機能のことではなく、組織が持つ要求や要件に適っているということです。かつデータ基盤の受益者が主体的にいつでも検証できるようになっている必要があります。セルフサービスが重要ね。
- そのために必要なのはeasyでfatな統合スイートではなく、simpleを疎に組み合わせたドメインコンポーネントのネットワーク。統合スイートを否定した段階で特定のクラウドベンダやOSSがよしなにやてくれることは期待できません。自分達の要求を自分達で定義し、「無いものは作る」の気概が大事。有名人の資料やwell-architectedに沿ってるからヨシではない。誰かにとっての課題があなたにとっても課題であっても、誰かにとってのソリューションがあなたにとってもソリューションとは限らない。
- データ基盤もソフトウェアプロダクトの一形態でしかない。Twelve-Factor Appやリアクティブ宣言の重要性は変わらない。より古くからの機能・非機能要求やソフトウェア/システム品質からも逃げられない。契約するだけで画面ボタンポチするだけで出来上がるデータ基盤スイートは存在しない。担当者のソフトウェアエンジニアリングが全て1。
- data lake/data warehouse/lake-house etcの論争は意味が無い。
- 物理技術観点での「lakeは全てのraw dataをファイルで溜めた場所で、DWHは専用のRDBMS likeなエンジンで補完する場所で〜」パターンと、3層構造観点で「lakeは生データ用で、DWHは加工済みデータ用で〜」パターンの2種類が観測される用語論争。大体のデータ基盤本はここの解説が大好き。
- 今時のDWH製品はjsonやcsvを直接クエリできますので、データの入っている場所がオブジェクトストレージか専用ストレージエンジンかというのはクエリという機能については重要ではありません。問題になるのはパフォーマンス観点でDWHネイティブのストレージを使う必要が出てきた時。非構造データをDWHにそのまま突っ込む時代はまだ遠い。
- この論争には仕事上、何の影響もない。組織内で用語とアーキテクチャに一貫性があれば問題ありません。要求・要件に集中する。今後問題になるのはfederatedやpolyglot。その時にクエリエンジンとストレージエンジンが密結合になった旧来型のDWHはNGが付くかもしれない。データメッシュが盛り上がると表面化する??
分散イベントジャーナル
- 中央集権なデータ基盤という発想が不都合に思うようになってきた
- データ基盤(もしくはガバナンス)チームの手元に全てのデータを置く、それ自体が高コストかつ障害点。
- 情報保護はデータ基盤の問題なのか? No. これは全社の課題であり、データ基盤「の」課題として取り上げられていることが間違い。DMBOKは全社の話であり、データ基盤は分析用の各論。
- データは環流する。ソースは誰かのマートであり、マートはまた誰かのソースでありうる。局所に存在する3本のドラム缶ではなく、全体的な生態系としての流路と滞留のネットワークで考える必要がある。
- ジャーナルは"データ基盤"の私物ではなく、全社のものでなければならない
- 上記の通り、流通が本命であり滞留させることが目的ではない。データウェアハウス/データレイクの発想は滞留。ジョブとしてのDAGも然り。
- では流通するものが何かというと、イベント。ユーザの個々の操作ログから、バッチ処理に至るまで、全ての出来事がイベントであり、これが流通対象。イベントの集合がジャーナル。
- データ基盤(というものがあるとして)の仕事は、これが全社に対しガバナンスが効いた状態で流通させること。滞留を監視しても意味がない。流通を指標にする。
- ジャーナルネットワークとエッジ(ドメイン)データウェアハウス
- 必要なのは確かなイベントジャーナルが「総体として」存在し、その在り方が見えるようになっていること。そこからしかるべき消費者に常にイベントとして配信されていること。
- 各々のドメインシステムは全てのイベントをジャーナルとして記録し配信し続ける。各々のドメインは生産者であると同時に消費者でもある。消費者として蓄積が行われる環境は「(エッジ)データウェアハウス」となる。消費者は、自身のジャーナルと配信されたイベントを組み合わせてサービスを提供する。ここに旧来のオペレーショナルデータベースとデータ基盤の境界は無い。
- 闇雲に行うと只のスパゲティになるので、このジャーナルと配信を横断でモニタリングしカタログ化して各々のドメインが自主的に品質検証を行えるよう支えていくのが(横断)データガバナンス基盤の仕事。あと監査可能性とセキュリティ(横断鍵管理)の担保。データ分析基盤は不要かもしれない。
- データ基盤だけが分散/リアクティブ2でなく集権/モノリスであって良いはずがない。ドメイン単位で独立して巻き戻しや再構築ができるというのは思ったより重要。その足枷にデータ基盤(=central source of truth)がなってはならない。セルフサービスと検証可能性を追求する。
最後に
来年は以下のことを妄想していきたい。
- 脱DWH3層構造
- 中央集権的でないイベントネットワークの構築とガバナンスの両立
- 社内弁護士やセキュリティ部署と仲良くなる方法
- データ基盤ROIの定め方