이번에 ETL 작업을 하면서 겪은 당황스런 일을 적어두려합니다. 이번 작업은 아래에 설명할 두가지이며, 작업 환경은 다음과 같습니다.
세대의 장비는 모두 같은 건물 안에 있습니다. 멀리 넷트웍을 타고 전송되는 상황은 아닙니다.
ETL tool : GeoKettle
DBMS : PostgreSQL 9.x, Kairos 5.x


1. PC(1 cpu)에 설치된 PostgreSQL DB에서 데이타를 추출하여 서버(4 cpu)상의 PostgreSQL DB에 전송하는 작업.

2. 서버(4 cpu)상의 PostgreSQL DB에서 데이타를 추출하여 다른 서버(4 cpu)상의 Kairos DB에 데이타를 전송하는 작업.

1번 작업은 데이타 원본이 윈도우가 설치된 PC상에 있어서인지 오래 걸렸습니다. 더군다나 테이블끼리 1대 1로 전송하는게 아니라 원본에서 조인을 해서 추출을 하는 작업이었습니다. 오래걸리더군요. 이건 각오한 문제였구요.

그런데... 2번 작업에서 큰 문제가 생겼습나다. Kairos는 메모리 DB인데 데이타 로딩이 아주 느리더군요. 이건 뭐...
서버에서 서버로 보내는 것이고, 테이블도 거의 1대 1로 전송하는 상황이었고, 메모리도 각각 50GB 정도 설치되어 있었습니다. 더군다나 아직 서비스에 쓰이는 장비도 아닌데 초당 270건 정도밖에 안되더군요. ㅠㅠ

그래서 눈물을 머금고 text로 추출해서 로딩하는 방식을 썼습니다.

한가지 더 문제가 있었는데, GeoKettle로 Kairos에 데이타를 이전할때 not null 제약이 걸린 컬럼에 null 값이 들어가면 오류가 발생하지 않고 행이 걸린것처럼 멈춰 있더군요. jdbc 드라이버 문제인지 GeoKettle의 문제인지 모르겠습니다. 암튼 이 문제땜에 에러가 안 뜨니 좀 기다려보자는 생각에 시간을 많이 소비했었죠.




사용한 툴과 디비를 보시면 아시겠지만 gis 관련 데이타를 다루는 작업이었습니다. 문제는 Kairos는 GeoKettle이 지원하지 않는 제품이라 이 툴로는 일반적인 문자, 숫자 등의 데이타가 아닌 공간 데이타는 Kairos로 이전을 할 수가 없었습니다. 오픈소스인 Pentaho Kettle 기반의 제품이니까 공부를 좀 해서 Kairos의 공간 데이타를 인식할 수 있게 만들어 보고 싶다는 생각을 해봅니다. 실제로 진행을 할 수 있을지는 모르겠습니다만...

그럼 평온한 밤 보내시길~~~

iPhone 에서 작성된 글입니다.
신고
YOUR COMMENT IS THE CRITICAL SUCCESS FACTOR FOR THE QUALITY OF BLOG POST


그동안 오픈소스 ETL툴인 Pentaho kettle을 업무에 도입하기 위해 그리고 개인적으로 공부를 해왔었는데, 큰 문제를 만나게 되었습니다. 바로 지리공간정보를 다루게 되니... 데이터형 문제가 발생하더군요. 그래서 구글님께 물어봤더니 답을 주시더군요.

GeoKettle입니다.

www.spatialytics.org

이 툴은 오픈소스 ETL 툴인 Pentaho Kettle에 지리정보를 다룰 수 있도록 - spatial data type을 인식하도록 플러그인( 이게 맞는지는 아직 확인 중입니다. )이 미리 설정되어 있습니다.

PostGIS가 설치된 PostgreSQL에서 테스트 해본 결과 100만건의 geometry형의 data를 전송하는데 별다른 문제는 없었습니다. 160초 가량 걸리더군요. 원본 디비가 개인 PC라서 좀 느린게 아니었을까 생각합니다.

한가지 단점이라면 Big data 관련 기능이 추가된 Kettle 4.3버전이 아니라 4.2 버전을 기반으로 했는지 Big data관련 기능이 일부 빠진것 같더군요. 이 부분은 곧 해소되지 않을까 생각합니다.

더 자세한 기능 분석은 좀 더 사용해본 뒤에 작성하겠습니다.

iPhone 에서 작성된 글입니다.
신고
YOUR COMMENT IS THE CRITICAL SUCCESS FACTOR FOR THE QUALITY OF BLOG POST


Postgres-XC로 시스템을 구축하려고 공부 중입니다. 아직 보기 좋게 정리는 못 했고 우선 간단히 장단점을 적어보려합니다.
회사에서 외부 사이트를 거의 막아놔서 아이폰에서 작성하는거라 글로만 설명하는 점 이해해주시길 바라며...

1. 장점
1.1. Open source라 구축 가능한 인력과 시간, 그리고 장비만 있으면 소프트웨어 라이선스 비용은 들지 않는다.

1.2. 읽기 및 쓰기 부하 분산이 가능하다.

1.3. Oracle RAC처럼 어플리케이션에서는 읽고 쓰는것을 구분하여 디비 접속을 하지 않아도 된다. 전체 노드가 읽기 및 쓰기가 가능하다.

2. 단점
2.1. 1.0 버전이 출시된지 몇달되지 않아서 구축 사례와 한글로 된 자료 등이 거의 없다.

2.2. PostgreSQL 9.1.x 버전에서만 사용 가능하다. 고로 이전 버전을 쓰고 있다면 업그레이드를 해야한다.

2.3. Trigger를 지원하지 않는다.
현재로는 지원하기 어렵다고한다.

2.4. 관리 툴의 부재
기존의 pgAdmin으로는 접속시 오류가 발생하여 관리가 불가능하다.

2.5. 트랜잭션의 문제
펑션 내부에서 dynamic query를 이용하여 update를 하도록 만들어서 여러세션에서 사용했을때, 트랜잭션을 걸어서 사용하면 일부 update문이 실행되지 않는 문제 발생.
설정의 문제인지 버그인지 확인 중입니다.

그런데 위의 문제로인해서 일단 업무에 Postgres-XC을 도입하는것은 보류한 상태입니다.


iPhone 에서 작성된 글입니다.
신고
YOUR COMMENT IS THE CRITICAL SUCCESS FACTOR FOR THE QUALITY OF BLOG POST