PostgreSQL al almacén de datos:El mejor enfoque para ETL/extracción de datos casi en tiempo real

Question

Fondo:

Tengo una base de datos PostgreSQL (v8.3) que está muy optimizada para OLTP.

Necesito extraer datos de él en tiempo semi-real (alguien seguramente preguntará qué significa tiempo semi-real y la respuesta es tan frecuentemente como sea razonablemente posible, pero seré pragmático, como punto de referencia, digamos que esperan cada 15 minutos) e introducirlo en un almacén de datos.

¿Cuántos datos?En las horas pico, estamos hablando de aproximadamente 80-100 000 filas por minuto en el lado OLTP; fuera de las horas pico, esto se reducirá significativamente a 15-20 000.Las filas que se actualizan con más frecuencia tienen ~64 bytes cada una, pero hay varias tablas, etc., por lo que los datos son bastante diversos y pueden alcanzar hasta 4000 bytes por fila.El OLTP está activo 24x5.5.

¿Mejor solución?

Por lo que puedo reconstruir, la solución más práctica es la siguiente:

• Cree un DISPARADOR para escribir toda la actividad DML en un archivo de registro CSV rotativo
• Realizar las transformaciones necesarias
• Utilice la herramienta nativa de bombeo de datos de DW para bombear eficientemente el CSV transformado al DW

¿Por qué este enfoque?

• LOS DISPARADORES permiten apuntar a tablas selectivas en lugar de abarcar todo el sistema + la salida es configurable (es decir,en un CSV) y son relativamente fáciles de escribir e implementar.SLONY utiliza un enfoque similar y los gastos generales son aceptables
• CSV fácil y rápido de transformar
• Fácil de bombear CSV al DW

Alternativas consideradas....

• Usando el registro nativo (http://www.postgresql.org/docs/8.3/static/runtime-config-logging.html).El problema con esto es que parecía muy detallado en relación con lo que necesitaba y era un poco más complicado de analizar y transformar.Sin embargo, podría ser más rápido porque supongo que hay menos gastos generales en comparación con un TRIGGER.Ciertamente, facilitaría la tarea de administración ya que abarca todo el sistema, pero nuevamente, no necesito algunas de las tablas (algunas se usan para el almacenamiento persistente de mensajes JMS que no quiero registrar)
• Consultar los datos directamente a través de una herramienta ETL como Talend y enviarlos al DW...El problema es que sería necesario modificar el esquema OLTP para admitir esto y eso tiene muchos efectos secundarios negativos.
• Usar un SLONY modificado/pirateado: SLONY hace un buen trabajo al registrar y migrar cambios a un esclavo, por lo que el marco conceptual está ahí, pero la solución propuesta parece más fácil y limpia.
• Usando el WAL

¿Alguien ha hecho esto antes?Quieres compartir tus pensamientos?

Answer 1

Suponiendo que sus tablas de interés tengan (o puedan ampliarse con) una clave secuencial única, indexada, obtendrá un valor mucho mejor simplemente emitiendo SELECT ... FROM table ... WHERE key > :last_max_key con salida a un archivo, donde last_max_key es el último valor clave de la última extracción (0 si es la primera extracción). El enfoque incremental y desacoplado evita presentando desencadenar latencia en la ruta de datos de inserción (ya sean activadores personalizados o Slony modificado) y, dependiendo de su configuración, podría escalar mejor con la cantidad de CPU, etc.(Sin embargo, si también tienes que pista UPDATEs, y usted agregó la clave secuencial, entonces su UPDATE las declaraciones deben SET la columna clave para NULL entonces obtiene un nuevo valor y se selecciona en la siguiente extracción.Lo harías no poder rastrear DELETEs sin disparador.) ¿Es esto lo que tenía en mente cuando mencionó a Talend?

me gustaría No utilice la función de registro a menos que no pueda implementar la solución anterior.;lo más probable es que la tala implique bloqueo por encima de la cabeza para garantizar que las líneas de registro se escriban secuencialmente y no se superpongan/sobrescriban entre sí cuando varios backends escriben en el registro (consulte la fuente de Postgres). La sobrecarga de bloqueo puede no ser catastrófica, pero puede prescindir de ella si puede usar el incremental. SELECT alternativa.Además, el registro de declaraciones se ahogaría cualquier mensaje útil de ADVERTENCIA o ERROR, y el el análisis en sí no será instantáneo.

A menos que esté dispuesto a analizar los WAL (incluido el seguimiento del estado de las transacciones y estar listo para reescribir el código cada vez que actualice Postgres), tampoco usaría necesariamente los WAL, es decir, a menos que tener el hardware adicional disponible, en cuyo caso podrías enviar WAL a otra máquina para su extracción (en la segunda máquina puedes usa disparadores descaradamente - o incluso el registro de declaraciones - ya que cualquier cosa que suceda allí no afecta INSERT/UPDATE/DELETE rendimiento en la máquina principal.) Tenga en cuenta que en cuanto al rendimiento (en la máquina principal), a menos que pueda escribir los registros en una SAN, obtendría un rendimiento comparable (en términos de destrucción del caché del sistema de archivos, principalmente) al enviar WAL a una máquina diferente a partir de ejecutar el incremental SELECT.

Answer 2

si se puede pensar en una 'mesa de suma de comprobación' que incluye solamente la de la 'suma de comprobación' de ello y no sólo se puede hacer una rápida seleccionar de los nuevos registros de registros, sino también la cambió y se elimina.

la suma de comprobación podría ser una función de suma de comprobación CRC32 te gusta.

Answer 3

La nueva cláusula ON conflicto en PostgreSQL ha cambiado la forma en que hago muchas actualizaciones. Me tire de los nuevos datos (basado en una row_update_timestamp) en una tabla temporal y luego en INSERT declaración de una SQL en la tabla de destino con ACTUALIZACIÓN EN CONFLICTO. Si su tabla de destino se divide entonces tiene que saltar a través de un par de aros (es decir golpear la tabla de particiones directamente). El ETL puede suceder que se carga la tabla de la temperatura (lo más probable) o en el CONFLICTO EN SQL (si es trivial). En comparación con otros sistemas "upsert" (actualizar, insertar si cero filas etc.) Esto muestra una mejora enorme velocidad. En nuestro entorno DW particular, no necesitamos / queremos dar cabida a DELETEs. Echa un vistazo a los documentos sobre el conflicto - que da MERGE de Oracle una carrera por su dinero