- Basándose en la experiencia de los primeros ingenieros de BigQuery, en muchas organizaciones el cuello de botella estaba más cerca de cómo se usan los datos y de la estructura de costos que del tamaño de los datos
- A partir de clientes de BigQuery y comentarios de la industria, la mayoría de los data warehouses tenían menos de 1 TB, e incluso entre los clientes de uso intensivo la mediana era mucho menor que 100 GB
- La separación entre storage y compute en la nube aumentó mucho la cantidad almacenada, pero la demanda de cómputo analítico no creció en la misma proporción porque se concentra en datos recientes y agregados
- En BigQuery, el 90% de las consultas de clientes que gastaban más de 1,000 dólares al año procesaban menos de 100 MB, y hasta los clientes con datasets enormes no ejecutaban consultas grandes con frecuencia
- Los datos antiguos pueden convertirse en pasivo por regulación, litigios, pérdida de significado y lógica de procesamiento especial, así que conviene revisar si es mejor agregarlos, borrarlos o resumirlos en vez de conservar el original
La diferencia entre el miedo al Big Data y los verdaderos cuellos de botella
- Durante más de 10 años se ha repetido el mensaje de que la razón por la que es difícil obtener insights accionables de los datos es el tamaño de los datos
- Después vino la receta de comprar nuevas tecnologías para manejar una expansión masiva, pero incluso tras adquirir nuevas herramientas y migrar sistemas legacy, muchas organizaciones siguen teniendo dificultades para entender sus datos
- La situación en 2023 es distinta de la época en que comenzaron las alertas sobre Big Data
- El gran cataclismo de datos que se predecía nunca llegó
- El tamaño de los datos creció algo, pero el hardware avanzó más rápido
- Los vendors siguen vendiendo escalabilidad, pero quienes trabajan en esto empiezan a preguntarse cómo se conecta eso con los problemas reales
El tamaño de los datos de los clientes visto desde la experiencia de BigQuery
- El autor, ingeniero fundador de Google BigQuery, llegó a ejecutar consultas de 1 PB en presentaciones públicas para demostrar la capacidad de procesar datos a gran escala
- Después depuró problemas de clientes de BigQuery, coescribió 2 libros y, desde 2018, trabajó como product manager a cargo de conversaciones con clientes y del análisis de métricas del producto
- La observación más sorprendente fue que la mayoría de los usuarios de “BigQuery” en realidad no tenían Big Data
- Incluso los clientes con muchos datos tenían cargas de trabajo que usaban solo una pequeña parte de su dataset total
- Cuando BigQuery salió al mercado, su velocidad parecía ciencia ficción, pero después enfoques de procesamiento más tradicionales también lograron alcanzarla
- Los gráficos del artículo no son cifras exactas, sino dibujos a mano basados en recuerdos; lo importante no es el valor exacto, sino la forma de la distribución
- La base de estas ideas proviene de logs de consultas, análisis post mortem de transacciones, resultados de benchmarks, tickets de soporte, conversaciones con clientes, logs del servicio, posts públicos de blogs e intuición
La mayoría de las organizaciones no tiene tantos datos
- Los slides de ventas de “se viene el Big Data” transmitían la idea de que pronto todos quedarían abrumados por los datos, pero 10 años después ese futuro no se materializó
- Al ver el tamaño de los clientes de BigQuery, la mayoría tenía menos de 1 TB de datos almacenados en total
- Había clientes con cientos de PB, pero el tamaño seguía una distribución de ley de potencia que caía rápidamente
- Había miles de clientes que pagaban menos de 10 dólares al mes en storage, lo que equivale a unos 0.5 TB
- Incluso entre los clientes que más usaban el servicio, la mediana de almacenamiento era mucho menor que 100 GB
- En conversaciones con analistas de la industria como Gartner y Forrester también surgía el mismo comentario: la mayoría de los data warehouses empresariales eran menores a 1 TB
- Como referencia del sector, un tamaño razonable para un data warehouse rondaba los 100 GB
- El equipo de BigQuery tomó ese tamaño como foco principal de sus esfuerzos de benchmark
- Un inversionista que revisó empresas de su portafolio encontró que, incluso en compañías tecnológicas donde era más probable ver datos relativamente grandes, la empresa B2B más grande tenía alrededor de 1 TB, la B2C más grande unos 10 TB y la mayoría era mucho más pequeña
- Incluso en ejemplos de empresas medianas, los datos no crecen tan fácilmente hasta volverse gigantescos
- Aunque 1,000 clientes generaran cada día 1 pedido y 100 line items, el volumen diario seguiría por debajo de 1 MB y después de 3 años sería de alrededor de 1 GB
- Aunque una base de marketing tuviera 1 millón de leads y decenas de campañas, la tabla de leads seguiría por debajo de 1 GB y el tracking de campañas probablemente estaría en unos pocos GB
- Incluso cuando SingleStore era un unicornio Series E de rápido crecimiento entre 2020 y 2022, su warehouse financiero, datos de clientes, tracking de campañas de marketing y logs del servicio sumaban apenas unos pocos GB
La ilusión creada por separar storage y compute
- Todas las plataformas modernas de datos en la nube adoptan la separación entre storage y compute, para que el cliente no quede atado a un solo form factor
- Este cambio podría ser más importante que el scale-out dentro de los últimos 20 años de arquitectura de datos
- En lugar de una arquitectura shared-nothing difícil de administrar, una estructura shared disk permite escalar storage y compute de manera independiente
- Object storage escalable y suficientemente rápido como S3 y GCS alivió muchas restricciones de diseño en las bases de datos
- En la práctica, el tamaño de los datos crece mucho más rápido que el tamaño del cómputo
- Los datos se generan con el tiempo y, aun en un negocio estático, el volumen almacenado aumenta linealmente
- El análisis suele concentrarse en datos recientes, por lo que la demanda de compute no necesita crecer al ritmo del storage
- Como los datos antiguos no cambian, seguir escaneándolos es casi un desperdicio, y las respuestas importantes pueden obtenerse con agregados
- Muchos clientes que migraron de on-premise a la nube con separación entre storage y compute vieron crecer muchísimo su volumen almacenado sin que cambiara demasiado la demanda de cómputo
- Un gran cliente minorista de BigQuery tenía un data warehouse on-premise de unos 100 TB, pero tras migrar a la nube creció hasta 30 PB
- El volumen almacenado aumentó 300 veces, pero el costo de compute no creció en la misma proporción, ni gastaban miles de millones de dólares en analítica
- Esta estructura muestra que, usando object stores escalables, puede bastar con muchísimo menos compute del esperado, e incluso puede que no haga falta procesamiento distribuido
Las cargas reales de consultas son mucho más pequeñas que el total de datos
- Es posible que el volumen de datos procesado por las cargas analíticas sea menor de lo que sugiere la intuición
- Muchas veces los dashboards se construyen sobre datos agregados
- Los usuarios suelen mirar sobre todo la última hora, el último día o la última semana
- Las tablas pequeñas se consultan con más frecuencia, y las tablas gigantes se consultan de manera más selectiva
- Al analizar consultas de clientes de BigQuery que gastaban más de 1,000 dólares al año, el 90% de las consultas procesaba menos de 100 MB
- Se segmentó el análisis de varias maneras para evitar que el volumen de consultas de un cliente específico sesgara el resultado
- Se excluyeron las consultas solo de metadatos que no leen datos
- Las consultas en el rango de GB aparecían recién en percentiles altos, y las del rango de TB eran muy raras
- Incluso los clientes con enormes volúmenes de datos casi nunca consultaban volúmenes enormes
- Cuando ejecutaban consultas grandes, normalmente era para generar reportes y el rendimiento no era la prioridad
- Una gran empresa de social media ejecutaba consultas muy grandes los fines de semana para informes ejecutivos del lunes, pero eso era apenas una fracción mínima frente a cientos de miles de consultas durante la semana
- Las bases de datos analíticas modernas usan varias técnicas para reducir la cantidad de datos realmente leída
- Column projection para leer solo los campos necesarios
- Partition pruning para leer solo rangos de fechas acotados
- Eliminación de segmentos mediante clustering o micro-partitioning automático para aprovechar la localidad de los datos
- Cálculo sobre datos comprimidos, proyección y predicate pushdown también reducen el I/O al momento de la consulta
- Reducir el I/O disminuye el cómputo necesario y baja costos y latencia
- Material relacionado: Reducir costos del data warehouse en la nube
- Material relacionado: Diagnosticar cuellos de botella de rendimiento en data warehouses
El costo de procesar datos presiona para consultar menos
- Que algo pueda procesarse rápido con scale-out no significa que sea barato procesarlo
- Si hacen falta 1,000 nodos para obtener un resultado, el costo puede ser muy alto
- La consulta de 1 PB que se ejecutaba en las demos de BigQuery costaba 5,000 dólares a precio de lista
- Esta ineficiencia es parte del impuesto del big data para equipos que en realidad no operan a escala de PB
- El incentivo económico para reducir el volumen procesado aplica incluso fuera de un modelo de cobro por bytes escaneados
- Ya sea el costo de escaneo en BigQuery o el costo en idle de una instancia de Snowflake, los principales data warehouses en la nube pueden inflar la factura
- Si las consultas son más pequeñas, se pueden usar instancias más chicas, las consultas van más rápido y también aumenta la concurrencia posible
La mayor parte de los datos casi nunca se consulta
- Una gran proporción de los datos procesados corresponde a datos recientes de menos de 24 horas
- Cuando un dato tiene alrededor de 1 semana, es unas 20 veces menos probable que se consulte que los datos del último día
- Después de un mes, en general los datos siguen ahí, pero solo se consultan cuando corre algún reporte poco frecuente
- La distribución por antigüedad de los datos almacenados es mucho más plana que el patrón de acceso
- Muchos datos se descartan rápido, pero muchos otros simplemente se siguen agregando al final de la tabla
- Aunque los datos del último año sean solo el 30% del total, podrían representar el 99% de los accesos
- Aunque los datos del último mes sean solo el 5% del total, podrían representar el 80% de los accesos
- Cuando los datos se enfrían con el tiempo, el verdadero working set termina siendo más manejable de lo esperado
- Incluso si existe una tabla de 1 PB con 10 años de historia, lo que realmente se consulta con frecuencia podría ser solo el día actual
- Y los datos del día actual podrían ocupar menos de 50 GB comprimidos
Los límites de una sola máquina siguen desplazándose
- Si se define Big Data como “lo que no cabe en una sola máquina”, la cantidad de cargas que entran en esa categoría disminuye cada año
- Cuando se escribió el paper de Google MapReduce en 2004, era común que las cargas de datos normales no cupieran en una sola máquina de propósito general
- Cuando AWS lanzó EC2 en 2006, las instancias disponibles tenían solo un núcleo y 2 GB de RAM, y muchas cargas no cabían en esa máquina
- Hoy, una instancia estándar de AWS usa 64 cores y 256 GB de RAM a nivel de servidor físico
- La RAM es decenas de veces mayor que la de las primeras instancias de EC2 en 2006
- Pagando más por instancias memory-optimized se puede aumentar la RAM en varios órdenes adicionales
- Eso lleva a preguntarse cuántas cargas realmente necesitan más de 24 TB de RAM o 445 CPU cores
- En la nube, el costo de una VM grande crece casi linealmente con la potencia de compute
- Una VM que usa todo un servidor cuesta solo 8 veces más que una VM que usa 1/8 del servidor
- Se plantea que hoy podría lograrse en un solo nodo un rendimiento comparable al benchmark original del paper de Dremel con 3,000 nodos paralelos
Los datos pueden ser un pasivo, no un activo
- Otra forma de definir Big Data es como “una situación en la que el costo de decidir qué borrar es mayor que el costo de seguir guardando todo”
- Muchos data lakes de las organizaciones se parecen más a un pantano gigantesco que creció no porque fuera necesario, sino porque nadie borró nada
- No saben qué contiene
- No saben si es seguro limpiarlo
- El costo de conservar datos es mayor que el simple costo físico de almacenar bytes
- Regulaciones como GDPR y CCPA exigen rastrear cómo se usa cierta información
- Algunos datos deben borrarse dentro de ciertos plazos
- Si números de teléfono permanecen demasiado tiempo en archivos parquet dentro de un data lake, eso puede violar requisitos legales
- Los datos antiguos también pueden jugar en contra de una organización durante litigios
- Así como muchas organizaciones limitan la retención de emails para reducir responsabilidades potenciales, los datos del data warehouse también pueden convertirse en evidencia perjudicial
- Si logs de hace 5 años muestran un bug de seguridad en el código o incumplimientos de SLA, conservarlos más tiempo puede prolongar la exposición legal
- Los datos también pueden perder significado con el tiempo, como el bit rot en el código
- La gente puede olvidar el significado exacto de campos especiales
- Los bugs de datos del pasado pueden borrarse de la memoria
- Por ejemplo, pudo haber existido un periodo breve en el que todos los
customer idquedaron en null, o una gran transacción fraudulenta pudo haber hecho que los resultados del Q3 de 2017 parecieran mejores de lo real - La lógica de negocio para consultar periodos antiguos puede volverse cada vez más compleja, como “antes de 2019 era
revenue, de 2019 a 2021 erarevenue_usd, y desde 2022 esrevenue_usd_audited”
Revisar si estás en el 1% del Big Data
- El Big Data existe de verdad, pero puede que la mayoría de la gente no tenga por qué preocuparse por eso
- Para evaluar si eres parte del 1% del Big Data, puedes hacerte estas preguntas
- ¿Realmente generas una cantidad enorme de datos?
- Si es así, ¿de verdad necesitas usar una cantidad enorme de datos al mismo tiempo?
- Si es así, ¿de verdad es tan grande que no cabe en una sola máquina?
- Si es así, ¿no será que solo estás acumulando datos?
- Si es así, ¿no sería mejor resumirlos?
- Si respondes “no” a cualquiera de estas preguntas, podrías ser candidato para una nueva generación de herramientas de datos ajustadas al tamaño real de los datos que tienes
- Como ejemplo relacionado, se menciona una alternativa moderna a BigQuery
- En vez de asustarse por el tamaño de los datos que quizá algún día tengan, las organizaciones deberían elegir herramientas y políticas de retención en función del tamaño de los datos que realmente tienen y de sus patrones reales de consulta
1 comentarios
Opiniones de Hacker News
En un trabajo anterior, cuando contratábamos científicos de datos, una pregunta trampa que nos gustaba usar era: “si el requisito dice que tienes hasta 6 TiB de datos, ¿qué stack/arquitectura armarías?”
Al escuchar respuestas grandilocuentes como BigQuery o Hadoop, y luego preguntar por costos de hardware/software/licencias, solían salir presupuestos de decenas de miles de dólares al año
Al final, quien pasaba era la persona que entendía que 6 TiB es una cantidad que 6 personas en una habitación podrían repartirse en sus smartphones; que bastaría con un HDD empresarial de 199 dólares, o tres para redundancia; y que incluso se podría cargar varias veces en memoria como CSV y procesarlo con scripts de
awkYo también caigo fácilmente en el error de que, cuando aprendes a usar un martillo, todo parece clavo, pero en contratación, no tener sentido de escala sobre lo que es “big data de verdad” era motivo de descarte
Más que concluir, solo por esa respuesta, que sobrediseña todo, lo correcto es verlo como alguien que cayó en una pregunta trampa dentro de una situación artificial donde el entrevistador tiene ventaja
Hace poco tuve una entrevista técnica con un entrevistador de años de experiencia similares a los míos, y respondí mal; el entrevistador mostró una actitud juzgadora ante mi mala respuesta. Si los roles se hubieran invertido, yo podría haberlo puesto igual de incómodo con un tema que conociera mejor
Como entrevistador, hay que tener especial cuidado de no abusar de la posición de superioridad. Es contraproducente para la empresa y tampoco es algo bueno para la persona que tienes enfrente
“Servicio de consultoría: tú me traes tu problema de big data, yo te digo ‘tu dataset cabe en RAM’, y tú me pagas 10 mil dólares a cambio de ahorrarte 500 mil dólares”
Hace unos años, un director me mostró un sistema que IT había construido con Hadoop, API gateways, varios desarrolladores y costos de cientos de miles de dólares al año; cuando le dije que, con el tamaño actual y el tamaño previsible a futuro, podría correr perfectamente con una unidad USB conectada a su laptop y unos cuantos scripts de Python, se irritó muchísimo, y después de eso nunca volví a participar en ese proyecto
Lo veo como parte de un ciclo de fanfarronería muy extendido en las empresas. Es una estructura que no permite admitir “estamos haciendo algo simple”
awk, y aunque lo quisieran, escanear 6 TB en una sola CPU en cada consulta, sin particionamiento ni almacenamiento columnar, siempre será lentoPara estos usos, normalmente BigQuery funcionaba bien. La interfaz de consola alcanza para análisis ad hoc, y también se pueden conectar muchas herramientas como Metabase y Tableau
Si particionas correctamente, el costo tampoco es excesivo, y si se vuelve un problema, puedes agregar tablas de rollup
.parquetestán totalmente subestimados, y todavía mucha gente no conoce este formatoA diferencia de CSV, conservan los tipos de datos; son 10 veces más pequeños que CSV, así que 6 TB se vuelven 600 GB; y la lectura es 50 veces más rápida. También son un estándar abierto de la Apache Foundation
No se pueden inspeccionar tan fácilmente como un CSV, pero ese compromiso vale la pena. Ojalá cualquier lugar que ofrezca CSV para descargar también ofreciera
.parquetEn general estoy de acuerdo con gran parte del artículo, pero hay algunas salvedades. Primero, MongoDB es un mal punto de referencia. Nunca he visto algo que haga MongoDB que PostgreSQL no haga mejor, y las soluciones de big data no suelen ser NoSQL/MongoDB, sino bases de datos columnares, MapReduce, Cassandra y cosas por el estilo
Segundo, hay que planear para el éxito. El 95% de las empresas no se convertirán en unicornios, pero si apuntas al 5% restante, no llegarás sin prepararte. La razón para diseñar pensando en escalabilidad cuando tienes 5 clientes es poder aprovechar el momento en que llegue el crecimiento exponencial
Dicho eso, la lección central es correcta. La mayoría de los datos no son grandes, y los datos sobre todas las personas del mundo podrían caber en una Chromebook de 100 dólares. La mayoría de los datos se consultan rara vez y las consultas son pequeñas; a menudo, el primer paso en trabajos de big data es reducir terabytes al tamaño realmente necesario en GB, MB y a veces KB. Debido a la regulación, los costos de datos también están aumentando
La gente no solo hace planes; normalmente también los implementa. Si planeas los próximos 3 meses, puedes ser mucho más ágil y productivo. Si no puedes ejecutar, no puedes convertirte en unicornio
Parece una combinación del síndrome del segundo sistema y sesgo de supervivencia. Quienes limpiaron el desastre de un buen MVP se quejan de que “esto debimos haberlo hecho antes”, pero las empresas que sí lo planearon y diseñaron por adelantado no sobrevivieron, así que ni siquiera están ahí para ser objeto de quejas
Estoy de acuerdo con casi todo lo demás, pero esa parte me pareció incorrecta y no pude dejarla pasar
La pista de una startup es limitada, y si los ingenieros están gastando dinero en cosas que recién se recompensarán dentro de años, aumentan la probabilidad de fracasar antes de que llegue ese momento
Que un producto consiga una tracción tan fuerte normalmente viene de un efecto compuesto entre la existencia de una base de usuarios y una necesidad. Aunque tropieces al agregar nuevos usuarios durante el crecimiento, es poco probable que los usuarios existentes vuelvan al producto anterior o se vayan a otro lado
En el viejo Twitter, ver la fail whale todos los días era lo normal, pero la mayoría no se fue, ni hubo una migración masiva hacia alternativas que escalaran mejor. Los productos que experimentan ese tipo de crecimiento exponencial son raros, y durante ese proceso es común sufrir con el escalado y tener peor disponibilidad. Me pregunto qué productos de crecimiento exponencial fracasaron realmente por no poder escalar
Cuando “big data” estaba de moda, yo era investigador en el Large Hadron Collider. Para nosotros, analizar todos los datos era un caso de uso con sentido, y en la estadística frecuentista, cuantos más datos, mejor.
Pero aun usando una red mundial de supercomputadoras, descubrimos que era mejor tener almacenamiento local rápido que esperar a que terminaran trabajos enormes. Al final, todos los estudiantes de posgrado redujeron los datos relevantes exactamente a entre 1 y 5 TB sin perder demasiada flexibilidad de análisis.
Parece que aquí hay algo así como una ley de la conveniencia, comparable a la ley de escalamiento de Amdahl.
Esto parece más cercano a una limitación humana que a las matemáticas. Hay un límite claro a la flexibilidad que podemos aprovechar. Podría cambiar si aparecen formas más fáciles de ejecutar nuevos tipos de análisis, pero probablemente crezca de manera logarítmica respecto de la cantidad de cosas que queremos hacer.
La gente es muy buena encontrando formas convenientes de hacer las cosas un poco mejor cada año, pero cualquier idea requiere un tiempo mínimo para ejecutarse.
Si no recuerdo mal, la cola de espera de esa máquina era tan larga como, o más larga que, el tiempo que tomaba ejecutar el trabajo en hardware barato, y sistemas de procesamiento masivamente paralelo como Beowulf surgieron de esfuerzos de ese tipo.
Reducir el tamaño de las bases de datos almacenadas y de los cálculos es una excelente forma de minimizar la factura mensual del cliente.
En mi experiencia, los datos siguen creciendo exponencialmente, pero la cantidad de información no crece así.
En finanzas, si quieres, puedes obtener fácilmente 100 millones de puntos de datos por día para una sola serie temporal, y también puedes manejar miles de series temporales. Pero esa frecuencia de muestreo y esa cantidad de series suelen ser 99.99% redundantes, porque los valores propios caen casi a cero después de unas 10 dimensiones, y a veces mucho antes.
Casi no hay motivo para almacenar petabytes de datos de ticks que nunca vas a consultar. En muchos casos tiene mucho más sentido hacer una reducción de dimensionalidad agresiva y con pérdida en el momento de la recolección, guardar solo los primeros componentes principales y los valores atípicos, y monitorear la estabilidad de los valores propios para ver si algún factor nuevo que antes era despreciable se vuelve importante.
Como resultado, los conjuntos de datos se vuelven mucho más pequeños y fáciles de manejar, y muchas veces ofrecen más insights precisamente porque sí se pueden usar en la práctica.
Suena interesante, pero para mí es un tema completamente nuevo.
Lo gracioso de “big data” es que generaba un incentivo perverso para evitar incluso las optimizaciones más básicas y obvias a nivel de software. Mientras mayores fueran los requisitos de hardware, más podías demostrar lo impresionante que eras.
Por ejemplo, si decías: “jefe, en vez de calcular sobre todo el conjunto de datos, si leemos una muestra puedo calcular los promedios de este reporte solo con una laptop”, el jefe lo interpretaba como: “¿qué significa muestra? ¿Qué estás insinuando con esa palabrería de matemático/ingeniero? ¿No estarás diciendo que gasté millones de dólares en vano?”.
Durante un tiempo hubo muchísima exageración comercial y ruido alrededor de big data, además de una competencia de fanfarronería sobre quién tenía datos lo bastante grandes.
Durante mucho tiempo fue muy difícil conseguir más de 64 GB de memoria en una sola máquina, y cuando tienes un límite duro, la complejidad de implementación se dispara rápidamente.
Un proceso que falla 1 de cada 50 veces solo porque los datos crecieron un poco es muy destructivo. Los equipos ejecutan decenas de estas tareas cron periódicas, y si cada una se rompe con frecuencia, terminas de guardia solo para ir recortando pedazos.
Hadoop y MapReduce no eran extremadamente eficientes, pero usados correctamente funcionaban bien, y era mucho más importante que corrieran de forma confiable. Es decir, eran mejores que código C++ optimizado al bit que nadie confiaba ni podía mantener, y que se moría cada jueves con un error de segmentación extraño.
Hoy simplemente usaría Snowflake, pero en ese momento eran herramientas razonables.
Este artículo no es del todo preciso. Originalmente, el big data se definía en tres dimensiones: volumen, velocidad y variedad
El volumen en general ya se resolvió, y la velocidad también, aunque es cara. La variedad todavía no se ha resuelto
Hoy, el big data no tiene tanto que ver con “nos falta almacenamiento o cómputo”, sino más bien con “nos falta capacidad cognitiva para integrar y entender esto”
También recomiendo mucho sus charlas relacionadas. La mayoría están en YouTube
[1] https://www.youtube.com/watch?v=KRcecxdGxvQ
[2] https://amturing.acm.org/award_winners/stonebraker_1172121.c...
Cada aeronave tiene un sistema de radar, y dentro de él hay 8 unidades de almacenamiento SSD RAID-0 de 16 discos de 20 TiB. Normalmente no llenamos del todo los RAID, así que generamos alrededor de 176 TiB por día; con 7 vuelos en dos semanas, son 1.2 PiB por campaña, unos 7.2 PiB al año
La razón por la que tenemos que descansar un día entre vuelos es que hay que descargar los datos por fibra óptica a un servidor de almacenamiento empujado más o menos a una esquina del hangar junto a la plataforma. Luego se replican a un segundo servidor por seguridad y, cuando termina la misión, se envía todo a la sede central para almacenarlo y procesarlo
Estos datos son valiosos, pero no al nivel de “miles de millones de dólares”. Se usan para extracción de recursos, cartografía, estudios ambientales y geodésicos, y hemos conservado cada byte desde 2008. Porque cuando aparece un algoritmo nuevo, podemos reprocesar datos antiguos con el nuevo estándar
Los archivos se transmiten a servidores de procesamiento con GPU en bloques de 800 GiB a 2 TiB, y no se pueden comprimir. La mayor parte de lo que capturamos, el fondo cósmico de microondas, es bastante aleatorio. En algún momento me engañé pensando que si escribíamos a cinta podríamos reducir la infraestructura a la mitad, pero la capacidad de las cintas parecía estar calculada como cuando se almacenan archivos de texto de gigabytes llenos solo de ceros
Las GPU son lentas, las CPU son lentas, el bus PCIe es lento, la RAM es lenta y hasta mi velocidad de tipeo es lenta. Todo siempre tiene que volverse más rápido
Todo es demasiado lento, demasiado difícil y demasiado pequeño. Los discos duros son demasiado pequeños, y ajustar el kernel de Linux y configurar una red rápida y confiable hacia el clúster de procesamiento es demasiado difícil. Incluso las actualizaciones de kernel/paquetes que solo cambian detalles internos rompen el sistema de una manera que parece pasarnos solo a nosotros
La configuración predeterminada vive en la fantasía de que la RAM es escasa, así que está pensada para ahorrar memoria en tareas de red. Pero el servidor de archivos tiene 0.5 TB de RAM, así que quisiera que la usara toda para acelerar la red y el sistema de archivos. Al final hay que leer 6 horas la documentación del stack de red y llevar la E/S a un nivel de sentido común propio de 2024
Probablemente conozco
sysctl.confmejor que casi cualquier otra persona en la TierraLos almacenes de objetos distribuidos y persistentes que se autodenominan para big data se derrumban por completo con nuestra carga de trabajo o cuestan cientos de millones de dólares. Cuando digo que el tamaño de los objetos ronda 1 TB, los vendedores de sistemas de archivos distribuidos dejan de responder. Un proveedor incluso leyó los requisitos y me conectó con el encargado de clientes de agencias de inteligencia. No soy la NSA y no tengo presupuesto de la NSA
A veces aparece un MBA o PMP que leyó un artículo sobre la nube en Bloomberg, ve el costo del centro de datos on-premise y pregunta por migrar a AWS o Azure; cuando le muestro los números, tanto de dinero como de tiempo, pone cara de que va a vomitar y cambia de tema
Además, todos los proveedores se subieron a la moda de AI/cloud y están discontinuando las líneas de productos que nos sirven. Ahora tenemos que competir por GPU con hedge funds y startups de AI que quieren exprimir datos de clientes para mostrarles anuncios
Nos faltan almacenamiento y cómputo, y el almacenamiento y el cómputo que tenemos también son demasiado lentos. Los DPU/IPU son interesantes, pero apenas los objetos se vuelven más grandes que una consulta de base de datos SQL o un fragmento de video comprimido en streaming, chocan de inmediato con sus límites
Antes trabajé en una empresa que generaba 20 GB de datos analíticos por día; probablemente haya sido el volumen de datos más grande que voy a manejar
Como proyecto junior escribí un trabajo de procesamiento de datos para agregaciones por lote y en tiempo real, y guardé los resultados en blobs Parquet en Azure
Mi jefe era lo bastante inteligente como para organizar reuniones periódicas con stakeholders para discutir qué conservar y qué descartar, y gracias a buenos algoritmos podíamos comprimir los datos a unos 200 MB por día
Los últimos 2 meses se subían a SQL Server, los últimos 2 años se agregaban aún más y se ponían en otro servidor, y toda la empresa podía consultarlos desde Excel en un tiempo razonable. El big data original se está pudriendo en almacenamiento en cinta por si algún día hace falta
Mi jefe era un mal gerente, pero entendía bien los datos y, visto en retrospectiva, hizo muchas cosas bien; yo también aprendí mucho
Durante años he visto sobreingeniería en herramientas y pipelines de datos “grandes”. En muchos casos de uso, los data warehouses y data lakes están en el rango de GB o de unos pocos TB, así que se podrían simplificar muchísimo ejecutando DuckDB en una buena instancia de EC2
En mi experiencia, así obtienes resultados antes de que otros sistemas siquiera empiecen a ejecutar la consulta. Sí, estoy hablando de Athena
Hoy creo que muchas consultas incluso pueden ejecutarse en el navegador, así que con ayuda de DuckDB WASM(https://github.com/duckdb/duckdb-wasm) y perspective.js(https://github.com/finos/perspective) creé https://sql-workbench.com/
Parece que ese ciclo de moda finalmente llegó a la “meseta de la muerte”. No es un final raro en esta industria tan extremadamente guiada por modas
AI también usa todos los datos y les pega encima una red neuronal mágica para descubrir qué significan
Personalmente, creo que el principal motor del big data fue el ego de los fundadores de empresas. Algo así como: obviamente nuestra empresa va a crecer de forma explosiva y tendrá éxito a escala planetaria, así que hay que diseñar para esa escala.
Es trágico cometer este error cuando una sola base de datos SQLite sería suficiente hasta que el producto llegue a la Series C. Toda la energía debería enfocarse en el producto, no todavía en la escala.
Hadoop empezó inspirado en lo que había en Google y se volvió popular entre empresas de todo el mundo que querían manejar datos de una forma más barata y mejor que con Oracle.
Spark surgió como una solución a la complejidad de Hive/Pig y otros, y cuando las empresas pudieron crear pipelines de datos confiables, pudieron montar IA encima de ellos.
Los modelos de datos generados por acciones humanas intencionales, como hacer clic en enlaces, enviar mensajes o comprar, suelen ser pequeños. Esto se debe a que hay límites en la cantidad de humanos y en la cantidad de eventos intencionales que los humanos pueden generar por segundo.
En cambio, los modelos de datos generados por máquinas pueden tener una velocidad y un volumen varios órdenes de magnitud mayores, y no tienen un límite claro en el tamaño del modelo de datos. Estos datos suelen ser los más interesantes y subutilizados, porque permiten obtener muchos hechos sobre el mundo que no se pueden obtener con modelos de datos intencionales humanos.