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