[l-desarrollo] Heramientas ETL OpenSource para PostgreSQL..

[Alfredo Rico]

Buen día amigos. Reciban un cordial saludo.
Alguno de ustedes ha tenido experiencia con la utilización de
herramientas opensource para hacer ETL hacía una base de datos
postgres.
La idea es que se tienen un conjunto de archivos planos y pues
facilitaría mucho las cosas si se contara con un ETL para definir las
reglas de carga de dichos arcvhivos y evitar desarrollar un proceso de
carga manual ya que se implican muchas verificaciones en los archivos
planos (expresiones regulares, integridad referencial,
normalización/desnormalización).
He visto que existe por allí Pentaho y SpagoBI, entre otros pero
quisiera saber si pueden compartir alguna experiencia.

Muchas Gracias

--
Saludos Cordiales.-
Alfredo Rico.
San Cristóbal - Venezuela.
_______________________________________________
l-desarrollo mailing list
l-desa...@velug.org.ve
http://listas.velug.org.ve/mailman/listinfo/l-desarrollo

[Deivinson Tejeda]

Buenas,

Yo te recomiendo Pentaho en base a mi experiencia, si solo quieres hacer ETL puede que existan otras mas pequenas.

2012/3/30 Alfredo Rico <alfre...@gmail.com>

--
Deivinson Tejeda (CaChi)

 @DeivinsonTejeda | http://deivinson.tejeda.com.ve

[Nhomar Hernández]

A ver,

Depende el tamaño de lo que quieras hacer y la continuidad que le quieras dar.

Yo he probado al menos 3 ETL, y sinceramente, termino haciendo mi script en python puro, las librerías de conexión son sumamente sencillas, pero necesitas ser algo diciplinado para lograr algo interesante y mantenible, pero se logra, y al final te queda tu propio ETL para tu o tus casos.

Es decir:

Si necesitas migrar 10 casos, y estos serás una vez configurados siempre los mismos, usa python o perl para la transformación y las librerias para la carga y la extracción.

SI necesitas cambiar los casos día a día por que el análisis de los datos asñi lo requiere, unas kettle, a mi no me gusta por que es Java (odio java) pero de lo OS es el mejor a mi parecer.

He sacado data desde casi 10 motores de BD y siempre pongo éstos datos en postgres.

Pentaho es la herramienta BI no el ETL el ETL es realmente http://kettle.pentaho.com/

Solo informativo.

Saludos.

--------------------
Saludos Cordiales

Nhomar G. Hernandez M.
+58-414-4110269
Skype: nhomar00
Web-Blog: http://geronimo.com.ve
Servicios IT: http://vauxoo.com
Linux-Counter: 467724
Correos:
nho...@openerp.com.ve
nho...@vauxoo.com
twitter @nhomar

[Gerardo Curiel]

2012/3/31 Nhomar Hernández <nho...@openerp.com.ve>

A ver,

Depende el tamaño de lo que quieras hacer y la continuidad que le quieras dar.

Yo he probado al menos 3 ETL, y sinceramente, termino haciendo mi script en python puro, las librerías de conexión son sumamente sencillas, pero necesitas ser algo diciplinado para lograr algo interesante y mantenible, pero se logra, y al final te queda tu propio ETL para tu o tus casos.

Es decir:

Si necesitas migrar 10 casos, y estos serás una vez configurados siempre los mismos, usa python o perl para la transformación y las librerias para la carga y la extracción.

Todo esto es mas practico y mas rapido si eres programador. Ahora, dile lo mismo a un DBA a ver si va a ser igual de rapido.

 

SI necesitas cambiar los casos día a día por que el análisis de los datos asñi lo requiere, unas kettle, a mi no me gusta por que es Java (odio java) pero de lo OS es el mejor a mi parecer.

Heh, dejas de recomendar una herramienta solo porque odias el lenguaje en el que está hecho? Me parece bastante retrogrado, a estas alturas del partido que eso siga sucediendo. Yo por lo menos no le tengo mucho amor a Perl, pero si me preguntan por un manejador de tickets, recomendaria de una vez Request-Tracker, hands down.

 

He sacado data desde casi 10 motores de BD y siempre pongo éstos datos en postgres.

Pentaho es la herramienta BI no el ETL el ETL es realmente http://kettle.pentaho.com/

