왕 삽질 후에 성공한 hicc 화면
- Posted at 2010/06/22 18:54
- Filed under project/lucene_hadoop
HICC(Hadoop Infrastructure Care Center)는 chukwa의 서브 모듈로 탑재 되어 있으며 하둡 클러스터를 모니터링 하는 화면을 제공한다.
지난번에 한번 실패하고 이번에 다시 도전해서 성공... 지난번에도 성공헀었는데 화면단에서 조회 조건에서 GMT+0 기준으로 데이터 조회하고 있는 바람에 데이터가 나타나지 않았다는 ㅋㅋㅋ
Posted by 김형준
- Response
- No Trackback , 13 Comments
Trackback URL : http://www.jaso.co.kr/trackback/404
Comments List
-
류금열 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 으로 할당되는지도 궁금하네요.
두서없이 얘기 했지만, 책을 봐도 잘 이해가 되지 않아 이렇게 질문을 남깁니다.
참고할수 있는 문서나 혹은 위의 과정을 이해하시는 분은 답변 부탁드립니다.
감사합니다.-
김형준 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 에게 파이프라인으로 전송을 하더라도 역시 같은 네트워크 라인에 이용할 대역폭이 없기 때문에 속도가 더욱 지연될거라고 생각하거든요. 파이프라인도 결국은 네트워크 라인을 사용하기 때문에 이런 고민을 하게 되었습니다.^^ -
류금열 2010/06/30 20:19 # M/D Reply Permalink
네 친절한 답변 감사드립니다.
어떤 부분을 공부해야 할지 방향을 알것 같네요~
감사합니다. -
김현수 2010/07/01 01:43 # M/D Reply Permalink
하둡 책을 읽으면서 궁금하게 생각한 부분이었는데요. 20개의 데이터노드를 활용할 수 있다고 가정할때 2개의 랙으로 10개 노드씩 구성하는것과 하나의 랙에서 20개 노드로 구성하는 것이 전자가 더 장점을 갖을 수 있는 부분이 위와같은 경우인가요? 단순하게 생각하면 같은 랙 안의 노드끼리 전송속도가 더 빠르다고 생각되서 더 좋을 것 같다고 느껴지는데요...2개의 랙으로 나눠서 구성했을때의 장점이 무엇인지가 궁금합니다.
-
김형준 2010/07/01 12:56 # M/D Permalink
안녕하세요. 랙 분리와는 상관없는 것 같습니다.
서로 다른 랙이라도 스위치 하나에 연결되어 있으면 dedicated GB를 보장받으니까 문제되지는 않을 겁니다.
랙에 스위치가 같이 있어서 랙-랙간에는 업링크를 타게 되면 하나의 랙에 두는 게 좋고요... 따라서 이것은 랙의 문제라기 보다는 스위치 구성의 문제입니다.
랙을 분리하면 좋은 것은 장애가 발생하는 단위가 랙 단위로 발생할 가능성이 많기 때문에 rack awareness 기능을 이용해서 하나의 랙에 장애가 발생해도 동일 블럭이 다른 랙의 노드에 있도록 할 수도 있습니다.
랙을 나누면 IDC의 랙당 운영 비용이 올라가는 단점도 있을 겁니다.
-
-
이광재 2010/07/01 16:56 # M/D Reply Permalink
자소님. Pig하고 Hive는 어떤 차이점이 있는 것인가요? 정의만 보면 비슷하게 보여서요~
-
김형준 2010/07/01 18:37 # M/D Permalink
이 블로그 포스팅이 갑자기 Q&A 게시판이 된 듯하네요...
Pig, Hive는 목적은 동일합니다. 하둡에 저장된 데이터를 프로그램이 아닌 스크립트 언어로 쉽게 분석해보자는 것입니다.
가장 큰 차이는 물론 스크립트 문법이겠죠... Pig는 좀 더 많은 프로그램적인 요소가 들어가 있어 조금 복잡하지만 기능적으로는 더 풍부하다고 할 수 있습니다. Hive는 SQL 비슷해서 쉽게 사용할 수 있는 장점이 있죠...
두번째 차이점은 Pig는 모든 하둡 파일을 이용할 수 있지만 Hive는 테이블 개념이 들어 있습니다. Hive는 테이블을 생성하고 테이블에 데이터를 넣는 방식입니다. 테이블리라고 해서 거창한 것은 아니고 컬럼 정도만 정의 되어 있고 파일을 저장할 때 Hive 명령을 이용해서 저장하면 해당 컬럼에 맞게 구분자를 추가해서 저장하는 정도입니다.
-
-
비밀방문자 2010/07/15 15:43 # M/D Reply Permalink
관리자만 볼 수 있는 댓글입니다.
-
잣나무숲 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 도 아직 잘 모르는 상황이라 어렵네요. 도와주시면 정말 감사하겠습니다~^^ -
잣나무숲 2010/07/15 19:25 # M/D Reply Permalink
예 답변 감사합니다~^^
