빅 데이터 분석을 위한 시작점. 데이터 수집!!

<p><font face="나눔고딕"></font> </p> <p><font face="나눔고딕">빅 데이터 분석을 위해서는 당연히 입력 데이터가 있어야 한다. 그리고 과연 빅 데이터에서 입력 데이터라는 것은 무엇인지에 대한 것도 정리가 필요할 듯 하다.</font></p> <h4>데이터 수집</h4> <p><font face="나눔고딕">하둡의 배치 처리가 아무리 훌륭하고, 클러스터의 규모가 아무리 크다고 해도 일단 데이터가 하둡의 파일시스템 (HDFS) 에 저장되어 있어야 하며, 실 시간으로 처리를 하고 싶어도 처리할 데이터가 원하는 시간 내에 실 시간 처리 프로세서로 전달되지 않으면 아무 소용도 없다.</font></p> <p><font face="나눔고딕">분석에 필요한 데이터가 데이터베이스에 저장되어 있었다면 분석 용도에 맞게 데이터를 가공 처리하거나 변환 작업등의 분석 업무를 수행할 수 있겠지만, 데이터가 파일 시스템으로 저장되어 있다면 데이터의 포맷이나 형식이 상이하기 때문에 원하는 데이터 형태로 변환하고 처리하는 프로그램을 직업 구현하거나 다양한 도구들을 이용해서 사전 작업을 한 후에 데이터베이스에 적재하는 작업이 필요하다. (즉, 비 정형 데이터를 정형화 데이터로 처리하는 과정이 필요하다는 의미)</font></p> <p><font face="나눔고딕">위와 같은 작업도 데이터들이 동일한 시스템에 있다면 다행이겠지만, 분석 대상이 될 데이터들이 서로 다른 별도의 시스템에 존재한다면, 이 데이터들을 가져오기 위한 데이터 수집 과정이 필요하다. 대량의 데이터라면 HTTP 나 별도의 전송 프로그램을 쓸 수도 있겠지만, 대부분은 FTP 들을 사용하는 경우가 많다. 보안 문제가 있다면 SFTP 를 이용하면 되지만 FTP라는 것이 트랜잭션을 지원하지 않기 때문에 데이터가 정확하게 주고 받아진 것인지를 확인하기가 어렵다는 단점이 존재한다. 따라서 전송할 때는 전송의 완료여부를 검증하기 위해서 데이터 파일 뿐만 아니라 체크 파일도 같이 전송하는 방법을 쓰게 된다. </font><font face="나눔고딕">이런 문제들을 해결하기 위한 솔루션들로는 IBM의 MQ File Transfer Edition 과 같은 것들이 있다. (<a href="http://www.lusodata.pt/webluso/Data/Sites/1/pdf/rp-wsmqftesolutionoverview.pdf" target="_blank">참고자료</a>)</font></p> <p><font face="나눔고딕">현실적으로는 여러 개의 시스템과 연동해서 데이터를 가져오는 것이 문제가 아니라 시스템들에 연동되는 API 나 인터페이스들을 어떻게 관리할 것인지? 가 더 큰 문제가 된다. 그나마 시스템이 몇 개 되지 않는다면 어느 정도는 통제가 되고, 더한 경우는 수작업을 통해서라도 해결을 하겠지만, 대상 시스템이 수십, 수백, 수천이 넘어간다면 거의 불가능에 가깝다고 봐야 한다. 더욱이 이런 작업을 실 시간으로 한다면… </font></p> <p><font face="나눔고딕">일반적으로 데이터를 로그 파일로 생성하기는 하지만 유닉스에서는 syslog를 사용하고, 자바에서는 log4j 등을 사용하며, 시스템에 따라서 일관적인 규약을 정해서 따르는 것이 아니기 때문에 각 시스템마다 고유의 포맷을 가지고 있다고 봐야 한다. 그리고 로그의 유형도 웹 로그, 트랜잭션 로그, 클릭 로그 등으로 다양한 형태의 데이터들이 파일로 생성이 되고, 데이터베이스에 쌓이는 히스토리 데이터들도 수집의 대상이 될 수 있다. 따라서 이렇게 분산되어 있고, 다양한 포맷을 가지는 로그 데이터들을 일관된 방법으로 수집할 수 있는 잘 설계된 로그 수집 프레임워크 (Log Aggregator Framework) 는 빅 데이터에서 반드시 필요하고, 우선적으로 고려해 봐야 할 부분이다.</font></p> <p><font face="나눔고딕">아마도 가장 많이 쓰이는 것으로 보이는 스플런크 (<a href="http://www.splunk.com/" target="_blank">splunk</a>) 는 무료 버전과 엔터프라이즈 버전으로 제공이 되며, 엔터프라이즈 버전은 하둡과 통합이 되어 HDFS에 데이터를 저장하고 분석될 수 있도록 업그레이드가 된 것으로 보인다. 하지만 하둡 에코 시스템의 측면에서 관심을 가져야 할 로그 수집기는 클라우데라에서 제공하는 플룸(<a href="https://github.com/cloudera/flume/wiki">Flume</a>) 일 것이다. </font></p> <p><font face="나눔고딕">플룸은 데이터 수집을 위한 다양한 데이터 플로우 토폴로지를 구성할 수 있고 마스터 노드에서 통합 관리할 수 있는 웹 페이지를 제공하며, 이를 통해서 변경 및 모니터링이 가능하다. 거기에 마스터 노드를 이중화해서 가용성과 안정성을 높인 것도 장점이다. 물론 구현이 자바로 구현되어 있기 때문에 다양한 운영체제에 설치가 가능하다. 그리고 데이터 저장소가 기본적으로 HDFS 를 사용하는 것을 전제로 하고 있기 때문에 하둡과 잘 통합될 수 있다.</font></p> <p><font face="나눔고딕">결론적으로는 빅 데이터를 활용하기 위한 가장 기본적이지만 간과될 수 있는 부분이 데이터 연동, 수집이라는 것을 항상 염두에 두고 있어야 한다는 점이다. 빅 데이터를 위한 서비스 시스템을 구축할 예정이라면 로드 데이터 수집을 위한 에이전트들을 어떻게 구성할 것이며, 이런 에이전트들이 분석 서비스를 위한 서버에 얼만큼의 영향을 주게 될지도 검토해 보아야 한다. 이런 복잡성과 구현의 미비한 점들은 현실적으로 아직도 FTP를 이용하는 쪽으로 갈 수 밖에는 없는 상황을 만들고 있다. 물론 FTP를 이용하는 것이 나쁘다는 것은 아니다. 다만 FTP 만으로는 한계가 있기 때문에 로그 수집기와 적절하게 운영될 수 있어야 한다는 점이다.</font></p> <p><font face="나눔고딕">이제 빅 데이터를 경험해 보려고 하는 입장에서는 구체적인 내용을 정리할 수는 없지만, 점진적으로 구체화 시켜서 정리를 해야 할 듯 하다. 이미 용도/기능 별로 많은 오픈 소스들이 존재하여 이를 검토하고 적용해 보는 것이 너무 많은 삽질을 필요로 하는 듯 하다. 아무래도 더 많은 자료와 경험 사례들을 찾아 봐야 할 듯…</font></p>

 

