2010-06-19 14 views
8

Tengo un problema de gestión de datos científicos que parece general, pero no puedo encontrar una solución existente o incluso una descripción de la misma, que hace mucho tiempo me desconcertó. Estoy a punto de embarcarme en una importante reescritura (Python), pero pensé en lanzar una última vez para las soluciones existentes, así puedo descartar la mía y volver a la biología, o al menos aprender un lenguaje apropiado para mejorar la búsqueda de Google. .soluciones python para gestionar el gráfico de dependencia de datos científicos por valores de especificación

Problema: Tengo atributos de datos caros (de horas a días para calcular) y grandes (GB) que normalmente se crean como transformaciones de uno o más atributos de datos. Necesito hacer un seguimiento exacto de cómo se construyen estos datos para poder reutilizarlos como entrada para otra transformación si se ajusta al problema (construido con los valores de especificación correctos) o para construir nuevos datos según sea necesario. Aunque no debería importar, normalmente empiezo con información de biología molecular algo heterogénea de 'valor agregado', por ejemplo, genomas con genes y proteínas anotados por otros procesos por otros investigadores. Necesito combinar y comparar estos datos para hacer mis propias inferencias. A menudo se requieren varios pasos intermedios, y estos pueden ser costosos. Además, los resultados finales pueden convertirse en la entrada para transformaciones adicionales. Todas estas transformaciones se pueden realizar de múltiples maneras: restringir con diferentes datos iniciales (por ejemplo, usar diferentes organismos), usar diferentes valores de parámetros en las mismas inferencias, o usar diferentes modelos de inferencia, etc. Los análisis cambian frecuentemente y se basan en otros de formas no planificadas. Necesito saber qué datos tengo (qué parámetros o especificaciones lo definen completamente), ambos para poder reutilizarlos si corresponde, así como para la integridad científica general.

Mis esfuerzos en general: Diseño mis clases de python con el problema de la descripción en mente. Todos los atributos de datos construidos por un objeto de clase se describen mediante un único conjunto de valores de parámetros. Llamo a estos parámetros o especificaciones definitorias el 'def_specs', y estos def_specs con sus valores la 'forma' de los datos atts. El estado de parámetros global completo para el proceso puede ser bastante grande (por ejemplo, un centenar de parámetros), pero los datos de atts proporcionados por cualquier clase requieren solo un pequeño número de estos, al menos directamente. El objetivo es verificar si los datos de configuración anteriores son apropiados probando si su forma es un subconjunto del estado de parámetro global.

Dentro de una clase es fácil encontrar las def_specs necesarias que definen la forma mediante el examen del código. El problema surge cuando un módulo necesita datos de otro módulo. Estos datos tendrán su propia forma, tal vez pasados ​​como argumentos por el objeto llamante, pero más frecuentemente filtrados del estado de parámetro global. La clase de llamada se debe aumentar con la forma de sus dependencias para mantener una descripción completa de sus datos. En teoría, esto podría hacerse manualmente examinando el gráfico de dependencia, pero este gráfico puede ser profundo, y hay muchos módulos, que estoy constantemente cambiando y agregando, y ... Soy demasiado flojo y descuidado para hacerlo. mano.

Por lo tanto, el programa descubre dinámicamente la forma completa de los datos atts mediante el seguimiento de llamadas a los atributos de otras clases y devolviendo su forma a la (s) llamada (s) mediante una pila administrada de llamadas __get__. Mientras reescribo, encuentro que necesito controlar estrictamente el acceso de atributos a mis clases de compilador para evitar que la información arbitraria influya en los datos. Afortunadamente, Python lo está haciendo fácil con descriptores.

Guardo la forma de los datos atts en un db para que pueda consultar si ya existen los datos apropiados (es decir, su forma es un subconjunto del estado del parámetro actual). En mi reescritura me estoy moviendo de mysql a través de la gran SQLAlchemy a un objeto db (ZODB o couchdb?) Como la tabla para cada clase tiene que ser alterada cuando se descubren def_specs adicionales, lo cual es un problema, y ​​porque algunas de las def_specs son listas o dictados de pitón, que son un dolor de traducir a sql.

No creo que esta gestión de datos pueda separarse de mi código de transformación de datos debido a la necesidad de un estricto control de atributos, aunque intento hacerlo todo lo posible. Puedo usar las clases existentes envolviéndolas con una clase que proporcione sus def_specs como atributos de clase, y administración de db a través de descriptores, pero estas clases son terminales en el sentido de que no se puede descubrir más la forma de dependencia adicional.