Esta  es la herramienta _mejorcita_ para eso. Estuve usandola por bastante tiempo, y aún cuando resuelve el problema, la interfaz en algunos casos deja mucho que desear. Y en este caso, la interfaz tiene importancia, porque el API para crear programaticamente las ETL es horrible, pero el workflow de crear ETLS y luego llamarlas programaticamente si es excelente. 

Saludos.

 

--
Gerardo Curiel

[Nhomar Hernández]

El 31 de marzo de 2012 11:33, Gerardo Curiel <gcu...@gmail.com> escribió:

2012/3/31 Nhomar Hernández <nho...@openerp.com.ve>

A ver,

Depende el tamaño de lo que quieras hacer y la continuidad que le quieras dar.

Yo he probado al menos 3 ETL, y sinceramente, termino haciendo mi script en python puro, las librerías de conexión son sumamente sencillas, pero necesitas ser algo diciplinado para lograr algo interesante y mantenible, pero se logra, y al final te queda tu propio ETL para tu o tus casos.

Es decir:

Si necesitas migrar 10 casos, y estos serás una vez configurados siempre los mismos, usa python o perl para la transformación y las librerias para la carga y la extracción.

Todo esto es mas practico y mas rapido si eres programador. Ahora, dile lo mismo a un DBA a ver si va a ser igual de rapido.

Aquí solamente te comento que un DBA (programar) que NO sepa sql, es como un médico que no sabe para que es la penicilina, pero si es un tanto difícil, pero a todos los DBA que le he entrenado en Python, salen con los ojitos hechos agua por haberse dado cuenta tan tarde ;-)
 

 

SI necesitas cambiar los casos día a día por que el análisis de los datos asñi lo requiere, unas kettle, a mi no me gusta por que es Java (odio java) pero de lo OS es el mejor a mi parecer.

Heh, dejas de recomendar una herramienta solo porque odias el lenguaje en el que está hecho? Me parece bastante retrogrado,

Dije que a MI no me gusta, pero es cuestión de estilo, tu le dices retrogrado, yo le digo especialista, es muy complicado ser igual de bueno en todo, y nosotros decidimos python + framework XXX pero no es retrogrado es cuestión de gustos.
 

a estas alturas del partido que eso siga sucediendo. Yo por lo menos no le tengo mucho amor a Perl, pero si me preguntan por un manejador de tickets, recomendaria de una vez Request-Tracker, hands down.

Dije que YO no lo uso,   pero lo estoy recomendando y....

 

He sacado data desde casi 10 motores de BD y siempre pongo éstos datos en postgres.

Pentaho es la herramienta BI no el ETL el ETL es realmente http://kettle.pentaho.com/

Esta  es la herramienta _mejorcita_ para eso. Estuve usandola por bastante tiempo, y aún cuando resuelve el problema, la interfaz en algunos casos deja mucho que desear. Y en este caso, la interfaz tiene importancia, porque el API para crear programaticamente las ETL es horrible, pero el workflow de crear ETLS y luego llamarlas programaticamente si es excelente. 

Tamos de acuerdo!
 

Saludos.

 

--
Gerardo Curiel

_______________________________________________
l-desarrollo mailing list
l-desa...@velug.org.ve
http://listas.velug.org.ve/mailman/listinfo/l-desarrollo

[Juan Miguel Paredes]

2012/3/30 Alfredo Rico <alfre...@gmail.com>:

> Buen día amigos. Reciban un cordial saludo.
> Alguno de ustedes ha tenido experiencia con la utilización de
> herramientas opensource para hacer ETL hacía una base de datos
> postgres.
> La idea es que se tienen un conjunto de archivos planos y pues
> facilitaría mucho las cosas si se contara con un ETL para definir las
> reglas de carga de dichos arcvhivos y evitar desarrollar un proceso de
> carga manual ya que se implican muchas verificaciones en los archivos
> planos (expresiones regulares, integridad referencial,
> normalización/desnormalización).
> He visto que existe por allí Pentaho y SpagoBI, entre otros pero
> quisiera saber si pueden compartir alguna experiencia.
>

Kettle y Talend, específicamente para ETL. La primera, aparte de la
buena cantidad de componentes prediseñados (con lo que en muchos
casos, tu trabajo de ETL se reduce a armar piezas), permite la
ejecución remota y distribuida de los trabajos. La última tiene la
ventaja de poder exportar el trabajo en Perl ;)

Saludos,

Juan M. Paredes A.