빅 데이터 분석을 위해서는 당연히 입력 데이터가 있어야 한다. 그리고 과연 빅 데이터에서 입력 데이터라는 것은 무엇인지에 대한 것도 정리가 필요할 듯 하다.

데이터 수집

하둡의 배치 처리가 아무리 훌륭하고, 클러스터의 규모가 아무리 크다고 해도 일단 데이터가 하둡의 파일시스템 (HDFS) 에 저장되어 있어야 하며, 실 시간으로 처리를 하고 싶어도 처리할 데이터가 원하는 시간 내에 실 시간 처리 프로세서로 전달되지 않으면 아무 소용도 없다.

분석에 필요한 데이터가 데이터베이스에 저장되어 있었다면 분석 용도에 맞게 데이터를 가공 처리하거나 변환 작업등의 분석 업무를 수행할 수 있겠지만, 데이터가 파일 시스템으로 저장되어 있다면 데이터의 포맷이나 형식이 상이하기 때문에 원하는 데이터 형태로 변환하고 처리하는 프로그램을 직업 구현하거나 다양한 도구들을 이용해서 사전 작업을 한 후에 데이터베이스에 적재하는 작업이 필요하다. (즉, 비 정형 데이터를 정형화 데이터로 처리하는 과정이 필요하다는 의미)

위와 같은 작업도 데이터들이 동일한 시스템에 있다면 다행이겠지만, 분석 대상이 될 데이터들이 서로 다른 별도의 시스템에 존재한다면, 이 데이터들을 가져오기 위한 데이터 수집 과정이 필요하다. 대량의 데이터라면 HTTP 나 별도의 전송 프로그램을 쓸 수도 있겠지만, 대부분은 FTP 들을 사용하는 경우가 많다. 보안 문제가 있다면 SFTP 를 이용하면 되지만 FTP라는 것이 트랜잭션을 지원하지 않기 때문에 데이터가 정확하게 주고 받아진 것인지를 확인하기가 어렵다는 단점이 존재한다. 따라서 전송할 때는 전송의 완료여부를 검증하기 위해서 데이터 파일 뿐만 아니라 체크 파일도 같이 전송하는 방법을 쓰게 된다. 이런 문제들을 해결하기 위한 솔루션들로는 IBM의 MQ File Transfer Edition 과 같은 것들이 있다. (참고자료)