Si la gestión de datos no puede separarse fácilmente de la construcción de datos, supongo que es poco probable que exista una solución lista para usar, sino mil soluciones específicas. Tal vez hay un patrón aplicable? Agradecería cualquier sugerencia sobre cómo buscar o describir mejor el problema. Para mí, parece un problema general, aunque manejar datos profundamente en capas es tal vez en desacuerdo con los vientos dominantes de la web.

+0

Su descripción de los requisitos para los atributos de datos me recuerda vagamente las diapositivas "Trees!", "Structural Sharing" de http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey de Rich Hickey (Clojure) 0:41:10 – jfs

+0

Gracias por la sugerencia: parece profunda, así que tendré que dedicarle algo de tiempo. – ricopan

+0

Ok observé la conversación y asimilé bastante de una manera general. Nunca había pensado en el tiempo explícitamente. Viniendo de mi problema específico, he visto la necesidad de hacer que mis objetos actúen más como funciones que proporcionan objetos inmutables como la única manera de garantizar la integridad de los datos con 'formas' conocidas. Solo había pensado en la concurrencia un poco, pero reforzaba la idea de que mis clases esencialmente tenían que actuar como funciones y tener un estricto control de atributos. Gracias de nuevo. Tengo que apegarme a lo práctico, pero eso me da algunas ideas y terminología para usar, y un poco de fe. – ricopan

Respuesta

2

no tengo sugerencias específicas relacionadas con Python para usted, pero aquí están algunas ideas:

Usted está encontrando un desafío común en bioinformática. Los datos son grandes, heterogéneos y vienen en formatos en constante cambio a medida que se introducen nuevas tecnologías. Mi consejo es no pensar demasiado en sus oleoductos, ya que es probable que cambien mañana. Elija unos pocos formatos de archivo bien definidos, y dé masajes a los datos entrantes en esos formatos con la mayor frecuencia posible. En mi experiencia, generalmente también es mejor tener herramientas débilmente acopladas que hacen una cosa bien, para que puedas encadenarlas para diferentes análisis rápidamente.

También puede considerar la adopción de una versión de esta pregunta a la bioinformática pila de cambio en http://biostar.stackexchange.com/

+0

Gracias, hurgaré en biostar. Este es un problema diferente al tratar con los datos primarios, que puede ser difícil de analizar y verificar. La información primaria es barata (para mí). Se vuelve costoso cuando lo marco con más inferencias, por ejemplo, asigna familias de proteínas mediante inferencias filogenéticas con parámetros siempre algo arbitrarios, crea perfiles discretos de coocurrencia, encuentra relaciones de contexto genómico, infiere procesos biológicos, se combina con la ubicación celular ... etc. todas esas cosas necesarias para llegar a resultados reales (cada transformación podría ser un método publicado) ... Entonces es costoso. – ricopan

2

ZODB no ha sido diseñado para manejar datos masivos, es sólo para aplicaciones basadas en la Web y, en cualquier caso, es una base de datos basada en archivos planos.

Te recomiendo que pruebes PyTables, una biblioteca de python para manejar archivos HDF5, que es un formato utilizado en astronomía y física para almacenar resultados de grandes cálculos y simulaciones. Se puede utilizar como una base de datos jerárquica y también tiene una forma eficiente de extraer objetos de Python. Por cierto, el autor de Pytables explicó que ZOdb was too slow por lo que tenía que hacer, y puedo confirmarlo. Si está interesado en HDF5, también hay otra biblioteca, h5py.

Como herramienta para gestionar el control de versiones de los diferentes cálculos que tiene, puede intentarlo en sumatra, que es algo así como una extensión de git/trac pero diseñado para simulaciones.

Debe hacer esta pregunta en biostar, allí encontrará mejores respuestas.

+0

Gracias por los pensamientos. Es realmente la "forma" de los datos (metadatos que lo definen) que estoy considerando NOsql, no los datos construidos por ellos mismos, aunque sería conveniente almacenarlos al costado. Uso pytables para almacenar mis datos de vez en cuando, con resultados decentes, aunque por lo general son solo matrices numpy archivadas. – ricopan

+0

Gracias por la información sobre sumatra. Esa parece una gran herramienta que seguiré de cerca. A primera vista, no parece que se ajuste a mi problema: no quiero almacenar cada dato att con todos los parámetros (muchos), sino solo aquellos que los definen. De lo contrario, si hago un análisis posterior con un parámetro impertinente cambiado, los datos relevantes no se ven como tales. Entonces, el problema es definir qué parámetros definen dinámicamente cada dato de datos, lo cual no creo que lidie con sumatra. Sin embargo, tal vez sería un buen almacenamiento de back-end para los metadatos, una vez determinado, especialmente si es indexable. – ricopan

Cuestiones relacionadas