빅데이터(Big Data) 분석의 시작, 데이터 수집 그리고 로그 수집기(Log Aggregator) 솔루션들

지난 12월초에 3월초까지 빅데이터에 대한 글을 포스팅하고 나서 전반적인 내용들을 대부분 정리했다고 생각하면서도 무언가 빠진 듯한 느낌이 있었는데 지난 주 어느 분과 이야기를 나누면서 빠진 부분이 무엇인지 퍼뜩 생각이 났습니다.

데이터 프로세싱을 하면서 제일 중요한 부분이면서 간과하기 쉽고 무엇보다 실무에 있어서는 가장 괴롭고 힘든 업무 영역이 바로 데이터 수집에 대한 것입니다. 결국은 데이터를 분석하기 위해서는 데이터를 수집하는 것부터 시작을 해야 하겠지만 이 데이터 수집이라는 것이 그렇게 만만한 일이 아닙니다.

아시다시피 하둡의 배치 프로세싱 성능이 아무리 좋아봐야, 클러스터의 규모가 아무리 커도 일단 HDFS에 데이터가 저장이 되어 있어야하고 실시간 처리를 하고 싶어도 처리할 데이터가 원하는 시간내에 실시간 프로세서로 전달이 되지 않는다면 아무 소용이 없기 때문입니다.

다행이 분석에 필요한 데이터들이 초기부터 데이터베이스에 저장되어 있었다면 분석 용도에 맞게 데이터베이스에서 데이터를 가공 처리하거나 변환작업을 통해서 원하는 분석 업무를 할 수 있겠지만 분석을 해야 하는 데이터들이 파일 시스템의 파일 형태로 저장되어 있다면 그 데이터의 포맷이나 형식이 상이하기 때문에 원하는 데이터 형태로 변환하고 처리하는 프로그램을 직접 구현하거나 유닉스에 마련된 다양한 유틸리티들을 이용해서 사전에 프리프로세싱을 해서 데이터베이스에 적재하는 작업이 필요합니다.

이것도 해당 데이터들이 같은 시스템에 있는 경우라면 그나마 낫겠죠. 하지만 분석해야 하는 데이터들은 해당 서비스가 운영되는 별도의 시스템에 저장되어 있거나 시스템의 로그 서버에 따로 저장되어 있기 마련입니다. 따라서 우선 분석을 해야 하는 데이터를 가져오는 일부터 데이터의 수집은 시작됩니다. HTTP 을 이용하거나 별도의 전송 프로그램을 이용해서 데이터를 전달할 수도 있겠지만 일반적으로 대용량의 데이터 전송을 위해서 대부분 ftp 을 사용하게 됩니다. 보안이 이슈가 된다면 방화벽 설정과 sftp 를 이용하기도 합니다. 문제는 이 ftp 가 그렇게 안정적이지 못하기도 하고 기본적으로 트랜잭션이라는 것을 지원하지 않기 때문에 대부분 ftp 을 이용하는 경우 데이터를 전송해주는 쪽과 데이터를 받아서 사용하는 쪽에서 데이터가 정확히 전달되었는지 확인할 수 있도록 전송파일과 함께 체크파일을 함께 전송하도록 하고 있습니다.

