❄️

私が妄想している最強のデータ基盤2023

2023/01/08に公開

新年になったので今年のやりたいことをまとめようと思いたち筆をとっています。単にやりたいこと書いてもただのポエムになってしまうので、私が今時点で妄想している最強のデータ基盤を描いて、その中でまだ触ったことのない技術を今年触っていこうという意気込みを最後に書こうと思います(意気込みだけにならないように頑張りたいです!)

まだ触ったことないものもあるので妄想しているレベルです。

アーキテクチャ図

まず最初に結論から書いていきます。

なぜこのアーキテクチャが最強と思うのか

データ基盤として機能を分けると以下の6つの領域に分かれると思っています(もう少し細かく分けることもできたりします。例えばDMBOKとかではホイール図で11の領域に分けたりしています)

データ基盤の領域 主に関連するDMBOKの知識領域 主担当
データ蓄積 データストレージとオペレーション、データセキュリティ データエンジニア(DBA)
データ連携 データ統合と相互運用、参照データとマスタデータ データエンジニア
データ加工(モデリング) データモデリングとデザイン データエンジニア
データマネジメント ドキュメントとコンテンツ管理、メタデータ、データ品質 データエンジニア、みんな
データ利活用 DWHとBI データアナリスト、データサイエンティスト
共通基盤機能 データセキュリティ クラウドエンジニア

※主担当のアクターの用語はもっとちゃんと整理していいと思っていますが、まぁいったんざっくりでいい気もしています。

とりあえず、最強のデータ基盤という異常はこれらがすべて網羅されている必要があると思うのでマッピングしてみます。

データ基盤の領域 コンポーネント ポイント
データ蓄積 S3、Snowflake え、改めて説明する必要ありますか?(コスパ重視ならRedshiftでもいいかもだし、データ量が少ないならPostgreSQLでもいいかもですが、まぁSnowflake使っておけばまぁ間違いないでしょ。あと、dbtvaultとかその辺りのエコシステムでみてもRedshiftよりSnowflakeの方がいいと思う今日この頃)
データ連携 Embulk 別にここは何でもいいです。FivetranとかtroccoとかSaaSでいい感じのあるので、適宜組み合わせていくといいかなと思います。コード管理とサーバレスでコンテナ化しやすいという観点でEmbulkにしています
データ加工(モデリング) dbt Core みんな大好きdbtです。この領域のデファクトでしょ!エコシステムがすごく発達しているのでdbt採用していればどんどんベストプラクティスが取り入れられるのでこだわりたいところです。dbtvaultを試していきたい
データマネジメント dbt docs、elementary、OpenMetadata OpenMetadata以外はS3+CloudFrontでホスティングのコストがほぼかからないので、いいですよね。OpenMetadataは今のところややホスティングのコストすごいので、Open Search ServiceのServerlessでどこまでコスト最適化できるかというところがポイントになるかなと思っています。
データ利活用 QuickSight、SageMaker Canvas 別にここも何でもいいです。AWSのサービスが始めやすいかなと思います。TableauとかThoughtSpotとかDataRobotとかDataikuとかいろいろ言い製品あると思うので、使いやすい奴でいいと思います!
共通基盤機能 各種AWSサービス(割愛) いろいろ認証認可のところとか監視やジョブ管理などの運用系の機能やセキュリティ系のサービスを組み合わせて作っていきましょう!※この辺りを去年は頑張ったな

マッピングも済んだので、あとはなんでこの技術なのというところを補足していきます。
私はデータ基盤は以下の非機能がポイントだと思っています。

  • 性能・拡張性:データ量はどんどん増えていくが最初から見通すことはできないので、無限の拡張性と初期投資の少なさが重要
  • 可用性:データをプロダクトにするという将来を見据えたときには一定のレベルを担保するべき
  • 運用保守性:少人数で運用していかないといけない(というかデータをプロダクトにするレベルでないと予算がそんなに出ない)
  • お金:24時間365日って必要なことはほぼないしだいたい使われるのは営業日の日中帯なので、アイドル時間多いから無駄な課金を避けるサーバレスの仕組みが重要

また、開発者体験も大事だと思っています。

ということで、データ基盤のアーキテクトとして重視するポイントは以下です。

  • サーバレスでいくべし!
    • Snowflake
    • ECS/Fargate
    • S3/CloudFront/Lambda/Cognito
    • Codeシリーズ
    • QuickSight/SageMaker
  • 開発関係の情報のSSoT(Single Source of Truth)化
    • GitHub

