私は一般的な科学データ管理の問題を抱えていますが、既存の解決策やその説明さえも見つけることができず、長い間頭を悩ませてきました。私は大規模な書き直し（python）に着手しようとしていますが、既存のソリューションに最後にもう一度キャストすると思ったので、自分自身を破棄して生物学に戻るか、少なくとも適切な言語を学んでグーグルを改善することができます.
問題: 通常、1 つまたは複数の他のデータ属性の変換として構築される、高価な (計算に数時間から数日かかる) 大きな (GB の) データ属性があります。このデータがどのように構築されたかを正確に追跡する必要があるため、問題に適合する場合 (正しい仕様値で構築された場合) に別の変換の入力として再利用したり、必要に応じて新しいデータを構築したりできます。それは問題ではありませんが、私は通常、「付加価値のある」やや異種の分子生物学情報から始めます。たとえば、他の研究者による他のプロセスによって注釈が付けられた遺伝子とタンパク質を含むゲノムです。これらのデータを組み合わせて比較し、独自の推論を行う必要があります。多くの場合、多くの中間ステップが必要であり、これらは費用がかかる可能性があります。さらに、最終結果は、追加の変換の入力になる可能性があります。これらの変換はすべて複数の方法で行うことができます。たとえば、異なる初期データで制限する (たとえば、異なる生物を使用する)、同じ推論で異なるパラメーター値を使用する、または異なる推論モデルを使用するなどです。分析は頻繁に変更され、他のものに基づいて構築されます。計画外の方法で。自分が持っているデータ (それを完全に定義するパラメータまたは仕様) を知る必要があるため、必要に応じてデータを再利用したり、一般的な科学的整合性を保つことができます。
一般的な私の取り組み: 記述の問題を念頭に置いて Python クラスを設計しています。クラス オブジェクトによって作成されたすべてのデータ属性は、1 つのパラメータ値のセットによって記述されます。これらの定義パラメータまたは仕様を「def_specs」と呼び、値を持つこれらの def_specs をデータ属性の「形状」と呼びます。プロセスの全体的なグローバル パラメータ状態は非常に大きくなる可能性があります (たとえば、100 個のパラメータ) が、いずれかのクラスによって提供されるデータ属性は、少なくとも直接的には少数のこれらの属性のみを必要とします。目標は、形状がグローバル パラメータ状態のサブセットであるかどうかをテストすることにより、以前に構築されたデータ属性が適切かどうかを確認することです。
クラス内では、コードを調べることで形状を定義する必要な def_specs を簡単に見つけることができます。モジュールが別のモジュールからのデータ属性を必要とする場合、摩擦が発生します。これらのデータ属性には独自の形状があり、おそらく呼び出し元のオブジェクトによって引数として渡されますが、グローバル パラメーターの状態からフィルター処理されることがよくあります。呼び出しクラスは、そのデータ属性の完全な記述を維持するために、その依存関係の形で拡張する必要があります。理論的には、これは依存関係グラフを調べることで手動で行うことができますが、このグラフは深くなる可能性があり、多くのモジュールがあり、常に変更および追加しています...手動で行うには怠惰で不注意です.
そのため、プログラムは、他のクラス属性への呼び出しを追跡し、管理された呼び出しスタックを介してその形状を呼び出し元にプッシュすることにより、データ属性の完全な形状を動的に検出し__get__ます。書き直していくと、ビルダー クラスへの属性アクセスを厳密に制御して、任意の情報がデータ属性に影響を与えないようにする必要があることがわかりました。幸いなことに、Python は記述子を使用してこれを容易にしています。
データ属性の形状を db に保存して、適切なデータ (つまり、その形状が現在のパラメーター状態のサブセット) が既に存在するかどうかを照会できるようにします。私の書き直しでは、偉大な SQLAlchemy を介して mysql からオブジェクト db (ZODB またはカウチデータベース?) に移行しています。これは、追加の def_spec が発見されたときに各クラスのテーブルを変更する必要があるためです。これは苦痛であり、一部の def_spec はPython のリストまたは辞書。これは SQL に変換するのが面倒です。
可能な限りそうしようとはしていますが、厳密な属性制御が必要なため、このデータ管理をデータ変換コードから切り離すことはできないと思います。def_specs をクラス属性として提供するクラスで既存のクラスをラップし、記述子を介してデータベースを管理することで、既存のクラスを使用できますが、これらのクラスは、追加の依存関係の形状をそれ以上検出できないという点で、最終的なものです。
データ管理をデータ構築から簡単に切り離すことができない場合、すぐに使用できるソリューションはなく、特定のソリューションは数千あるとは考えにくいと思います。該当するパターンがあるのではないでしょうか？問題を調べたり、よりよく説明したりする方法についてのヒントをいただければ幸いです。私には一般的な問題のように思えますが、深く階層化されたデータを管理することは、おそらく Web の一般的な風向きとは相容れないものです。