Diría que depende principalmente de la naturaleza de los datos, así como del tipo de consultas que intenta ejecutar con más frecuencia. Finalmente, como dijo Sean, terminarás teniendo que leer los datos del disco de todos modos, a menos que seas lo suficientemente rico como para vivir en la memoria. Y antes de comenzar a responder por lo que he visto a mi alrededor, los archivos planos son la solución más común con diferencia.
Permíteme darte dos ejemplos concretos que enfrenté este verano, para los cuales terminé con dos soluciones diferentes:
- RDBMS para datos MOOC como edX o Coursera
- limas planas para almacenar formas de onda para la presión arterial de pacientes en UCI
Ejemplo 1: manejo de datos MOOC.
- ¿Cuáles son los límites del aprendizaje automático? ¿Cuándo puede estar seguro de que un algoritmo ML no podrá darle un resultado satisfactorio?
- ¿Cómo podemos usar Tensorflow para problemas de clasificación?
- En el autoencoder variacional, ¿por qué solo tomamos muestras de variables latentes de un gaussiano estándar y aplicamos el decodificador para generar nuevos datos en las pruebas?
- Cómo dominar el aprendizaje automático en el menor tiempo posible
- ¿Cuál es la mejor biblioteca de aprendizaje profundo en la etapa actual para trabajar en grandes datos? ¿Cuáles son algunas alternativas para las bibliotecas a gran escala?
Recibí los datos de un montón de cursos de edX, básicamente todo lo que se registró en las actividades de los estudiantes: qué páginas visitaron, qué enviaron, el foro, etc. En general, el tamaño de los datos no era tan grande: alrededor de 50 GB por curso en el formato sin formato que recibí.
Además de la multiplicidad de datos, teníamos la intención de ejecutar grandes cantidades de consultas diferentes para investigar muchos aspectos del curso a partir de estadísticas descriptivas misceláneas (por ejemplo, cursos en línea abiertos masivos (MOOC): ¿Dónde puedo encontrar datos y estadísticas? en los MOOC?) para el aprendizaje automático y la investigación educativa, como predecir abandonos y qué recursos son útiles para responder a un problema dado.
Como resultado, pensamos que usar un DBMS sería útil para lograr esas tareas de manera eficiente. Estábamos más motivados ya que estábamos viendo algunos otros laboratorios que tenían dificultades para manejar CSV en todo el lugar. Además, la tabla más grande se ajustaba en RAM, por lo que no tuvimos ningún problema de E / S.
Aquí hay un ejemplo de una consulta que necesitábamos responder: 
Como puede ver, responder una pregunta simple fue una molestia al usar archivos planos (los cuadros azul grisáceos en esta diapositiva), pero podría ocuparse de usar una sola consulta SQL una vez que cambiamos a DBMS (vicelet MySQL)
(más detalles sobre este trabajo aquí si está interesado: http://francky.me/publications.p…)
Ejemplo 2: tratar con datos de la UCI.
En este proyecto, los datos fueron mucho más simples ya que nos centramos en un conjunto de datos de forma de onda del paciente en la UCI. Eran solo las 22 formas de onda diferentes.
Aquí estaba la motivación (la copié de un documento que mi laboratorio y acabo de enviar)
Para los estudios de forma de onda fisiológica típicos, los investigadores definen un grupo de estudio dentro del cual designan casos y controles. Extraen las formas de onda del grupo, filtran las señales, las procesan previamente y extraen las características antes de ejecutar, evaluar e interpretar iterativamente una máquina preseleccionada.
algoritmo de aprendizaje con métricas como el área bajo la curva y análisis como la sensibilidad variable.Reconociendo que un estudio típico, incluso con cantidades modestas de pacientes, puede tomar de 6 a 12 meses, hemos preguntado cómo se puede reducir esta duración y múltiples estudios pueden compartir el esfuerzo de desarrollo. En respuesta, estamos diseñando un marco de análisis y aprendizaje automático a gran escala, llamado beatDB, para extraer conocimiento de formas de onda fisiológicas de alta resolución. beatDB es nuestro primer corte para crear repositorios de datos de nivel de función muy grandes y de acceso abierto derivados de formas de onda de señal fisiológica periódicas continuas, como electrocardiogramas (ECG) o presión arterial. En la actualidad, hemos procesado cerca de mil millones de latidos de la presión arterial de la base de datos de formas de onda MIMIC 2 versión 3 y hemos desarrollado una estrategia para la extracción y descubrimiento de características que respalda estudios eficientes.
Por lo tanto, beatDB reduce drásticamente el tiempo de las investigaciones a gran escala precalculando juiciosamente las características de ritmo que probablemente se utilizarán con frecuencia. Es compatible con la investigación ágil al ofrecer parametrizaciones que permiten que se tomen decisiones específicas de intercambio de cómputo y almacenamiento de tareas al calcular características adicionales y preparar datos para aprendizaje automático o visualización.
Resumir la estructura de datos es sencillo: tenemos algunas formas de onda y características que calculamos en ellas para facilitar el aprendizaje automático.
Además de la simplicidad de los datos, las consultas que pretendemos ejecutar son siempre las mismas: tome estas características o estas formas de onda para estos pacientes. Eso es.
Importar los datos a algunos DBMS no sería tan útil. De hecho, incluso sería una carga recuperar los datos, ya que el tamaño era bastante grande (más de 1 TB) y podría crecer a medida que agregamos más funciones.
Entonces, en este segundo caso, decidimos usar archivos planos, con algunas carpetas para agrupar por pacientes / características.
Pero ahora estamos pensando en incorporar datos de pacientes más complejos, como los datos demográficos o lo que les sucede durante la estadía en la UCI, y nos gustaría ver cómo se comportan sus formas de onda dependiendo de las condiciones. A medida que los datos nos hemos vuelto más complejos, estamos considerando un formato más estructurado.
