Advertencia: uso severo de siglas.
Esta es una pregunta difícil. Hay tanta historia y experiencia (> 20 años, incontables millones de horas de mano de obra) detrás del almacenamiento de datos. Primero, cuando se trata de computación grid en CERN y LHC, todos los recursos se recopilan en una ubicación unificadora [1].
A continuación, hay muchos experimentos en el CERN:
- ¿Hay algún autómata celular bien conocido e interesante?
- ¿Cuáles son los diferentes niveles de RAID?
- ¿Cuál es la diferencia entre base de datos paralela y mapreduce?
- ¿Cuáles son los sitios web y las redes sociales más influyentes sobre el calentamiento global y los asuntos climáticos?
- Ciencias de la computación: me gustaría crear una base de datos en un servidor y luego buscar en mi programa conjuntos de datos específicos. ¿Es posible hacer algo con Qt o tengo que usar un SDK diferente?
- ATLAS (trabajo con esto)
- ALICIA
- CMS
- LHCb
y cada experimento hace algo diferente. Debido a la gran cantidad de información y a no tratar de explicarlos a todos, solo hablaré sobre ATLAS ( A Large T oroidal L HC A pparatu s ).
En la ejecución 1, de 2008 a 2013, ATLAS tenía un modelo informático que estaba en el nivel superior, congelado. Esto significaba, en gran parte, que el formato de datos se decidió con anticipación y se “congeló” en su lugar, por lo que incluso si se iban a realizar cambios, esto solo sucedería después de la puesta en servicio y las actualizaciones de la Fase 0 [2]. Este tipo de datos de salida del detector no se puede leer en ROOT, por lo que las personas dedican una gran cantidad de tiempo a traducir los datos en algo que sea ROOT-legible.
que ahora se reemplaza con el nuevo modelo de análisis que permite conjuntos de datos re-derivados, re-desnatados, re-adelgazados, re-adelgazados, re-reducidos en casi tiempo real, incluso cuando los conjuntos de datos están en el orden de petabytes y terabytes ! 
Y hay un AOD2AOD en la parte inferior izquierda de la figura, lo que significa que los conjuntos de datos que hemos reconstruido desde el nivel superior se pueden volver a ejecutar con las calibraciones de actualización, la sistemática y las técnicas de reconstrucción mejoradas periódicamente durante el operador de El detector LHC.
Entonces, ¿qué tipo de datos están realmente involucrados / almacenados en primer lugar?
que es una cantidad significativa La mayoría de los físicos en Run-1 se ocupó de NTUPL y DPD: estos son sus archivos ROOT estándar con TTrees y TBranches y TLeaves (los trataré más adelante). Ahora, cuando nos preparemos para Run-2, trabajaremos principalmente en DxAOD que se derivan (gigabytes de tamaño) de AOD (terabytes de tamaño) formados a partir de AOD de nivel 0 (petabytes de tamaño). Aquí hay una imagen que destaca el proceso general
¿Qué es el nivel 0 entonces? Sitios de computación?
Bueno, el Nivel 0 se refiere a la instalación en el CERN que tenía la función principal de interactuar directamente con los datos RAW del detector, así como el archivo de los datos en cintas magnéticas.
La cuadrícula LHC está organizada en niveles. El Nivel 0 se encuentra en el CERN y consiste en gran parte de miles de servidores comprados comercialmente, tanto cajas de estilo PC como, más recientemente, sistemas blade que parecen cajas de pizza negras, apiladas en fila tras fila de estantes. Las computadoras aún se están comprando y agregando al sistema. Los datos pasados al Nivel 0 por los sistemas de adquisición de datos LHC se archivarán en cinta magnética.
El Nivel 0 distribuirá los datos a los 12 centros del Nivel 1, ubicados en el CERN y en otros 11 institutos importantes de todo el mundo. Por lo tanto, los datos no procesados existirán en dos copias, una en el CERN y otra dividida en todo el mundo. Cada uno de los centros de Nivel 1 también albergará un conjunto completo de datos en una forma compacta estructurada para que los físicos realicen muchos de sus análisis.
El LHC Computing Grid completo también tiene centros de Nivel 2, que son centros de computación más pequeños en universidades e institutos de investigación. Las computadoras en estos centros suministrarán potencia de procesamiento distribuida a toda la red para el análisis de datos. [4]
La red mundial de computación LHC (WLCG) se compone de cuatro niveles, o “niveles”, llamados 0, 1, 2 y 3. Cada nivel está compuesto por varios centros de computación y proporciona un conjunto específico de servicios. Entre ellos, los niveles procesan, almacenan y analizan todos los datos del Gran Colisionador de Hadrones (LHC).
El nivel 0 es el Centro de datos del CERN. Todos los datos del LHC pasan a través de este concentrador central, pero proporcionan menos del 20% de la capacidad informática total de la red. El CERN es responsable del mantenimiento seguro de los datos sin procesar (millones de lecturas digitales de los detectores), y realiza el primer paso para reconstruir los datos sin procesar en información significativa. El Nivel 0 distribuye los datos sin procesar y la salida reconstruida al Nivel 1, y vuelve a procesar los datos cuando el LHC no se está ejecutando.
El Nivel 1 consta de 13 centros informáticos (tabla 1) lo suficientemente grandes como para almacenar datos LHC. Proporcionan soporte las 24 horas para la cuadrícula y son responsables de almacenar una parte proporcional de datos en bruto y reconstruidos, así como de realizar un reprocesamiento a gran escala y almacenar la salida correspondiente; distribuir datos a los niveles 2; y almacenar una parte de los datos simulados que producen los Tier 2. Los enlaces de fibra óptica que funcionan a 10 gigabits por segundo conectan el CERN a cada uno de los 13 principales centros Tier 1 de todo el mundo. Esta red dedicada de gran ancho de banda se llama Red privada óptica LHC (LHCOPN).
¿Por qué el tamaño de los datos es tan grande?
Cuando el LHC esté operativo para la ejecución 2, desde principios de 2015 hasta 2018, procesará eventos a una velocidad de 40 MHz (Megahercios). En otras palabras, 40 millones de eventos por segundo. Este es un asombroso 25 nanosegundos entre colisiones a un nivel de energía sin precedentes. La regla general sobre el tamaño de los datos por evento es
[matemáticas] 1 \ text {evento} \ aprox 1 \ text {MB} [/ matemáticas] [7]
que son 40 terabytes por segundo de datos entrantes. PER. SEGUNDO. Esta es mucha información, y llenaríamos un solo petabyte en aproximadamente medio minuto. Es imposible para nosotros registrar toda esa información. Por lo tanto, debemos filtrar los eventos a la misma velocidad a la que entran. Aquí es donde entran los niveles. Hice la siguiente caricatura para resaltar el sistema general resumido del Informe de datos técnicos de nivel 1 (L1TDR) [6]. 
Para aclarar esto, imagine que el agua fluye a través del sistema de arriba a abajo. Los círculos rojos (Central Trigger Processor, CTP) pueden abrir las tuberías al siguiente nivel (del nivel 1 al nivel 2, y del nivel 2 a las cintas magnéticas en el Nivel-0 para la grabación). El objetivo es desencadenar eventos que consideramos interesantes, pero desencadenar lo suficientemente rápido como para que no tengamos un retraso. El nivel 1 es básicamente nuestra primera línea de defensa. Uno de mis proyectos de investigación está en el desarrollo de hardware para este nivel para Run 3 (2018+). Entonces, el Nivel 1 es increíblemente crudo e increíblemente rápido. Tiene múltiples componentes que analizan varias partes del evento en paralelo (a través de la multiplexación de datos). Hay muchos buffers, tuberías, discos de lectura, etc., todos nos ayudan a mover toda esta información a través de la tubería. 
Esta es una descripción esquemática de lo que se adjunta al primer punto rojo para el disparador de Nivel 1. El CTP en la parte inferior es ese punto rojo en la imagen anterior que te he mostrado. El calorímetro de nivel 1 obtiene datos de los calorímetros de argón líquido y mosaico del detector, y realiza un procesamiento específico, como calcular la cantidad de energía en varias regiones utilizando un algoritmo de ventana deslizante, o haciendo un algoritmo de agrupamiento muy crudo para identificar regiones de mayor densidad de energía. El trabajo del CTP es tomar la información del Calorímetro, de los Muones, y combinarla en una Aceptación Global de Nivel 1 (L1A) que determina si el evento que mira actualmente va al Nivel 2 o si simplemente lanzamos lejos porque no es lo suficientemente interesante.
El objetivo final es filtrar 40 millones de eventos por segundo a 1000 eventos por segundo, que se pueden grabar en cinta magnética.
Entonces, ¿qué son los archivos ROOT? [8]
Bueno, los archivos ROOT son … más o menos … bases de datos binarias. Contienen información sobre sí mismo ( descripción ), así como los datos sin procesar ( datos ). Todo lo que hay dentro de un archivo ROOT es binario por varias razones informáticas en las que preferiría no entrar. Debido a esto, un programa que entiende cómo leer un archivo ROOT sabe que todo lo que necesita hacer es abrirlo y leer la descripción para comprender lo suficiente sobre él. Esto significa que podemos abrir y leer archivos ROOT en O (1) tiempo, ya que no importa cuán grande o pequeño sea el archivo, solo lee en una cierta cantidad de bytes para comprender la estructura del archivo que le ha dado. , y luego contiene punteros a más información si la solicita. Un archivo ROOT es como una base de datos y contiene muchos TDirectorios y TTrees. Un TTree es como una tabla de base de datos. Un TDirectory es como una colección de tablas de bases de datos. Un TTree puede tener TBranches / TLeaves que son como columnas. Y las filas son los eventos. Aquí hay un ejemplo de código para ilustrar alguna estructura básica:
[correo electrónico protegido] : ~ / faxbox / LArStudies $ root -b -l PileupSkim_Pythia8_AU2CT10_jetjet_JZ0W_0.root
raíz [0]
Adjuntando el archivo PileupSkim_Pythia8_AU2CT10_jetjet_JZ0W_0.root como _file0 …
raíz [1] .ls
TFile ** PileupSkim_Pythia8_AU2CT10_jetjet_JZ0W_0.root
TFile * PileupSkim_Pythia8_AU2CT10_jetjet_JZ0W_0.root
CLAVE: TTree mytree; 1 mytree
root [2] mytree-> ls ()
OBJ: TTree mytree mytree: 0 en: 0x1dc2430
raíz [3] mytree
(clase TTree *) 0x1dc2430
Observe cómo me dice que TTree mytree está ubicado en la memoria en 0x1dc2430 . ROOT entiende cómo encontrar cosas porque es como un cartero con la dirección postal de alguien. En lugar de darle al cartero toda mi casa, que es bastante difícil de transportar, solo le doy mi dirección y él sabe dónde encontrar mi casa cuando la necesita.
Ahora, ¿qué hay dentro del TTree? Bueno, ramas, muchas columnas de datos. Podemos obtener un adelanto de esto de varias maneras
root [4] mytree-> GetListOfBranches ()
(clase TObjArray *) 0x1dc2580
root [5] mytree-> GetListOfBranches () -> GetEntries ()
(const Int_t) 1050
lo que me dice que hay 1.050 columnas en mi tabla de base de datos. ¿Cuál es uno de ellos?
root [6] mytree-> GetListOfBranches () -> At (0)
(const clase TObject *) 0x20ab610
root [7] mytree-> GetListOfBranches () -> At (0) -> GetName ()
(const char * 0x20ab629) “peso”
root [8] mytree-> GetListOfBranches () -> At (129) -> GetName ()
(const char * 0x241dea0) “Eventshape_rhoKt4EM”
root [9] mytree-> GetListOfBranches () -> At (583) -> GetName ()
(const char * 0x26eb9f0) “jet_AntiKt10TruthTrimmedPtFrac5SmallR30_ZCUT12”
y así. Se accede a todos estos de manera casi instantánea porque toda esta información es simplemente descriptiva. No tiene idea de cuáles son los datos reales porque todo se recupera a través de punteros. Debido a esto, podemos desplegar y expandir lentamente los datos en varios lugares que nos interesan … ¡y sabemos dónde desempaquetar los datos porque sabemos dónde está todo! Simplemente no sabemos de qué se trata. Entonces, veamos cuál es el valor para algunos eventos, como la rama ZCUT12 que hemos encontrado.
root [13] mytree-> GetEntry (0)
(Int_t) 720490
root [15] mytree-> GetBranch (“jet_AntiKt10TruthTrimmedPtFrac5SmallR30_ZCUT12”)
(clase TBranch *) 0x26eb520
root [18] mytree-> GetBranch (“jet_AntiKt10TruthTrimmedPtFrac5SmallR30_ZCUT12”) -> GetEntry (0)
(Int_t) 10
root [19] mytree-> GetBranch (“jet_AntiKt10LCTopo_pt”) -> GetEntry (0)
(int_t) 12
y así. El retorno de la función GetEntry solo le indica el tamaño de los datos almacenados en esa entrada en particular. Para obtener cosas como valores reales, debe tomar el TLeaf asociado con TBranch (es complicado, lo sé, pero generalmente se acostumbra o simplemente escribe macros para que nunca lidie con características directas reales como acceder a un solo valor). Una de las ubicaciones en las que ROOT brilla es que puede encadenar múltiples archivos ROOT juntos y luego dibujar histogramas y guardarlos en archivos. Dibujar histogramas es una de las cosas más comunes que podemos hacer y puede ser tan fácil como
root [0] mytree-> Draw (“jet_AntiKt10LCTopo_pt”)
root [1] mytree-> Draw (“jet_AntiKt10LCTopo_pt: jet_AntiKt10LCTopo_m”)
el primero dibuja un histograma 1D del anti-Kt R = 1.0 (agrupado de grupos topológicos en el detector) del jet pt. El segundo es un histograma 2D del chorro pt versus la masa del chorro. Los datos histogramados podrían almacenarse nuevamente en un archivo ROOT para acceder a otro script para dibujar los gráficos y guardarlos en el archivo. Debido a la naturaleza del archivo ROOT, podemos acceder a los histogramas tan rápido como queramos independientemente del tamaño del archivo ROOT porque almacena punteros a los datos del histograma.
Ahora, cuando comience a obtener datos significativamente más complicados, y la naturaleza de los archivos ROOT capaces de almacenar punteros a otros datos, encontrará que las bases de datos estándar están mal equipadas para almacenar datos ROOT en primer lugar. Por ejemplo, un chorro anti-Kt R = 1.0 calibrado localmente de grupos topológicos podría prepararse con Kt, R = 0.3 sujetos. En lugar de almacenar la información del sujeto directamente debajo del chorro, el chorro almacena punteros a la información del sujeto. Esto significa que las mismas fuentes podrían señalar los mismos datos en un esfuerzo por minimizar el espacio de almacenamiento y maximizar la eficiencia. Una vez intenté tomar un archivo ROOT que tenía 2 gigabytes y almacenarlo en una base de datos MySQL (23 gigabytes) y una base de datos PostgreSQL (18 gigabytes). ROOT hace un trabajo fantástico con la compresión y normalmente las bases de datos no pueden manejar esta mierda.
[1] Bienvenido a la red informática mundial LHC
[2] http://cds.cern.ch/record/169540…
[3] Gran colisionador de hadrones
[4] CERN LHC
[5] The Grid: un sistema de niveles
[6] http://atlas.web.cern.ch/Atlas/G…
[7] Página en gantep.edu.tr
[8] Archivos ROOT | RAÍZ
[9] TTree
[10] TBranch
[11] TLeaf
