database mapreduce data-warehouse greenplum vldb

database - 20 mil millones de filas/mes-Hbase/Hive/Greenplum/¿Qué?



mapreduce data-warehouse (7)

NXC, ¿estás seguro de esos 600 mil millones de filas por día? Incluso si una fila fuera solo un byte, eso es 600 GB de datos diarios. Suponiendo un 100 bytes más razonable por fila, estamos hablando de 60 TB de datos por día, 1.8 PB por mes. Realmente dudo que alguien esté extrayendo tanta información a través de Oracle.

Otras fuentes parecen confirmar que Oracle se vuelve bastante difícil de manejar cuando el volumen de datos alcanza cifras de TB de 2 dígitos.

Me gustaría utilizar su sabiduría para elegir la solución adecuada para un sistema de depósito de datos. Aquí hay algunos detalles para comprender mejor el problema:

Los datos están organizados en una estructura de esquema en estrella con un GRAN hecho y ~ 15 dimensiones.
20B filas de hechos por mes
10 dimensiones con cientos filas (algo de jerarquía)
5 dimensiones con miles filas
2 dimensiones con ~ 200K filas
2 dimensiones grandes con filas de 50M-100M

Dos consultas típicas se ejecutan en este DB

Miembros principales en dimq:

select top X dimq, count(id) from fact where dim1 = x and dim2 = y and dim3 = z group by dimq order by count(id) desc

Medidas contra una tupla:

select count(distinct dis1), count (distinct dis2), count(dim1), count(dim2),... from fact where dim1 = x and dim2 = y and dim3 = z

Preguntas:

  1. ¿Cuál es la mejor plataforma para realizar tales consultas?
  2. Qué tipo de hardware se necesita

  3. ¿Dónde se puede alojar (EC2?)


    (ignore los problemas de importación y carga en este momento)

Tnx,
Hageo.

Una alternativa para un bajo número de usuarios sería un clúster (beowulf). 20K te compra 50 nettops con 500G cada una. Eso es aproximadamente 3KW de potencia máxima. O 4 meses de almacenamiento en la nube.

He tenido un gran éxito con Vertica . Actualmente estoy cargando entre 200 y mil millones de filas en un día, con un promedio de 9 billones de líneas al mes, aunque he llegado a 17 mil millones en un mes. Tengo cerca de 21 dimensiones y las consultas son increíblemente rápidas. Pasamos del sistema anterior cuando simplemente no teníamos las ventanas del tiempo para hacer la carga de datos.

hicimos una prueba muy exhaustiva y estudiamos diferentes soluciones, y prácticamente miramos todo en el mercado. Si bien tanto Teradata como Netezza nos habrían convenido, sencillamente eran demasiado costosos para nosotros. Vertica les gana a ambos en la relación precio / rendimiento. Por cierto, es una base de datos en columnas.

Ahora tenemos alrededor de 80 usuarios, y se espera que crezca a unos 900 para fines del próximo año cuando comencemos a desplegarnos por completo.

Estamos utilizando ampliamente ASP.NET/dundas/reporting services para informes. También funciona bien con soluciones de informes de terceros, aunque no lo hemos probado.

Por cierto, ¿qué vas a usar para la carga de datos? Estamos usando informatica y estamos muy contentos con eso. SSIS nos llevó por la pared.

Tengo curiosidad por lo que finalmente seleccionaste. Su pregunta fue al final de 2008. Hoy en día, la situación es diferente con HBase, Greenplum, pig etc. dando acceso a SQL.

Con el pluging de informes HBASE y jasperserver hbase, se pueden crear informes decentes. Baja latencia OLAP puede ser creado en HBase. Esto funcionará igual que el SQL. El complemento Jasperserver HBase proporciona el lenguaje de consulta Hbase, que es una extensión del comando de escaneo Hbase.

No puedo enfatizar esto lo suficiente: obtenga algo que funcione bien con las herramientas de informes disponibles.

