jaso extends j2ee

오산돌구 2011/07/07 23:24 # M/D Reply Permalink

하둡 입문자입니다. 님 블로그에서 양질의 글들 잘 읽고 갑니다.
이번 포스트는 현재 저한테 딱이네요 : )

천호찌질이 2011/08/26 10:51 # M/D Reply Permalink

하둡 공부한지 얼마 안되었는데..
이 블로그에 와서 많은 정보를 얻습니다. 감사합니다.

근데 hadoop...좀 어렵네요^^

정학 2012/03/09 05:05 # M/D Reply Permalink

안녕하세요,

현재 Hadoop 관련하여 간단한 연구를 하고 있는 학생 입니다.
메모리 사용관련 테스트 포스팅(hadoop memory usage 모니터링)을 보고나서 연락드리게 되었습니다.

혹시 테스트 시, 어떤 벤치마크를 사용하셨는지요?
답변 부탁드리겠습니다.

감사합니다.

1. 김형준 2012/03/09 16:49 # M/D Permalink

   벤치마킹 도구는 그냥 필요할때마다 만들어서 사용합니다.
   모니터링은 그루터에서 자체 개발한 cloumon을 사용하고요

kdnmih 2010/09/28 14:59 # M/D Reply Permalink

좋은 정보 감사합니다. 잘 지내시죠^^?
하둡도 공부해야되는데... 아 망할넘의 숙제들이 절 쥑이네요...

racoon 2010/11/11 14:05 # M/D Reply Permalink

좋은 정보 감사합니다. :D

ssallys 2012/03/22 08:31 # M/D Reply Permalink

좋은 정보 감사합니다.

류금열 2010/06/30 10:12 # M/D Reply Permalink

안녕하세요.
하둡에서도 HDFS 에 관심이 있는 학생입니다.
아무리 생각해봐도 모르는 점이 있어서 이렇게 염치 불구하고 질문을 남깁니다.

다수의 클라이언트에 대한 병목 현상을 줄여 수용력을 높이고 장애 복구 능력이라는 기능을 위해서 hdfs 에서 replication 정책이 있는데요

클라이언트에서 파일을 쓰는 과정에서 블록 복제를 언제 하는지 궁금하네요.
hadoop the definitive guide 에서는 다른 데이터노드에 복사를 한 후에 ack message 를 클라이언트에 보내야 다음 블록을 복사한다고 확인했는데요.

그렇게 되면 64MB 를 복사하는 과정이 192 MB 를 복사하는 과정으로 쓰기 부화가 늘어나는 것처럼 보입니다.

하지만 실제로 hadoop 환경에서 replica 1,2,3.. 으로 하나의 클라이언트에서 copyFromLocal 명령으로 복사를 할 경우에 속도가 2배 3배 되는 것이 아니라 약간의 차이만을 보입니다.

그리고 더욱 혼란으로 빠지게 하는 것은 두개의 클라이언트에서 위와 같은 실험을 하면 replica의 증가함에 따라 큰 폭으로 지연되는 전송속도를 확인 할 수 있었습니다.

제가 해본 것은 datanode 의 개수도 3개밖에 없어서 대 규모의 실제 하둡에서 동작하는 것과 많은 차이가 있겠지만, 이를 통해 정확한 block replication 의 복사 시점과 복사 과정에 대한 궁금증이 생겼습니다.

그리고 어떤 node 에 블록을 할당되는지에 따른 속도의 변화가 큰 것도 확인할 수 있습니다.

namenode 에서 node 선택에 대한 특정한 정책이 있는지 아니면 random 으로 할당되는지도 궁금하네요.

두서없이 얘기 했지만, 책을 봐도 잘 이해가 되지 않아 이렇게 질문을 남깁니다.

참고할수 있는 문서나 혹은 위의 과정을 이해하시는 분은 답변 부탁드립니다.

감사합니다.