현실적으로는 여러 개의 시스템과 연동해서 데이터를 가져오는 것이 문제가 아니라 시스템들에 연동되는 API 나 인터페이스들을 어떻게 관리할 것인지? 가 더 큰 문제가 된다. 그나마 시스템이 몇 개 되지 않는다면 어느 정도는 통제가 되고, 더한 경우는 수작업을 통해서라도 해결을 하겠지만, 대상 시스템이 수십, 수백, 수천이 넘어간다면 거의 불가능에 가깝다고 봐야 한다. 더욱이 이런 작업을 실 시간으로 한다면…

일반적으로 데이터를 로그 파일로 생성하기는 하지만 유닉스에서는 syslog를 사용하고, 자바에서는 log4j 등을 사용하며, 시스템에 따라서 일관적인 규약을 정해서 따르는 것이 아니기 때문에 각 시스템마다 고유의 포맷을 가지고 있다고 봐야 한다. 그리고 로그의 유형도 웹 로그, 트랜잭션 로그, 클릭 로그 등으로 다양한 형태의 데이터들이 파일로 생성이 되고, 데이터베이스에 쌓이는 히스토리 데이터들도 수집의 대상이 될 수 있다. 따라서 이렇게 분산되어 있고, 다양한 포맷을 가지는 로그 데이터들을 일관된 방법으로 수집할 수 있는 잘 설계된 로그 수집 프레임워크 (Log Aggregator Framework) 는 빅 데이터에서 반드시 필요하고, 우선적으로 고려해 봐야 할 부분이다.

아마도 가장 많이 쓰이는 것으로 보이는 스플런크 (splunk) 는 무료 버전과 엔터프라이즈 버전으로 제공이 되며, 엔터프라이즈 버전은 하둡과 통합이 되어 HDFS에 데이터를 저장하고 분석될 수 있도록 업그레이드가 된 것으로 보인다. 하지만 하둡 에코 시스템의 측면에서 관심을 가져야 할 로그 수집기는 클라우데라에서 제공하는 플룸(Flume) 일 것이다.

플룸은 데이터 수집을 위한 다양한 데이터 플로우 토폴로지를 구성할 수 있고 마스터 노드에서 통합 관리할 수 있는 웹 페이지를 제공하며, 이를 통해서 변경 및 모니터링이 가능하다. 거기에 마스터 노드를 이중화해서 가용성과 안정성을 높인 것도 장점이다. 물론 구현이 자바로 구현되어 있기 때문에 다양한 운영체제에 설치가 가능하다. 그리고 데이터 저장소가 기본적으로 HDFS 를 사용하는 것을 전제로 하고 있기 때문에 하둡과 잘 통합될 수 있다.

결론적으로는 빅 데이터를 활용하기 위한 가장 기본적이지만 간과될 수 있는 부분이 데이터 연동, 수집이라는 것을 항상 염두에 두고 있어야 한다는 점이다. 빅 데이터를 위한 서비스 시스템을 구축할 예정이라면 로드 데이터 수집을 위한 에이전트들을 어떻게 구성할 것이며, 이런 에이전트들이 분석 서비스를 위한 서버에 얼만큼의 영향을 주게 될지도 검토해 보아야 한다. 이런 복잡성과 구현의 미비한 점들은 현실적으로 아직도 FTP를 이용하는 쪽으로 갈 수 밖에는 없는 상황을 만들고 있다. 물론 FTP를 이용하는 것이 나쁘다는 것은 아니다. 다만 FTP 만으로는 한계가 있기 때문에 로그 수집기와 적절하게 운영될 수 있어야 한다는 점이다.

이제 빅 데이터를 경험해 보려고 하는 입장에서는 구체적인 내용을 정리할 수는 없지만, 점진적으로 구체화 시켜서 정리를 해야 할 듯 하다. 이미 용도/기능 별로 많은 오픈 소스들이 존재하여 이를 검토하고 적용해 보는 것이 너무 많은 삽질을 필요로 하는 듯 하다. 아무래도 더 많은 자료와 경험 사례들을 찾아 봐야 할 듯…