我有一个看起来很笼统的科学数据管理问题,但我找不到现有的解决方案,甚至找不到它的描述,这让我很困惑。我即将开始一次重大的重写(python),但我想我会为现有的解决方案投最后一次,所以我可以放弃自己的并回到生物学,或者至少学习一些合适的语言以便更好地进行谷歌搜索.
问题:我有昂贵的(数小时到数天来计算)和大(GB)的数据属性,这些属性通常是作为一个或多个其他数据属性的转换而构建的。我需要准确跟踪这些数据是如何构建的,这样如果它适合问题(使用正确的规范值构建)或根据需要构建新数据,我就可以将其用作另一个转换的输入。尽管这无关紧要,但我通常会从“增值”的有点异质的分子生物学信息开始,例如,基因组中的基因和蛋白质由其他研究人员的其他过程注释。我需要结合和比较这些数据来做出自己的推论。通常需要许多中间步骤,而且这些步骤可能很昂贵。此外,最终结果可以成为其他转换的输入。所有这些转换都可以通过多种方式完成:使用不同的初始数据(例如使用不同的生物体)进行限制,在相同的推理中使用不同的参数值,或者使用不同的推理模型等。分析经常变化并建立在其他分析之上以计划外的方式。我需要知道我拥有哪些数据(哪些参数或规范完全定义了它),这样我才能在适当的时候重复使用它,以及为了一般的科学完整性。
我的总体努力:我在设计我的 python 类时考虑到了描述问题。类对象构建的所有数据属性都由一组参数值描述。我将这些定义参数或规范称为“def_specs”,这些 def_specs 及其值称为数据 atts 的“形状”。进程的整个全局参数状态可能非常大(例如一百个参数),但任何一个类提供的数据 atts 只需要其中的一小部分,至少直接需要。目标是通过测试它们的形状是否是全局参数状态的子集来检查先前构建的数据 atts 是否合适。
在一个类中,通过检查代码很容易找到定义形状所需的 def_specs。当一个模块需要来自另一个模块的数据时,就会出现问题。这些数据 atts 将有自己的形状,可能由调用对象作为 args 传递,但更多时候是从全局参数状态中过滤出来的。调用类应该增加其依赖的形状,以维护其数据属性的完整描述。理论上这可以通过检查依赖图来手动完成,但是这个图可能会变得很深,并且有很多模块,我会不断地更改和添加,而且......我太懒了,也太粗心了,无法手动完成.
因此,程序通过跟踪对其他类属性的调用并通过托管的调用堆栈将它们的形状推回调用者来动态发现数据 atts 的完整形状__get__
。当我重写时,我发现我需要严格控制对构建器类的属性访问,以防止任意信息影响数据 atts。幸运的是,python 使用描述符使这变得容易。
我将数据 atts 的形状存储在数据库中,以便我可以查询是否已经存在适当的数据(即其形状是当前参数状态的子集)。在我的重写中,我通过出色的 SQLAlchemy 从 mysql 转移到对象 db(ZODB 或 couchdb?),因为当发现额外的 def_specs 时,必须更改每个类的表,这很痛苦,因为一些 def_specs 是python 列表或字典,很难翻译成 sql。
由于需要严格的属性控制,我不认为这种数据管理可以与我的数据转换代码分开,尽管我正在尽可能地这样做。我可以使用现有的类,用一个类包装它们,该类提供它们的 def_specs 作为类属性,并通过描述符进行数据库管理,但是这些类是终端的,因为无法进一步发现额外的依赖形状。
如果数据管理不能轻易地与数据构建分开,我想不可能有一个开箱即用的解决方案,而是一千个特定的解决方案。也许有一个适用的模式?我会很感激任何关于如何去寻找或更好地描述问题的提示。对我来说,这似乎是一个普遍的问题,尽管管理深度分层的数据可能与网络的盛行不符。