Amenadiel

Ille qui nos omnes servabit
Fundador
OVERLORD
REPORTERO
Se incorporó
15 Enero 2004
Mensajes
18.398
Estamos viendo una postulación a un proyecto para una empresa chilena de servicios.

En términos generales, la empresa quiere que el proveedor (mi empresa) ofrezca los servicios de

- extracción de datos desde su plataforma
- carga de data a una plataforma de almacenamiento y análisis
- provisión o construcción de la mentada plataforma
- disponibilización de una herramienta de visualización y reportería de los datos cargados en donde además se pueda definir filtros y agrupaciones en forma dinámica.

El volumen de datos es de 1TB diario y cada registro tiene datetime y posición geoespacial, de manera que cuando se habla de una herramienta de visualización y una UI capaz de generar filtros, estamos hablando de operar sobre un mapa. El almacenamiento debe ofrecer un año de historia.

¿Cómo lo harían? Yo ya redacté la propuesta técnica asi que no espero que me hagan la pega, sino que me gustaría contar con otros puntos de vista.
 

Amenadiel

Ille qui nos omnes servabit
Fundador
OVERLORD
REPORTERO
Se incorporó
15 Enero 2004
Mensajes
18.398
Tai loco, el gobierno gringo debe recolectar cientos de terabyte al dia.
 
Upvote 0

nibal2

pajarón nuevo
MOD
Se incorporó
15 Junio 2007
Mensajes
2.897
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.
 
Upvote 0

Harima

Pegao al tarro
Se incorporó
15 Mayo 2008
Mensajes
3.956
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.
 
Upvote 0

Amenadiel

Ille qui nos omnes servabit
Fundador
OVERLORD
REPORTERO
Se incorporó
15 Enero 2004
Mensajes
18.398
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.
 
Upvote 0

Tbon

Football total philosophy
Miembro del Equipo
Fundador
ADMIN
Se incorporó
20 Enero 2004
Mensajes
13.672
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.
 
Upvote 0

Amenadiel

Ille qui nos omnes servabit
Fundador
OVERLORD
REPORTERO
Se incorporó
15 Enero 2004
Mensajes
18.398
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.
 
Upvote 0

SeWa

Pro
Se incorporó
4 Abril 2006
Mensajes
536
¿1TB diario? Me imagino que son robots los usuarios que haran análisis o gestión de esos datos :zippy:

¿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" :zippy:
 
Última modificación:
Upvote 0

guaripolo

Fanático
Se incorporó
21 Agosto 2006
Mensajes
1.344
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.
 
Upvote 0

Amenadiel

Ille qui nos omnes servabit
Fundador
OVERLORD
REPORTERO
Se incorporó
15 Enero 2004
Mensajes
18.398
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.
 
Upvote 0

guaripolo

Fanático
Se incorporó
21 Agosto 2006
Mensajes
1.344
averigua acerca de cloudera.

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

Amenadiel

Ille qui nos omnes servabit
Fundador
OVERLORD
REPORTERO
Se incorporó
15 Enero 2004
Mensajes
18.398
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
 
Upvote 0

guaripolo

Fanático
Se incorporó
21 Agosto 2006
Mensajes
1.344
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
 
Upvote 0

neoyagami

Un misterio
Se incorporó
3 Febrero 2005
Mensajes
4.970
y... yo me quede en la epoca que un procedimiento almacenado y unos inner join eran lo complejo :p
 
Upvote 0
Subir