1. 김형준 2010/06/29 22:38 # M/D Permalink

   클라이언트에서 파일 저장 시 hadoop의 블럭 복제 방법에 대해 질문하셨는데 다음과 같은 순서로 진행됩니다.
   1. 클라이언트는 NameNode에게 블럭 전송을 시작한다고 알린다.
   2. NameNode는 적절한 데이터노드 3개를 선택해서 클라이언트로 보낸다.
   3. 클라이언트는 첫번째 데이터노드로 전송할 데이터를 보낸다.
   4. 데이터노드는 받은 데이터를 두번째 노드로 전송하고 자신의 디스크에 기록한다.
   5. 그 다음 데이터노드도 동일한 방법으로 수행한다.
   6. 64MB 블럭을 전송하고 나면 1번 부터 다시 시작한다.
   
   이상입니다.
   3 카피를 저장하는데 속도가 3배로 더 소요되지 않고 조금 더 소요되는 것은 Client -> DataNod1 -> DataNode2 -> DataNode3 와 같이 전송 패킷 단위로 파이프라인되기 때문이라고 보시면 됩니다. 2 ~ 3번째 데이터노드에서 패킷을 처리하는 동안 첫번째 데이터노드는 다음번 패킷을 받기 때문입니다.
   그리고 이런 글은 비밀 댓글로 하지 않으셔도 됩니다. 다른 분들에게도 같이 공유하면 좋겠죠. ㅋㅋ

류금열 2010/06/30 10:10 # M/D Reply Permalink

먼저 성의있는 답변감사드립니다.
블럭 복제 과정에서 datanode1 이 client 에서 블럭을 받을때 지연 없이 최대 대역폭으로 블럭을 다운로드 하고 있다면, datanode2 에게 파이프라인으로 전송을 하더라도 역시 같은 네트워크 라인에 이용할 대역폭이 없기 때문에 속도가 더욱 지연될거라고 생각하거든요. 파이프라인도 결국은 네트워크 라인을 사용하기 때문에 이런 고민을 하게 되었습니다.^^

1. 김형준 2010/06/30 15:51 # M/D Permalink

   네트워크 기반이기 때문에 네트워크 대역폭이상으로 성능이 나올수는 없겠죠. 다만 기존에 중앙집중되어 있는 스토리지(NAS, SAN)등에 비해 분산된 서버를 이용하기 때문에 네트워크도 트래픽도 분산되는 효과를 볼수 있습니다.
   이것도 업링크에 부하가 집중되면 어쩔수 없고요... 하둡 구성시 가장 신경써야 하는 부분이 바로 이런 부분입니다. 내부용으로 사용할 경우는 문제가 안되지만 저장된 파일을 이용하여 외부 서비스를 하는 경우 신경써야 하는 부분입니다.

류금열 2010/06/30 20:19 # M/D Reply Permalink

네 친절한 답변 감사드립니다.
어떤 부분을 공부해야 할지 방향을 알것 같네요~
감사합니다.

김현수 2010/07/01 01:43 # M/D Reply Permalink

하둡 책을 읽으면서 궁금하게 생각한 부분이었는데요. 20개의 데이터노드를 활용할 수 있다고 가정할때 2개의 랙으로 10개 노드씩 구성하는것과 하나의 랙에서 20개 노드로 구성하는 것이 전자가 더 장점을 갖을 수 있는 부분이 위와같은 경우인가요? 단순하게 생각하면 같은 랙 안의 노드끼리 전송속도가 더 빠르다고 생각되서 더 좋을 것 같다고 느껴지는데요...2개의 랙으로 나눠서 구성했을때의 장점이 무엇인지가 궁금합니다.

1. 김형준 2010/07/01 12:56 # M/D Permalink

   안녕하세요. 랙 분리와는 상관없는 것 같습니다.
   서로 다른 랙이라도 스위치 하나에 연결되어 있으면 dedicated GB를 보장받으니까 문제되지는 않을 겁니다.
   랙에 스위치가 같이 있어서 랙-랙간에는 업링크를 타게 되면 하나의 랙에 두는 게 좋고요... 따라서 이것은 랙의 문제라기 보다는 스위치 구성의 문제입니다.
   랙을 분리하면 좋은 것은 장애가 발생하는 단위가 랙 단위로 발생할 가능성이 많기 때문에 rack awareness 기능을 이용해서 하나의 랙에 장애가 발생해도 동일 블럭이 다른 랙의 노드에 있도록 할 수도 있습니다.
   랙을 나누면 IDC의 랙당 운영 비용이 올라가는 단점도 있을 겁니다.

이광재 2010/07/01 16:56 # M/D Reply Permalink

자소님. Pig하고 Hive는 어떤 차이점이 있는 것인가요? 정의만 보면 비슷하게 보여서요~