하지만 이 역시 완벽하지 않죠. 그래서 이러한 데이터 전송에 대한 notification 과 트랜잭션관리등을 위한 상용 솔루션들도 있습니다. 예를 들어 IBM의 MQ File Transfer Edition 같은 것입니다. 기본적인 데이터 전송 프로토톨은 ftp 을 사용하지만 안정적으로 데이터 전송을 하는데 필요한 처리를 맡아서 해주는 역할을 해주는 것이죠. ( 참고: http://www.lusodata.pt/webluso/Data/Sites/1/pdf/rp-wsmqftesolutionoverview.pdf) 찾아보니 기업내, 기업간 데이터 전송을 위한 IBM의 토탈(?) 솔루션도 있네요. (http://www.redbooks.ibm.com/abstracts/sg247927.html) 여담이지만 IBM은 없는 솔루션이 없는 것 같아요. ^^

현실적으로 십수개의 시스템과 연동을 해서 데이터를 가져오는 작업 자체가 그렇게 기술적인 난이도가 있는 것은 아닙니다. 문제는 이렇게 연동되는 연동 인터페이스에 대한 관리를 어떻게 하면 제대로 하는가가 가장 큰 문제라고 할 수 있습니다. ftp 기반으로 데이터를 연동하는 경우에는 별도의 프로세스가 연동 시스템의 체크파일등을 확인하면서 연동된 결과를 일일히 파악해야 하는 어려움이 있습니다. 만일 장애가 발생하면 재시도하는 작업을 해야 하는데 많은 경우 수작업에 의존하는 경우도 많은 것이 사실입니다. 물론 상용솔루션을 구매하거나 이에 준하는 유틸리티를 개발하면 되겠지만 생각보다 만만한 작업은 아닐 것입니다.

그나마 데이터를 수집을 위해서 연동을 해야 하는 시스템이 십수개라면 어느 정도 통제하에 데이터를 수집하고 처리할 수 있겠지만 만일 수집해야 하는 물리적인 시스템의 수가 수십, 수백, 수천개가 된다면 어떻게 해야 할까요? 더불어 각 시스템에서 돌아가는 각종 서비스들로 부터 발생하는 로그의 종류까지 생각해본다면? 게다가 ftp 와 같은 배치작업이 아니라 실시간성으로 데이터를 수집해야 한다면 이러한 작업은 그렇게 쉽지 않겠죠.

전통적으로 유닉스에서의 로그 수집은 syslog을 사용해왔습니다. 자바에서는 Log4j을 많이 사용하고 있었지만 문제는 각종 서비스들은 이러한 표준화된 도구에서 제공하는 규약을 지켜서 로그를 쌓기도 하지만 서비스 자체에서 정의한 고유의 포맷으로 각종 로그 데이터들이 저장되게 됩니다. 소위 웹로그, 트랜잭션로그, 클릭로그 등 다양한 형태의 로그 데이터가 쌓이게 되는 것이죠. 아참, 이 밖에도 데이터베이스에 저장되는 로그데이터(히스토리데이터) 들도 수집해야하는 대상이 되는 데이터들이 되겠습니다.

그래서 이러한 흩어져 있는 각종 로그 데이터를 일관된 방법으로 수집할 수 있는 잘 설계된 로그 수집 프레임워크(Log Aggregator Framework) 는 빅데이터 분야에서 반드시 필요하고 고려해야 할 부분입니다.

아마도 이러한 로그 관리 도구로 가장 유명한 것중 하나가 스플런크(splunk) 일 것입니다. 프리 버전과 엔터프라이즈 버전을 제공하고 있고 이쪽 분야에서는 많이 알려지고 많이들 활용하고 있는 것 같습니다. 최근 엔터프라이즈 버전에서는 하둡과 통합이 되어서 HDFS에 데이터를 저장하고 하둡에서 분석 프로세싱을 할 수 있도록 업그레이드가 되었습니다. 웹 기반의 GUI을 제공하고 있어서 그 사용성이나 관리적인 측면에서는 매우 큰 강점이 있을 것 같습니다. 그런데 공개된 자료로는 대충 짐작만 할 수 있어서 정확하게 파악이 안되네요. 혹시 잘 아시는 분이 댓글을 달아주시면 큰 도움이 될 것 같습니다. 예산을 어느 정도 확보하고 안정된 솔루션을 확보하고 비용 투자할 의사가 있는 기업에서는 splunk가 괜찮은 솔루션으로 보입니다.

하지만 하둡 에코시스템 측면에서 관심을 가져야 할 로그 수집기(Log aggregator)는 Flume 입니다.

사실 재작년쯤에 페이스북이 공개한 Scribe 을 검토하고 개발팀내에서 HDFS를 지원할 수 있도록 개발한 적이 있습니다만 제대로 활용을 할 수가 없었습니다. 가장 큰 이유는 기존 시스템에 Scribe을 설치할 수 있는 여건과 상황이 되질 않았기 때문이였습니다. 네 맞습니다. 레가시 시스템을 쉽게 건드릴 수는 없습니다.

그런데 최근 Flume 에 대해서 다시 검토를 해보니 맘에 쏙 들게 만들어져 있더군요. (Thanks, Cloudera!) 무엇보다도 데이터 수집을 위한 다양한 데이터 플로우 토폴로지를 구성할 수 있고 마스터 노드에서 통합 관리할 수 있는 웹페이지를 제공할 뿐만 아니라 이를 통해서 설정을 쉽게 변경하거나 모니터링이 가능하다는 것입니다. 뿐만 아니라 마스터 노드를 이중화하여 가용성이 크게 높아져 있더군요. 게다가 자바로 구현되어 있어서 다양한 오에스 플랫폼에 포팅이 되어 있다는 것입니다. MS윈도우서버, 각종 유닉스/리눅스 서버에 설치해서 로그 데이터 수집이 가능합니다. 당연히 데이터 저장소가 기본적으로 HDFS 라는 것으로 전제하였기 때문에 하둡과 매우 잘 통합되어 있기도 합니다.

반면 공개된 Scribe 소스코드는 더이상 업데이트도 되고 있지 않고 데이터 수집을 하는 각 노드에 대한 모니터링도 쉽지않습니다 또한 설정도 rshell 을 이용해야 하는 등 불편함이 있습니다.

물론 Scribe 은 페이스북 내부에서 실시간 데이터 프로세싱을 위해서 잘 활용되고 있는 것으로 보입니다만 단순히 Scribe 만 활용하는 것이 아니라 Calligrapuhs 라는 Scribe 와 호환되는 자바로 쓰여진 프로그램(Flume의 Collector와 같은 역할) 과 Ptail, Puma, hbase 와 같은 프로그램과 결합되어져 가능해진 것이죠. 아직 오픈소스로 공개되지는 않았습니다.(참고: http://borthakur.com/ftp/SIGMODRealtimeHadoopPresentation.pdf)

오늘은 빅데이터 분야에서 쉽게 간과할 수 있는 데이터 연동, 수집에 관한 얘기와 관련 솔루션에 대해서 얘기를 해보았습니다. 사실 flume 이든 scribe 이든 이를 잘 활용해서 좀 더 있어보이는(?) 데이터 플랫폼을 구축하고 싶지만 현실은 그렇게 녹녹치 않다는 것입니다. 여전히 서비스 시스템들은 분석 시스템들과 동떨어져 있고 서비스 구축시에 분석 환경에 대한 것들을 충분히 고려하고 있지 않기 때문에 위와 같은 것들을 바로 적용하기에는 여러가지 어려움이 있습니다. 로그데이터 수집을 위한 에이전트들이 서비스 서버의 성능에 얼마만큼 영향을 주는지도 충분히 검토해야 하고 서비스를 하는 쪽에 수집 에이전트를 설치했을 때 그 영향이 어떠한지 객관적으로 정보를 제공도 해야 합니다. 이러다보니 현실적으로 각 시스템 관리 책임을 명확 구분하기 위해서 데이터 연동/수집을 위해서 ftp 를 적용하자는 쪽으로 결론 나는 것이죠. 사실 대부분의 경우 큰 문제가 없고 안정적이기 때문에 ftp 를 잘 활용하는 것도 좋은 방법이구요.

저에게 하둡기반으로 로그데이터 수집을 위한 솔루션을 선택하라면 Flume 과 FTP 을 적절히 활용해야 한다고 말씀드리고 싶다는 걸로 오늘 포스팅은 마무리 지을까 합니다.

아! 맞다.  FUSE 얘길 하지 않았군요. ^^

Advertisements
이 글은 IT 카테고리에 분류되었고 , , , , 태그가 있습니다. 고유주소 북마크.

빅데이터(Big Data) 분석의 시작, 데이터 수집 그리고 로그 수집기(Log Aggregator) 솔루션들에 1개의 응답

  1. flume으로 하둡에 로그를 남기는 경우 하나의 파일에 계속 append되지 않고, 매번 가져올 때마다 파일을 만들어서 이게 좀 불편하던데, 혹시 해결하신 방법이 있으신가요? 개인적으로 그래서 그냥 hbase plugin 수정해서 저장을 했었는데요.

    • kimws댓글:

      제 글을 잘 읽어보시면 알겠지만 아직 저는 flume을 실무에 활용하고 있지 않습니다. 하지만 flume 의 사용자 매뉴얼 (http://archive.cloudera.com/cdh/3/flume/UserGuide/) 을 읽어보시면 3.5 절 Note 에 다음과 같은 내용이 나옵니다. 한번 참고하셔서 적용을 해보시는 것도 방법이 아닐까 생각됩니다.

      Note
      There are no guarantees that data written to an HDFS file is durable until the HDFS file is properly closed. Because of this, the collector sink periodically closes a file and creates a new one in HDFS. The default time between file rolls (close then open new) is 30s. If you are writing data at low throughput (<2MB/s) you may want to increase the default time by modifying the flume.collector.roll.millis and flume.agent.logdir.retransmit time properties in your flume-site.xml file.

    • TJune댓글:

      중간에 batch Decorator를 두어 Buffering 하거나, Sink를 커스텀하게 만들어서 요구조건에 맞게 개발하는것도 하나의 방법일듯 합니다.

  2. tykoh70댓글:

    간만에 뵙겠습니다. 우승님! 그간 잘 지내셨는지요?
    오늘 문득 오전미팅에서 우승님 이야기가 나와서 반가웠습니다.
    일신상에 변동이 있으시다는 이야기는 들었습니다.
    모쪼록 좋은 일과 즐거운 일이 함께 하실 수 있기를 빌겠습니다.
    그리고 조만간 제 지인과 함께 뵐 수 있는 시간이 있기를 기대해 보겠습니다. ㅋ~

    위에 말씀하신 Aggregator는 제 경우는 Splunk와 Flume이 해당되는군요.
    그러나 Splunk는 라이센스 및 과금 방식 때문에 도입을 꺼리는 기업들이 많아서 유사형태로 만들어서 활용하게끔 도와드리기는 합니다. 말 그대로 로그 취합만이죠.
    검색까지는 몰라도 분석은 아직 미완이라…ㅎ~

    제 경우는

    [조합.1]
    Altair Engineering의 PBSworks + 별도의 파일분산처리 프로세스 + Flume + HiQube + Microsoft SQL server 조합이 현재 사용하는 구성입니다만 뭐 큰 목적이 없는 그냥 제가 필요해서 사용하는 조합입니다. ㅋ~

    [조합.2]
    몇 가지 HPC기반에서 운용가능한 Service on demand 형태의 서비스들(이걸 SaaS 비슷한거라고 해야 하나요?) + Altair Engineering PBSworks(프로세스 제어 및 잡 스케쥴링을 위한 로드밴런서 입니다라고 말해두고 앞서 이야기한 HPC를 구성하게 해주는게 이녀석이라고 밝힙니다.) + Nimsoft Unified Manager (이것은 조금 재미난 TMS입니다. CA Technology에서도 AppLogic과 함께 사용하려고 생각만 하던데 아직 미구현된 상태입니다.) + Splunk (Flume으로 대체의 무리 없다면 선수교체 예정이지만…일단 비싸고 라이센스 방식이 귀찮아서 입니다…그러나 좋은건 사실입니다.) + HiQube(MOLAP 솔루션이죠. 이게 사용해보니 RDBMS로 운용되는 퍼포먼스DB들로부터 분석을 위한 용도로도 나쁘진 않더군요. 일종의 다운타임 및 장애처리 분석용으로 활용합니다만 좀 멋있게 표현해주자면 IT기반의 PCMS(Product cost management system)같은거라고 해둘 수 있겠습니다.) + (One of) NoSQL Engine(이건 용도에 따라 선택되어지는 엔진이 다르네요. ^___^;) + SmartMCS(자체 개발한 대용량 네트워크 분산처리 솔루션입니다만… 아직 메이져리그에는 정식데뷰를 안한 상태로 마이너리그에서만 실전에 투입되어 있습니다. 네트워크 인프라 엑세스단 제어를 위한 솔루션인데 구글에 팔아먹을라고 만든 녀석입죠. 여름에 컨퍼런스에서 공개예정입니다. ~___~;)이 해봤으면 하는 조합입니다만… 정.체.불.명…조.합. ㅋ~
    목적은 BaaS(Business as a Service)를 위한 테스트라고나 해두겠습니다.

    여하튼… 아직은 많은 시행착오를 필요로 하는 시점이다보니 딱히 뭐라 할 말이 없습니다.
    귀차니즘 덕분에 요즘은 오픈소스를 가능하면 줄이고 상용제품들과 통합하는 방향을 선호하고 있습니다. 밤샘하면서 일할 나이도 아니거니와…SI는 더더욱 싫어하다보니(쿨럭~!!! ~___~;) 있는거 가격만 적절하다면 조합해서 사용하는게 득인데다가 기업고객들이 오픈소스제품을 그닥 선호하지를 않아서…라고 핑계아닌 핑계를 대어봅니다. ㅋ~

    늘 생각하는거지만 이쪽일은 참 힘드네요. 진도 많이 빼고…
    이제는 저도 여러가지를 통합하고 설계하고 운영을 하는 일을 직접한다는게 힘들기도 합니다.
    그래서 요즘은 별도의 Implementation 조직을 협력으로 두고 운용할까 고민하고 있습니다.
    결국 협업의 모델로 방향을 잡고 업무영역을 쪼개고 있습니다.
    50이 되면 비즈니스 필드에서는 물러나고 연구소에서 연구나 하면서 살고 싶은게 소원입니다.

    조만간 뵐 수 있었으면 좋겠습니다. LinkedIn으로 연락처 남겨주시면 연락드리겠습니다.
    즐거운 하루 되세요! ^____^

    • kimws댓글:

      헉 제 얘기는 또 어디서 들으셨나요? 세상이 좁긴 좁군요 ^^

      • kimws댓글:

        덧붙여 고태영님 댓글을 보면 고수 앞에서 일천한 지식으로 글 몇줄 적는 제자신이 부끄럽다능. 잘 아시겠지만 보통 기업에 있어서는 당연히 오픈소스보다는 어느정도 인력지원 및 컨설팅이 가능한 솔루션을 원하죠. 오픈소스는 적용하는데 있어서 개발자들의 사전 검토가 필요하고 생각보다 검토/검증에 많은 리소스를 뺏기고 인력이 내부에 있지 않으면 유지하기도 쉽지 않죠.

  3. tykoh70댓글:

    아~! 오늘 또 구글 애널리틱스 어댑터가 있는 SaaS 기반의 BI솔루션인 Bime (http://bimeanalytics.com/) 이 전투욕구를 불러일으키네요. ㅠ__ㅠ
    역시 세상은 넓고 할 짓(?)은 많다는걸 느껴봅니다.

    요즘 저는 Azure기반에서 운용될 MS SQL과 SharePoint service의 BI 플랫폼에 관련해서 이런저런 단상에 빠져있습니다. 지난번 마이크로소프트 BI플랫폼 컨퍼런스에 다녀온 이후로 말입니다.
    일단 마이크로소프트가 뒤쳐져있고 별 볼일 없어보여도 제 눈에는 그렇게 안보입니다.
    뭐 아직 제품들간의 포지셔닝에서는 있는거 팔아먹으려다보니 삽질을 일부러 하고 있는거 같아 보이기도 합니다만… 예를 들자면 MS SQL 2012에서 DW를 구성하고 Office 2012버전에 파워피보팅을 기준으로하여 데이터 취합과 분석 그리고 SharePoint로의 디스트리뷰션과 브로드캐스팅을 구현하고도…(세상에나…~___~;) Visual Studio로 리포트를 내려보내는 만행(?) 같은게 말입니다.
    도데체 MS는 왜 그럴까요?
    이 불편한 진실…
    고작 SQL좀 팔아보자고 유저친화적인 오피스 도구와 쉐어포인트 조합으로 충분할 BI레벨을 VS까지 내려보내고 삽질하게 하는 이유가 뭘까요?
    이미 엑셀레벨에서 충분히 분석과 What if, Aggregation, Optimization이 가능할텐데 말입니다. (물론 어느정도는 그 자체로 가능하겠지만 어드밴스드한 영역은 F#같은 녀석이 스크립트 레벨로 지원이 된다는 전제에서입니다만…ㅋ~)
    VBA만으로도 사용자 관점에서의 리포팅은 충분히 커버리지가 확보되는데 그걸 딱히 VS영역으로라는 것은 뭐랄까? C#과 LINQ 그리고 F#의 .Net개발 포지셔닝을 염두에 두고 가는 것이라면 또 모르겠는데 그건 아니라고 하고… 그렇다고 해서 Optimization을 위해 Azure에 Hadoop을 결합하기에 (분석과 최적화를 위해) R을 채용하는 것도 아니라는데… (뭐 나중에 필요하면 할지도 모르겠죠.)
    그런데 더더욱 이해가 안가는건 이미 금융공학이나 바이오인포메틱스에 잘 사용하고 있는 O’calm의 MS 버전인 F#을 가지고 있으면서도 왜 엑셀에 Optimization 스크립트로 활용 안하는지는 정말 의문입니다.
    개인적으로는 Finance, Scientistic Analysis를 필드에서 수행하는 도구로 많이 활용되어지는 Python보다도 더 강력한게 F#일텐데 VS2010버전에는 메인으로 올려두고도 그냥 방치하는 느낌은 왠지 갈피를 못잡고 있는 모습으로 비춰집니다.
    만일 제가 마이크로소프트의 제품라인업을 담당하는 사람이라면 아마도 이렇게 할 것 같습니다.
    현재 컬럼방식의 인메모리 엔진을 사용하고 있는 Excel 2012와 이 엔진의 어드밴스드격인 SQL 2012의 장점을 살리되 보완하기 위해서라면 Azure를 기반으로 기존 엔진이 가지는 컬럼 방식 인메모리 엔진의 한계를 극복시킵니다.
    동시에 Excel과 Access의 VBA를 F# 스크립트로 마이그레이션하고 익스텐션 오플리케이션의 외형과 데이터 비주얼라이제이션 역량을 실버라이트를 이용해서 오피스, 쉐어포인트에 구현합니다.
    그리고 이녀석들을 자연스럽게 C# with LINQ로 SQL서버와의 자연스런 연동구조로 가져가면서 엔터프라이즈 레벨에서의 분석 최적화의 레벨을 통합화합니다.
    제가 보기에는 MS에 하둡생태계의 툴들인 Scribe, Hive, Pig, Flume를 대체하거나 유사하게 활용할 수 있는 여러 방법들을 이미 가지고 있거나 활용이 가능하다고 봅니다.
    그렇기에 아마도 ‘아이소토프’ 프로젝트에 C#을 중간언어로 포지셔닝 하는 실험을 하고 있는지도 모르겠다고 생각합니다. 만일 이 선택이 앞서 제가 말한 구조와 활용을 염두에 두고 가는 것이라면 재미난 방향이겠지만…
    한국MS가 본사의 비젼을 잘 모르는 것인지 아니면 MS 자체가 일단 펼쳐만 두고 하나씩 상황봐서 정리하고자 하는 것인지 아직 잘 모르겠다는 것입니다.
    뭐 제가 관여할 바는 아니지만 하둡을 연계해서 Azure를 끌고가려는 MS의 계획은 뭐랄까 아직 계획마저도 프로토타이핑 단계처럼 보입니다. (사실이 그렇기도 한것 같네요. ㅋ)
    참으로 궁금합니다.
    김환태 수석님으로부터의 나름의 변을 듣기는 했지만 뭐랄까…
    이해불가인 제품군 포지셔닝 전략은 애매뚱하기 그지 없었습니다.

    그럼에도 불구하고 저는 2012버전을 기점으로 한 MS의 비전에 대해서는 지대한 관심과 희망을 품어봅니다.
    철없던 어린시절 한 때, 반MS 진영의 개발자였던 저의 입장변화를 끌어낸 마이크로소프트의 현재의 가능성은 참으로 대단한 것입니다. ^____^;;;

    에고…그냥 두서없이 오늘도 또 넋두리를 하다가 게시판 스크롤 분량만 늘렸네요. ㅋ~
    아! 그리고 내일 클라우드 컨퍼런스 하나가 롯데월드호텔에서 열리는데 저는 그곳에 있을 예정입니다.
    마이크로소프트 제품군이 중심이되는 클라우드 플랫폼이라 나름 관심도 있고 해서 참관합니다.
    거기서 시간되면 연락드리도록 하겠습니다.
    즐거운 밤 되세요!

    =3=3=33

    • kimws댓글:

      역시 포스팅을 능가하는 댓글에 제가 감동 먹고 있습니다. 저는 사실 MS랑 별로 친한 사람이 아닌지라 무슨 말씀을 하시는지는 알겠지만 제가 앞으로 말씀하신 MS의 Azure 을 쓸 확률은 매우 낮을 것 같네요. 그리고 댓글의 내용을 보건데 미소짓고 계실 MS 코리아의 몇몇 분 얼굴도 떠오릅니다. 아마 아시는 MS 관계자분과 잘 얘기하시면 Azure에서 하둡을 사용할 수 있는 invitation code 하나 정도는 얻으실 수 있지 않을까요? 아니면 https://www.hadooponazure.com 에서 직접 invite code 을 요청해보세요. ^^

      제가 내일은 시간이 안될 것 같은데요. 개인적인 일로 3시경에 수원에 가야할 일이 있어서 말이죠. 아무튼 롯데에서 하는 행사 저도 참가하고 싶지만 어렵겠군요. 수요일은 저 시간 괜찮습니다. 사무실이 어느쪽이신가요?

      • tykoh70댓글:

        주최측이 장소를 헷갈리게 공지해서 안가려고 생각중입니다. 제 사무실은 영등포 양평동에 있습니다. ㅋ~ 이따가 전화 드리겠습니다.

  4. good5810댓글:

    안녕하세요. 빅데이터와 하둡 관련 글을 찾다가 이 블로그를 알게 됐습니다. 유익한 글을 잘 봤습니다. 여쭐 게 있어서 그렇습니다. 메일주소를 알려주시면 메일로 연락을 드리겠습니다. 감사합니다.

  5. Ted Won댓글:

    Splunk 도입 검토 하면서 보니 Hadoop 통합은 올해 하반기 이후 나올 신규 버전에서 가능하네요.

  6. Jude댓글:

    Logstash 도 꽤 쓸만했던 기억입니다. 설정파일에서 regex쓸 때 좀 이상한 부분이 있지만요.
    Elasticsearch logstash kibana 조합으로 많이 활용하더군요.

  7. 정철훈댓글:

    안녕하세요 빅데이터 관련 검색을 하다 이 블로그를 방문하게 되었는데요.. 현재 저희도 flume 을
    통해 로그를 수집하고 있는데 수집하고 활용할 방법이 딱히 없어서…
    제가 하려는 것은 여러 서버의 was로그를 수집하여 통합 대시보드를 만들고 싶은데요
    즉 100개의 웹서버가 있다면 100개의 대시보드를 한눈에 봐 모니터링을 만들려고 하는데…
    만들려는것은 간단합니다. 현재세션수, 특정기간 접속자수, 현재 heap 메모리
    이렇게 보여주려하는데 하둡적재까지는 tail 스크립트를 통한 flume으로 수집하여 문제가 없는데
    이 비정형 log에서 세션과, 접속자, heap메모리를 추출할 방안이 떠오르질 않네요..ㅠㅠ
    전 에코시스템에서 추출에 용이한 툴이 있을줄알았더니…..
    혹시 경험 있으시다면 bbbbeck@naver.com 으로 메일한통 주심 안될까요?
    도움 부탁드립니다. ㅠㅠ

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중