20 mil millones de filas al mes te colocan en el territorio VLDB, por lo que necesitas particionar. Las dimensiones de cardinalidad baja también sugieren que los índices de mapa de bits serían una ganancia de rendimiento.

  • Olvídese de los sistemas en la nube ( Hive , Hbase ) hasta que tengan soporte SQL maduro. Para una aplicación de depósito de datos, usted quiere algo que funcione con las herramientas de informes convencionales. De lo contrario, se encontrará perpetuamente empantanado escribiendo y manteniendo programas de informes ad-hoc.

  • Los volúmenes de datos son manejables con un sistema de gestión de bases de datos (DBMS) más convencional como Oracle: conozco una importante compañía de telecomunicaciones europea que carga 600 GB por día en una base de datos Oracle . En igualdad de condiciones, son dos órdenes de magnitud más grandes que sus volúmenes de datos, por lo que las arquitecturas de discos compartidos aún tienen espacio libre para usted. Es probable que una arquitectura compartida como Netezza o Teradata sea ​​aún más rápida, pero estos volúmenes no se encuentran en un nivel que esté más allá de un sistema de disco compartido convencional. Tenga en cuenta, sin embargo, que estos sistemas son bastante caros.

  • También tenga en cuenta que MapReduce no es un algoritmo de selección de consulta eficiente . Es fundamentalmente un mecanismo para distribuir cálculos de fuerza bruta. Greenplum tiene un back-end de MapReduce, pero un motor de nada compartido especialmente diseñado será mucho más eficiente y hará más trabajo por menos hardware.

Mi opinión sobre esto es que Teradata o Netezza probablemente serían la herramienta ideal para el trabajo, pero sin duda la más cara. Oracle , Sybase IQ o incluso SQL Server también manejarían los volúmenes de datos implicados, pero serán más lentos: son arquitecturas de disco compartidas, pero aún pueden administrar este tipo de volumen de datos. Vea esta publicación para un resumen de las características relacionadas con VLDB en Oracle y SQL Server, y tenga en cuenta que Oracle acaba de presentar también la plataforma de almacenamiento Exadata .

Mi plan de capacidad de back-of-a-fag-pack sugiere quizás 3-5 TB más o menos por mes, incluyendo índices para Oracle o SQL Server. Probablemente menos en Oracle con índices de mapa de bits, aunque una hoja de índice tiene un ROWID de 16 bytes en Oracle versus una referencia de página de 6 bytes en SQL Server.

Sybase IQ hace un uso extensivo de los índices de mapas de bits y está optimizado para las consultas del almacén de datos. Aunque es una arquitectura de disco compartido, es muy eficiente para este tipo de consulta (IIRC era la arquitectura original orientada a columnas). Esto probablemente sería mejor que Oracle o SQL Server, ya que está especializado para este tipo de trabajo.

Greenplum podría ser una opción más económica, pero nunca la he usado, así que no puedo comentar qué tan bien funciona en la práctica.

Si tiene 10 dimensiones con solo unos pocos cientos de filas, considere fusionarlas en una única dimensión basura que adelgace su tabla de hechos al fusionar las diez claves en una sola. Todavía puede implementar jerarquías en una dimensión de basura y esto eliminaría 1/2 o más del tamaño de su tabla de hechos y eliminaría una gran cantidad de uso de disco por índices.

Recomiendo encarecidamente que vaya con algo que funciona bien con una sección transversal razonable de herramientas de informes. Esto significa una interfaz de SQL. Los sistemas comerciales, como Crystal Reports, permiten que los informes y los análisis los realicen personas con un conjunto de habilidades de SQL más fáciles de obtener. El mundo de código abierto también ha generado BIRT , Jasper Reports y Pentaho. . Hive o HBase te ponen en el negocio de crear un front-end personalizado, que realmente no deseas a menos que estés feliz de pasar los próximos 5 años escribiendo formateadores de informes personalizados en Python.

Finalmente, ubíquelo en algún lugar donde pueda obtener fácilmente un feed de datos rápido de sus sistemas de producción. Esto probablemente significa su propio hardware en su propio centro de datos. Este sistema estará vinculado a E / S; está haciendo un procesamiento simple en grandes volúmenes de datos. Esto significa que necesitará máquinas con subsistemas de discos rápidos. Los proveedores de la nube tienden a no admitir este tipo de hardware, ya que es un orden de magnitud más caro que el tipo de caja desechable de 1U que tradicionalmente usan estos conjuntos. Fast Disk I / O no es una fortaleza de las arquitecturas en la nube.