HDFS는 RDBMS와는 다르게 기존 데이터를 업데이트해서 사용하는데 적합하지 않다. 하지만 로그성 데이터가 아니라 상태값이나 변할 수 있는 값을 가지는 데이터인 경우 변경 사항이 계속 발생하고 이것을 주기적으로 반영해야할 필요성이 있을 수 있다. 예를 들어 상품 판매 순위를 집계하려면, 상품 판매 로그와 상품 자체에 대한 정보가 있어야 한다. (로그에 상품에 대한 정보를 포함시킬 수도 있지만 최신 정보를 얻으려면 별도 정보가 필요할 것이다.) 로그는 변하지 않는 데이터이지만 상품에 대한 정보는 상품명, 카테고리 등이 계속 변할 수 있다. 이런 경우 데이터 전체 크기가 그렇게 크지 않은 경우 전체 데이터를 주기적으로 새로 dump할 수 있다. (Sqoop 등을 활용해서) 하지만 전체 데이터 크기가 커서 ..
에이브로 (Avro) 아파치 에이브로는 더그 커팅이 개발한 언어에 중립적인 스키마 기반의 데이터 직렬화 프레임워크이다. 데이터를 네트워크를 통해 전송하거나 저장하기 위해서는 데이터를 직렬화해야한다. 하둡 Writable 클래스들은 언어 이식성이 없기 때문에 에이브로는 하둡에서 데이터를 직렬화하는데 선호되는 도구이다. 스키마 스키마는 JSON을 사용하여 정의된다 [User에 대한 스키마 예제 (user.avsc)] { "namespace": "example.avro", "type": "record", "name": "User", "fields": [ {"name": "name", "type": "string"}, {"name": "favorite_number", "type": ["int", "null"]}..
태블로(tableau) BI(Business Intelligence) 툴에서는 다양한 형태의 데이터들을 연동하여 분석할 수 있다. 엑셀 파일, csv 파일, MySQL, Oracle, HDFS, HIVE, Google drive, drop box 등... 1회성으로 분석하고 끝날 것이 아니라 엔터프라이즈 환경에서 지속적으로 사용할 시스템을 만들려면 데이터 구성을 잘 해둘 필요가 있는데 이를 위한 내용을 정리해본다. 아직 그렇게 경험이 많지 않지만 알아가고 있는 내용을 정리하는 것이다. 데이터 원본을 구성할 때 단일 테이블로만 구성할 때는 크게 고민할 것이 없는데 여러 테이블을 묶어서 데이터 원본을 구성할 때는 좀 생각해봐야할 부분들이 있다. 일단 테이블을 연결하는 방법에는 조인과 관계 방식이 있다. 조인..
분석을 위한 명령어들 모두 JDK 설치되어 있으면 실행을 위해 별도 설치할 것은 없음 스레드 덤프 생성 jstack -l > # jstack -l 3435 > /home/user/jstack.txt 정확한 원인 분석을 원한다면 5초 정도 간격으로 5회 정도 생성 필요 (스레드 상태 변화 확인을 위해) 힙덤프 생성 힙덤프 생성 중 Stop the world 되기 때문에 주의 (시간은 오래걸려도 수초내일 듯하다) jcmd GC.heap_dump # jcmd 3435 GC.heap_dump /home/user/heap_dump.hprof 클래스 로드 현황 확인 명령 실행 시 Stop the world 되기 때문에 주의 jcmd GC.class_stats # -csv=true 옵션을 추가하면 csv형태로 출력 ..
Spring framework의 KerberosRestTemplate를 사용해서 HDFS REST API를 통해 파일 다운로드, 업로드하는 예제이다. 일단 KerberosRestTemplate을 사용하기 위한 의존성 설정이 필요하다. org.springframework.security.kerberos spring-security-kerberos-client 1.0.1.RELEASE 예제 코드 import org.apache.commons.lang3.BooleanUtils; import org.apache.http.auth.AuthSchemeProvider; import org.apache.http.auth.AuthScope; import org.apache.http.auth.Credentials; imp..
서비스 개발 및 운영을 하다보면 크고 작은 문제들이 생기기 마련이다. 문제가 하나도 발생하지 않는게 가장 좋겠지만, 그렇게 하기는 쉽지 않다. 그렇다고 문제 발생이 두려워 서비스 기능 추가나 코드 수정을 안할 수는 없는 노릇이다. "구더기 무서워 장 못 담글까"라는 말처럼.. 95%의 완성도에서 100%의 완성도로 가기 위해서는 0%에서 95%로 가기위해 들였던만큼의 노력이 필요한 경우가 많다. 100% 완벽한 무장애 시스템을 만드는 것을 최우선 목표로 하게되면 안정성은 높아지겠지만 그만큼 서비스 기능 추가에는 시간이 걸리게 될 것이다. 그리고 개발자의 스트레스 지수와 불안감도 올라갈 것이다.. 서비스에 기능 추가도 빨리 빨리 하면서 무장애 시스템을 만드는 것은 일반적인 수준의 노력만으로는 불가능할 것이..
