3회 서울 Hadoop 사용자 모임 / 아파치 피닉스

2,567 views

Published on

3회 서울 Hadoop 사용자 모임 / 아파치 피닉스

Published in: Software
1 Comment
9 Likes
Statistics
Notes
  • where address '%송파구%' 하지 말고 where reflect2(address, 'contains', '송파구') 하면 될 듯.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
2,567
On SlideShare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
45
Comments
1
Likes
9
Embeds 0
No embeds

No notes for slide

3회 서울 Hadoop 사용자 모임 / 아파치 피닉스

  1. 1. 제 3회 서울 Hadoop 사용자 모임 tchoi@hortonworks.com 호튼웍스 코리아 수석 컨설턴트 최종욱
  2. 2. 공지 사항 • 서울 Hadoop 사용자 모임에 어서 오십시오! • 식사는 첫 발표 이후 강당 밖에서 부탁드립니다. • 샌드위치는 햄, 씨푸드, 참치 준비했습니다. • 오후 7:00부터 시작합니다. • 호튼웍스, SAS, ASD 테크 순서로 발표합니다.
  3. 3. 어서 오세요! • 서울 Hadoop 사용자 모임: 초보자부터 전문가까지 하둡 전반에 대한 이야기를 나누는 사람들의 공개 모임이다. 2014년 1월부터 매월 모여, 이제 약 100명이 모인다. • 대강당, 마이크, 프로젝터, 캠코더 등 시설도 대폭 강화했다. • facebook.com/groups/seoulhadoop
  4. 4. 오늘의 발표 일정 소개 하이브 최적화 및 피닉스 소개 최종욱 수석 컨설턴트 Hadoop Data 가치 창출을 위한 SAS 분석 테크놀로지 김근태 부장 파이썬과 하둡 스트리밍의 활용 세르게이
  5. 5. 하이브 40배 성능 향상 비결 실전 성능 향상 결과
  6. 6. 대기업 시험 환경 • 문제: 부분 일치하는 문자열만 걸러내는 경우에 20분이나 걸린다. • 예: SELECT * FROM customer WHERE address LIKE “%송파구%” • 원인: LIKE를 처리할 때, 자바 정규식 기능을 사용하는데 이를 위해 컴파일, 실행, 문자열 객체 생성 등에 굉장히 많은 CPU와 메모리 자원이 필요하다.
  7. 7. LIKE 최적화 • 전략: 자주 쓰이는 패턴이 나타나는 경우, byte 배열에 바로 접근하여 for 반복문으로 처리한다. • 설계: 80%의 용례가 abc%, %abc%, %abc와 같음을 SQL 서버 개발자가 알려줬다. UTF-8 처리, 널 처리 등을 추가했다. • 기타 최적화: 24개의 디스크, 고속 네트워크, 하이브 버전업, ORC 파일 적용했다. • 결과: 20분이 걸리던 질의를 30초만에 처리했다. LIKE 외 질의에서 성능이 6배로
  8. 8. 아파치 피닉스 소개 실시간 삽입, 조회, 편집, 삭제로의 초대
  9. 9. 하이브가 통계를 내는 방식 • 군대식으로 여러 컴퓨터에 명령을 내려, 각 컴퓨터가 계산한 통계를 합치는 방식이다.
  10. 10. 하이브(하둡)의 강점 슈퍼컴 하이브 (하둡) • 여러 일반 컴퓨터로 처리 • 처리할 양이 늘어나면 컴퓨터 추가 및 네트워크 연결 • 확장 비용이 저렴 • 커다란 고급 컴퓨터로 처리 • 처리할 양이 늘어나면 더 큰 컴퓨터로 대체 • 확장 비용이 비쌈
  11. 11. 하이브가 문서를 찾는 방식 • 한 문서를 찾느라 부대 전체가 수색하는 꼴이라 비효율적이다.
  12. 12. HBase가 문서를 찾는 방식 • 도서관 처럼 정리를 열심히 해놓아서 실시간으로 추가, 조회, 편집, 삭제 할 수 있다.
  13. 13. 도서관 사서가 되어봅시다 1. 책 일련번호를 알 때. 2. 안내도에서 위치를 확인하여 3. 주제별 구역으로 이동하고 4. 일련번호가 낀 책장을 찾아 5. 책장 내에서 해당 일련번호의 책을 찾고 6. 본문을 복사한다.
  14. 14. 비유를 하자면… 도서관 HBase 전체 안내도 마스터 주제별 구역 리전 서버 범위가 붙은 책장 리전 책 일련 번호 로우 키 책 본문 컬럼 패밀리
  15. 15. 외계어의 넘사벽 • “김씨가 2002년에 발행한 책을 찾아라” • new Scan(new byte[]{}, new FilterList(FilterList.Operator.M UST_PASS_ALL, Arrays.asList( new SingleColumnValueFilter(cf, au thorCol, CompareOp.EQUAL, B ytes.toBytes(“kim”)), new SingleColumnValueFilter(cf, ye arCol, CompareOp.EQUAL, Byt es.toBytes(2002)) ))); • 개발자, 관리자 모두 떡실신…
  16. 16. 기존의 SQL on HBase 지원 • 하이브와 임팔라 등에서 HBase 통합을 지원했다. • 실제 용례에 비해 기능과 성능이 떨어졌다. • 실질적으로 쓰기에는 무리가 많이 있었다.
  17. 17. 아파치 피닉스는 기본적으로 • 기존에 쓰던 JDBC, SQL 그대로 HBase를 사용. • SELECT * FROM book WHERE author=“kim” AND year=2002
  18. 18. 피닉스는 덤으로… • 다양한 최적화 지원 – 복합키: 여러 컬럼을 조합해서 하나의 일련번호로 사용 – 솔팅: 한꺼번에 많이 쓸 때 한 컴퓨터에 쏠리는 현상 완화하여 성능을 최적으로 유지 – 스킵 스캔: – 이차 색인: 한 문서에 여러 종류의 일련번호 부여 – 시퀀스: 기존 데이터베이스처럼 임의의 일련번호 부여
  19. 19. 무작위로 분산된 키의 경우
  20. 20. 연속적으로 증가하는 키의 경우
  21. 21. 솔팅 (Salting) 최적화 • HBase는 키 기준으로 정렬하여 인접한 키 끼리는 한 컴퓨터에 모아놓는 방식이다. • 한번에 쓸 게 많아지면, 키에 따라서 여러 컴퓨터에 나뉘어서 기록되기 때문에 문제가 없다. • 하지만, 로그 데이터처럼 인접한 키가 많으면 한 컴퓨터에 모든 부하가 집중되어 전체가 느려진다. • 솔팅을 적용하면 사전에 정해진 규칙에 따라 키의 순서를 뒤섞어서 부하 집중을
  22. 22. 복합키 최적화 • ‘책을 저자 이름 순으로만 정렬해도 괜찮겠지?’ • 김태광 작가 2014년 현재 151권 이상 집필… OTL • 저자 이름과 책 이름 순으로 정렬하면, 찾기에 훨씬 편리
  23. 23. 스킵 스캔 a b c d 1 2 3 4 a b c d 1 2 3 4 WHERE key1=‘a’ OR key1=‘c’ WHERE (key1=‘a’ OR key1=‘c’) AND (key2=1 OR key2=3) 8개 영역 읽음 4개 영역만 읽음
  24. 24. 하둡 생태계의 중심으로 들어오는 중 • 이전엔 세일즈포스라는 회사에서 관리했다. – 최근에 아파치 소프트웨어 재단으로 이관. • 이전엔 하둡 배포판에 포함되지 않았다. – HDP 2.1에 포함. 차후 타 배포판에도 포함될지도?
  25. 25. 실시간 조회 성능 • 타이핑을 하는 동안 주가 그래프가 변경된다. 굉장히 빠른 반응성을 보인다. • http://www.youtube.co m/watch?v=YHsHdQ08t rg
  26. 26. 피닉스는 기회의 땅! • 기업 사용자: 실시간 삽입/조회/편집/삭제 에도 하둡을 적용할 수 있다. • 오픈소스 개발자: 문이 활짝 열려있는 데뷔 무대!

×