1. 김형준 2010/07/01 18:37 # M/D Permalink

   이 블로그 포스팅이 갑자기 Q&A 게시판이 된 듯하네요...
   
   Pig, Hive는 목적은 동일합니다. 하둡에 저장된 데이터를 프로그램이 아닌 스크립트 언어로 쉽게 분석해보자는 것입니다.
   
   가장 큰 차이는 물론 스크립트 문법이겠죠... Pig는 좀 더 많은 프로그램적인 요소가 들어가 있어 조금 복잡하지만 기능적으로는 더 풍부하다고 할 수 있습니다. Hive는 SQL 비슷해서 쉽게 사용할 수 있는 장점이 있죠...
   두번째 차이점은 Pig는 모든 하둡 파일을 이용할 수 있지만 Hive는 테이블 개념이 들어 있습니다. Hive는 테이블을 생성하고 테이블에 데이터를 넣는 방식입니다. 테이블리라고 해서 거창한 것은 아니고 컬럼 정도만 정의 되어 있고 파일을 저장할 때 Hive 명령을 이용해서 저장하면 해당 컬럼에 맞게 구분자를 추가해서 저장하는 정도입니다.

잣나무숲 2010/07/15 15:45 # M/D Reply Permalink

안녕하세요. hadoop 을 공부하는 사람입니다.

chukwa 를 시도하던 중에 막히는 부분이 있어서 여쭤보고자 합니다.

postprocess.log 에 보면
"pool-1-thread-1 MetricDataLoader - SQLException: Table chukwa1.system_metrics_2115_week' doesn't exist"
와 같은 에러가 발생합니다.

실제로 mysql 에 위 table 은 없구여.

database_create_table.sql 를 이용하여 table 을 생성하였는데, *_template 라는 테이블만 생성이 되더군여.

따로 테이블을 생성해줘야 하는지요? 아니면 어딘가 설정을 덜해줘서 그런건지 감이 안오네요.

java 도 db 도 아직 잘 모르는 상황이라 어렵네요. 도와주시면 정말 감사하겠습니다~^^

1. 김형준 2010/07/15 17:45 # M/D Permalink

   안녕하세요.
   bin/chukwa org.apache.hadoop.chukwa.database.TableCreator 실행해주시면 테이블이 생성됩니다.

잣나무숲 2010/07/15 19:25 # M/D Reply Permalink

예 답변 감사합니다~^^

anybody 2010/11/05 15:17 # M/D Reply Permalink

hadoop/chukwa를 공부중에 있습니다.

현재 chukwa의 데이터를 hicc로 보려고 하고 있는데요.

./chukwa hicc 후에 hicc.log에서 JsonException : 'owner'와 같은 에러로그가 나타납니다.

혹시 해결방법을 아시는지요.

그리고 hicc와 collector의 포트(8080)가 겹치는데요.

collector의 포트를(4080)으로 수정했더니 agent는 8080을 바라보고, collector는 4080에서 대기하는 현상이 발생해서 다시 8080으로 수정을 했습니다.

hicc가 가동할때 기존의 collector의 제티에 hicc.war만 deploy되게 할수는 없는건지요.

생각보다 어려운데요 ㅠ 도와주시면 정말 감사하겠습니다~

1. 김형준 2010/11/08 08:59 # M/D Permalink

   안녕하세요. owner 에러 나타난 것은 소스를 봐야 정확하게 알 것 같습니다. 아마 chukwa가 하둡에 특정 디렉토리를 만들어서 그곳에 위젯 정보 등을 저장하고 사용하는데 그것때문이지 않나 생각이 듭니다.
   포트 문제는 chukwa의 경우 collector와 hicc 웹 서버를 같은 서버에 실행하지 않습니다. 같이 실행할 경우 hicc port를 변경하거나 collector port를 변경합니다. 이때 agent에서도 변경된 포트를 인식하게 하기 위해서 conf/collectors 파일을 수정하시면 됩니다.

typos 2009/08/13 11:15 # M/D Reply Permalink

hadoop이 여러 sub project로 쪼개진것도 심상찮습니다.
나중에 쫓아오는 사람들은 무쟈 헷갈릴듯

1. 김형준 2009/08/13 11:33 # M/D Permalink

   기존 운영중인 0.18, 0.19를 업그레이드 하면서 환경 설정 바뀐것도 고민해야 하고.. 쩝