開発者体験を重視していきつつサーバレスになっていればいいと思うのでSaaSサービスをどんどん取り入れていけばいいと思っていますが、サーバレスの形でセルフホスティングしていくことができるものはセルフホスティングしていけばいいとも思っています(そっちの方がコスパいい場合がある)

コスパとかいいましたが、このデータ基盤はSnowflakeを除くとAWS内でセルフでホスティングできるので、"パラノイア"的にNWの外にデータを流したくないような(ポリシーを変えられない)企業でも導入できます。※SnowflakeもPrivateLinkとIP制限を組み合わせて閉塞網に対応できます。

現実世界ではなかなか最強のデータ基盤を実現するためのいくつかの障壁がありますが、一番はまだまだインターネットを介してのデータのやり取りに一定の不安を持っている組織が多いというところですね。モダンデータスタックのようにSaaS組み合わせた基盤は言うは易く導入は難しな企業も多いと思います。
普段の仕事から如何にNW的に閉じた環境でありながら、オンプレミス環境のデータをモダンな基盤に持ってきていくことができるかみたいなところを考える癖がついているのかもしれないです。そこに一定のフラストレーションも感じたりするのですが、逆にこの辺りが一種の特徴なのかなと思ったりします。

でも最近SaaSサービスもオプションで顧客のプライベートNW上で実行できるような機能を提供し始めているので、本当にコスパの面だけで天秤にかけられる世の中になりつつあるのかもしれないですね。(結局、開発画面はSaaSのもともと提供しているクラウドサービス上みたいな形が自然だと思うので、データパイプラインの開発中に本番データのプレビューが飛んだりするとしたら本番データを使った開発にSaaSを取り入れる難しさは残るのかなと思っています。闇が深い)

もっとディープに書きたいこと(=今年の抱負)

これ以降はポエムになります~(軽く読み飛ばしてもらっていいです)

データパイプラインの詳細

基盤要素としてのアーキテクチャはこれまで書いた通りですが、本当はそのうえで動くデータパイプラインのアーキテクチャとかをもっと深く書きたいと思っています。
例えばdbtvaultがいいのか、dbt Style Guideに沿ってkimballさんチックな方針で作っていくのかとかいろいろあります。

この辺りはハンズオンとしてbookでまとめていきたいなと思っています(時間が取れるかどうか…)。
個人的には銀の弾丸みたいなものはないかなと思いつつも、この辺りの勘所をこれからデータエンジニアをやっていく人がつかめるようなハンズオンにしたい気持ちでいます(私の理解も深まると思うのでこれは最低限やりたい)

データマネジメント関係

データ品質(Data Observabilityという表現の方が個人的にはしっくりきます)辺りはelementaryが得意とするところのイメージですが、ここは一種OpenMetadataでもカバーできそうな気もします。
他にもGreat Expectationsとかもあるので、どんなものが最強なのか、この辺りは年末辺りにまた別の結論になっていそうな気がします。

IaCも頑張る

基盤屋としてのキャリアが長くなってきたので私の強みとしてはクラウドエンジニアとかDBA(データベースアドミニストレータ)としてのロールもこなせるところだと思っています。なので、そこの強みを生かしてデータ基盤のIaC化も力入れたいと思っています。(妄想中の最強のデータ基盤のTerraformテンプレートとかGitHubに追加したい気持ち。部品部品はハンズオン用に作るTerraformのファイルで揃いそうな気もしてます)

↓すでにあるこれとか
https://zenn.dev/jimatomo/books/d49ddf2e18ae8e

SnowflakeのTerraformプロバイダーも触っていきたい所存

最後に

データエンジニアリングは総合格闘技的な側面があるのでカバーするべき領域が広いですが、だいぶ全体を見通せる力がついてきた気がするので、今年も引き続き知見の少ない領域にどんどん挑戦していきたいと思います!
(ちなみに、この記事を読んだ後から"総合格闘技"という表現、気に入ってます)

ちなみにこの記事を書くにあたっては以下のイベントのレポートをめっちゃ食っちゃ参考にしています。(他にも日々インプットしていますが、この記事書くにあたって改めて見返してみたらだいぶ影響受けてたことに気づきました。収斂進化ということにさせてくださいw)
https://dev.classmethod.jp/articles/report-saikyo-data-architecture/

Discussion