Datawarehouse 365TB

No sera ese proyecto del gobierno gringo? D:

Tai loco, el gobierno gringo debe recolectar cientos de terabyte al dia.

Dependiendo de la carga que genere a los servidores hacer 2 independientes.
Uno que extraiga los datos y que realice los procesos y otro que solo se use para almacenar y servir los datos procesados.

No se que proceso harás sobre los datos, pero hay algunas funciones espaciales que son bastante pesadas, mas si vas a trabajar con varios objetos a la vez, y aún mas carga con polígonos con muchos vértices. Ojo con eso.

lo primero es ver que BD van a usar, por lo menos lo que hemos echo ultimamente es tener una BD para insertar datos en duro (mssql en cluster con discos conectados por fibra, lo mas importante aca son los IO que entrega el bicho del storage, aparte de estar balanceada, si se cae un storage sigue funcionando el otro), y luego sincronizamos a apache cassandra en cluster para mostrar la info y los reportes por web (las nosql son buenas para consultas pero no para insertar datos despues de lso 60000 registros concurrentes se va al demonio), bueno insisto depende de que es lo que necesitas, pero si buscas no somos los unicos que usamos modelos hibridos para sistemas altamente concurrentes.

La definición de las herramientas a utilizar son a criterio del proveedor, asi que podría haber ofrecido la combinación que quisiera.

Respecto a los inserts en nosql, yo trabajo harto con MongoDB y tengo bastante buena tasa de inserts. La DB consta de 10 tablas de 4GB cada una, y cada una contiene varios millones de documentos. Hago queries geoespaciales sobre ellas y búsqueda de texto, y la query suele demorar unos 10s.

Sin embargo, para este caso me parece que MongoDB se queda corto. No sólo es mucha data para una sola máquina (aunque sea de 8 núcleos y 16gb ram) sino que en un cluster el almacenamiento es redundante. Proveer 3 nodos de 365tb cada uno me costaría unos 40.000 dólares mensuales y no es la idea.

Todo depende del presupuesto y en base a eso hay que definir un alcance.

Si es para un DWH y dado que la data productiva está en origen, se podria pensar en un storage de alta capacidad (HP 3PAR, IBM XIV, EMC VMAX, etc...), donde se podria definir un "umbral de corte" de una cantidad x de tiempo en capacidad para discos rapidos (en 15k fibra) y el resto en una especie de "historico" en discos lentos de alta capacidad (SATA de tipo empresarial 7.2k), con esto, teniendo en cuenta que estos storage pueden manejar de forma interna la ubicación de la data dependiendo del grado de uso que tiene la data, el storage puede automaticamente mover la hot data (mas actual probablemente) a los discos rapidos, mientras se mantiene el resto en los discos lentos a la espera).

Estos storage manejan niveles de protección bastante altos, por lo que no debiese ser un problema, pero claro, nuevamente depende del presupuesto ya que estos bichos no son nada de baratos, ahora, de ser realmente ese el volumen de datos y conociendo escenarios de ese tipo en bancos por ejemplo, la petición no es nada de pequeña.

Saludos.

Nada de pequeña, y sobre todo porque el cliente quiere una solución llave en mano. Ellos dejan el dump diario en un servidor y nosotros tenemos que leer, parsear y subir a la caja negra que decidamos ofrecer.

Y sobre esa plataforma, correr reportes en tiempo real es un desafío grande. En esta magnitud de datos lo más normal sería trabajar con jobs asíncronos, pero eso no interactúa bien con aplicaciones web.

¿1TB diario? Me imagino que son robots los usuarios que haran análisis o gestión de esos datos :

¿No será un problema de definición de Medidas y Dimensiones? ¿O con los ETL's queda reducida la cantidad de datos?

Si algo he aprendido es que los DWH no son sacos sin fondo. El costo de procesamiento y almacenaje de tal cantidad de datos no se compensa para casi ninguna empresa en Chile...

Quizá estoy siendo prejuicioso, pero los proyectos BI son grandes dolores de cabeza, sobre todo si trabajas con un cliente de un área "Estadística" :

piensas modelar esto dimensionalmente?
cuantas dimensiones y tablas de hechos serian? hay dimensiones compartidas? jerarquias ragged/skiped? slow-change-dimensions?
que tipo de metricas necesitas, son agregaciones simples o tienen logicas complejas?
vas a analizar data transaccional o a generar snapshots agregados?
las dimensiones son densas o dispersas? quizas un motor columnar te ahorre muuucho espacio en disco.
cuantos años de historia necesitas almacenar?
la visualizacion es en reportes estructurados o es mas tirao a analytics y data-discovery?

cuanto ppto tiene el cliente para HW y licencias de software?
se me viene a la cabeza un informatica/datastage + teradata o SQl Server parallel DW pero ahí los precios se te disparan y el valor del desarrollo tb.
Para visualizacion hay alternativas más baratas y si necesitas algo muy especifico con R puedes hacer maravillas.

quizas un enfoque mas tirao a big-data pueda darte los resultados que necesitas? te ahorras la paja de la integracion y con herramientas como pig-hive-impala puedes hacer analisis con muy buena performance solo que es un conocimiento muuucho mas especifico.

PD: Mandame un MP si tienes mas dudas.

Buena guaripolo. Se nota que cachas del tema. Efectivamente, la solución debe pasar por una plataforma de big data.

Sobre dimensiones y jerarquías no tengo idea.

Es un año de data, o sea 365TB. El presupuesto es como 500k usd. Al año.

averigua acerca de cloudera.

Para el throughput de datos que necesitas te podria funcionar, pero necesitas analistas suuuuuuuper capacitaos (y ojala informaticos)

Cloudera ha estado intentando hacer un hadoop que responda con la rapidez de un motor sql corriente.

Mi apuesta es ir por google bigquery. Si eventualmente se necesita levantar un hadoop, el mismo storage en google cloud storage se puede usar en reemplazo de hdfs

Google big.query sigue teniendo el enfoque de hadoop de tirar un "job" con ciertos parametros y esperar a que termine, ademas es una solucion cloud.. como piensas subir 1tb diario a la nube? no lo veo posible a menos que tu source-system este tambien alojado en la nube de google.

Por otra parte, si tienes usuarios analistas con conocimientos de SQL podrias probar con Impala y dejar a un admin dandole mantencion a los jobs de carga de datos con Pig

Impala

y... yo me quede en la epoca que un procedimiento almacenado y unos inner join eran lo complejo