古今東西、フレームワークは過去の不合理や不便さに対する解決策として生まれていると思う。
特に、アプリケーション開発のシナリオで圧倒的な生産性の向上を生み出す何かが生まれたりする。
それは過去があまりにも酷かったのもあるし、リアーキテクチャのセンスが天才的なものもあると思う。
dbtは過去の分析プロジェクトで得られたいくつかの論点を解決するように作られている。
dbtは分析における様々なタスク(以下、ワークフロー）を効率よく解決するためのツールである。
分析用ではあるが、モダンなアプリケーション開発フレームワークが解決した多くの論点に基づいて
開発されている。その由来の詳細について「The dbt Viewpoint」で説明されているので読んでみた。
訳と文章作成4時間以内のスピードチャレンジなので間違っていたらすみません。
原文は平易かつ丁寧な表現で面白いので読んでみてください。
dbtの由来
2015-16年, RJMetrics社から派生した分析プロジェクトは、分析のエコシステムにおける重要な発展
を観察し参加する機会を得た。dbtの種となる考え方はこの環境で考案された。
The dbt Viewpoint(この記事)に書かれている論点は、チームが学んだこと、
そして他がどう変わるべきと信じているか、について反映させるために書かれている。
dbtは、私たちが観察したワークフローの課題に対処するための私たちの試みであり、
(この資料に書いた)論点は、dbtプロジェクトのゴールを示す最も基本的な記述である。
今日のAnalytics
真の成熟した分析組織においては、プロプライエタリソフトウエアが過去のものとなり、
データ統合を行うコードとツール、ハイパフォーマンス分析データベース、SQL/R/Python、
可視化ツール、を組み合わせてソリューションを組む流れに進んでいる。
この変化により、重要な可能性を見出せるようになったが、分析チームは依然として、
引き続き、高品質、低遅延に対する高い目標に対峙しないといけない。
我々は分析チームはワークフローに関する問題を抱えていると信じている。
分析者はしばしば離れた環境で操作を行い、結果として部分的な最適化を生み出している。
結果、ナレッジはサイロ化されてしまう。同僚が既にどこかで書いたコードを再生産したりしている。
あまり馴染みのないデータのニュアンスを掴めない。
洗練されたチームであっても解決できないことを何百回も聴き、概して現状維持だと認識している。
組織の決定のスピードと品質は上がらない。
分析はこのようである必要はない(?)。実際、これらの問題についてソフトウエア開発チームが
既に解決している。ソフトウエアエンジニアが早く高品質で成果物を生産するために行なっている
多人数共同開発と同じテクニックを分析にも適用できる。
Analyticsは共同作業的
成熟した分析チームが持つべきテクニックやワークフローはソフトウエア開発に見られる以下の
共同作業的な特徴を持つべき。
バージョンコントロール
分析を行うコードは、それがPythonなのか、SQLなのか、Javaなのかそれ以外なのかによらず、
バージョンコントロールされるべきだ。分析はデータとビジネスが変化していく中で、
誰が何をいつ変更したのかを知ることが重要になる。
品質保証
悪いデータは悪い分析につながる。そして悪い分析は悪い決定につながる。
データや分析結果を作り出すコードはレビューされ、テストされるべきだ。
Bad data can lead to bad analyses, and bad analyses can lead to bad decisions.
Any code that generates data or analysis should be reviewed and tested.
ドキュメンテーション
あなたが書いた分析はソフトウエアアプリケーションである。他のソフトウエアアプリケーションと同様に
他の誰かが「それをどのように使うのか」疑問を抱く。これは簡単に見えるかもしれないが、
(例えば?)”収益線”に様々な意味がある可能性があるように、そう簡単ではない。
コードには、それがどのように解釈されるべきか、基本的な記述を付与すべきだ。
また、疑問が生まれる度に、チームメンバが既存のドキュメントに追加するべきだ。
モジュール性(Modularity)
もしあなたが、あなたやあなたの同僚が会社の収益について一連の分析を行うのであれば、
あなたがたは同じ入力データを使うべきだ。「コピペ」は良い方法ではない。
背後にあるデータが変化したとして、そのデータが使われる全ての箇所を変更しないといけない。
代わりに、パブリックなインターフェースとしてデータのスキーマを考慮すべきだ。
一貫性のあるスキーマを公開して、ビジネスロジックが変更されたときに一緒に変更できるような
テーブル、ビュー、や他のデータセットを作ること。
Analyticsのコードはアセットである
その分析を得るために要したコード、プロセス、ツールは組織が行った中心的な投資である。
成熟した分析組織のワークフローは次に示す特徴を備えるべきで、それにより組織の投資を
守って育てるべきだ。(so as to を意訳した)
環境
Analyticsは複数の環境を必要とする。分析者はユーザに影響を与えずに作業する自由を必要とするが、
一方で、ユーザは彼らの普段の仕事を行うため、依存するデータを信頼できるようにサービスレベルの
保証を必要とする。
サービスレベルの保証
分析チームは本番環境に投入された全ての分析の精度に責任をもつ必要がある。(stand behind.)
エラーは本番環境におけるバグと同じレベルの緊急性をもって扱われるべきだ。
本番環境から不要になった全てのコードは非推奨となるプロセスで扱われるべきだ。
保守性を考慮した設計
ソフトウエア開発における大半のコストは保守フェーズに発生する。
このため、ソフトウエアエンジニアは保守性の観点を持ってコードを記述する。
しかしながら、分析コードはしばしば(ソフトウエア開発のものより)扱いづらいものである。
背後にあるデータの変化により、予測し修正することが難しい形で大半の分析コードは壊れてしまう。
分析コードは保守性の観点をもって書かれるべきだ。スキーマとデータに対する将来の変化を予測し、
対応する影響を最小限に抑えるためにコードを書くべきだ。
分析ワークフローは自動化ツールを必要としている
しばしば、多くの分析のためのワークフローは手作業で行われる。
分析者は、sourceからdestinationへ、stageからstageへの移送手段構築にほとんどの時間を使う。
ソフトウエアエンジニアは彼らの仕事で起こる手作業の部分の広範囲をカバーするツールを構築しているう。
私たちが推測している分析用途のワークフローを実装するために、似たようなツールが必要となるだろう。
以下は自動化されたワークフローの一例。
このようなワークフローは単一のコマンドで実行できるように構築されるべき。
- modelと分析は複数のソース管理リポジトリからダウンロードされる
- コードは与えられた環境に適合して構成される
- コードはテストされる、そして
- コードはデプロイされる
まとめ
The dbt Viewpointを読んで訳してみた。
アプリフレームワークで開発経験があると、かなり似た雰囲気を感じるツールなのだが、
どうやら本当にアプリ開発の分野にインスパイアされたツールだったということがわかった。