스터디

SQL Unplugged 2012 후기

서른마른다섯 2012. 4. 23. 14:31

SQL Unplugged가 세번째로 개최되었다. 지방에서 근무했던 나는 세미나를 참가할 여건이 되지않아 항상 동영상으로만 봐왔었는데 이번에는 참관해서 세미나를 들었다. 동영상으로 보는 것과 현장에서 보는 것은 콘서트를 보는 것처럼 달랐다.

BI에 관심을 많이 가지고 있었는데 부제가 무려 데이터 세상을 혁명하다.’ 였다. 아주 큰 기대를 안고 BI 위주로 세미나를 들었는데 결과는 참담했다. 기초 용어 정도만 알고 있었는데 세미나 수준이 조금 높았다. 나는 Track 4 – Track 3 - Track 2 – Track 3 의 순으로 참관했다.

휴식타임에 INBREIN에서 모델링 퀴즈를 맞추면 MS 마우스를 준다기에 시도했지만 62관계설정을 잘못했다. 시간을 5분만 준대서 급하게 푸느라 놓친 부분이 있었나보다 생각하지만 역시나 아쉬웠다.

Track4_1 에서는 SQL Server Integration Service 2012의 새 기능과 수정된 기능과 Columnstroe Index를 소개해주었다. 시작 전 워밍업 퀴즈를 냈었는데 맞추면 16기가 USB였다. 어려운 내용이 전혀 없었지만 퀴즈를 맞추진 않았다. 세미나 내용은 대체로 만족스러웠다. 버전업을 하면서 사용 편의성이 훨씬 좋아진 SSIS였다.

Track3_2 에서는 게임분석을 위해 필요한 것에 대해 설명했다. 두 분이서 대화형으로 진행하였는데 꽁트를 하는 듯하면서도 쉽게 설명하여 알아듣기 쉬웠고 실제 도움이 많이 된 것 같다. 키워드는 품질향상, 분석주제, 통찰력 이었다. 즉 데이터를 표준화하여 신뢰도를 높이고, 무엇에 대해 분석할 것인가를 명확히 결정한 다음 이러저러한 데이터를 산출해내고 의미있는 데이터를 찾아내는 것이다. BI로의 접근이 힘들었는데 언젠가 필요로 할 때 큰 도움이 될 것 같은 세미나였다.

Track2_3 에서는 “80Cores 256GB Memory” 장비에서 “Windows Server 2008R2 SQL Server 2005”를 세팅하면서 겪었던 문제 원인을 잘 설명해 주었다. 새로운 윈도우의 CPU관리 개념인 Process Group에 대한 이야기를 처음 들었다. 누마도 정확히 이해하지 못했는데쉽게 경험해보지 못할 장비에서의 문제점과 신기술과 해결은 정말 흥미로운 내용이었다. NUMA(Non-Uniform Memory Access) 에 대해서 얼핏 이해하고 있는 상태였던 나에게 Process Group더 공부해라고 들려왔다.

Track3_4 SSAS를 정확하게 이해하지 못한 상태에서 참관해서 그런지 알아들을 수도 없었고 그래서 금방 흥미를 잃어버렸다. 1번트랙 들어갈 걸 이란 후회가 밀려오는 데는 10분이 채 걸리지 않았다.

 

새 기능으로 더욱 강력해진 SQL Server 2012 BI

Integration Service

-       Expression Task 표현식

n  변수에 값뿐 아니라 식을 사용할 수 있게 되어 변수 제어가 용이해졌다.

-       Redo, Undo

n  실행 취소, 재실행 기능이 추가되었다.

-       Grouping

n  제어흐름, 데이터흐름, 이벤트처리 등에서 다수의 객체를 그룹화하여 작업환경 정리를 통해 가독성이 높아졌다.

-       CDC (Change Data Capture)

n  DML의 데이터 변경 내역 추적 기능

n  스키마_테이블_CT 테이블에 변경 데이터가 저장된다.

n  잦은 갱신이 발생할 경우 성능을 고려해야 한다.

n  CDC ETL 구현

u  초기데이터 로드 -> 변경데이터 작업 (DQS 등) -> ETL 이후 데티어 관리 (_CT 테이블 관리)

-       DQS Cleansing

n  Data Quality Server 설치 후 사용 가능(15분 정도 소요)

n  지식 기반 데이터 품질 서비스로 데이터 품질 강화 및 표준화 가능

n  도메인으로 데이터 관리

n  Data Cleansing (‘서울’, ‘서울시’, ‘서울특별시’ -> ‘서울’ )

n  Update ~ Where in 보다 성능이 좋음

-       피벗

n  피벗 설정을 보다 직관적으로 쉽게 할 수 있어 작업이 편리해졌다.

n  기존에는 입력열에서 속성값을 직접 수정해줬어야 했다.

-       Parameters

n  프로젝트 매개변수가 생김

u  프로젝트 내 모든 패키지에서 공용하는 변수

u  부모 패키지의 변수를 받기 위해 연결하는 복잡한 과정이 없어짐

-       Deploy

n  프로젝트 배포가 생김

u  Integration Services Calalogs 에 직접 배포

u  유효성 검사 리포팅 지원

u  총 10개의 버전을 지원하여 과거의 상태로 바로 돌아갈 수 있음

ColumnStore Index

-       Enterprise Edition 지원

-       열기반 데이터 구조

-       집계 쿼리 성능 향상

n  필요한 열 데이터만 사용

n  열에 중복이 많을수록 압축률이 좋음

-       인덱스 열 개수 제한

n  일반 테이블의 최대 열개수인 1024개까지 지원 (행기반 인덱스는 16개 까지만 지원)

-       파티션된 테이블 지원

-       데이터 직접 갱신 불가

-       장단점

n  Row-Store

u  데이터 업데이트가 용이함

u  일반적으로 불필요한 열 데이터 읽기 발생

u  압축 효율이 상대적으로 낮음

u  Random Access에 유리

n  Column-Store

u  대용량 데이터 읽기 성능이 비교적 뛰어남

u  데이터 업데이트가 까다로움

u  압축 효율이 상대적으로 높음

-       xVelocity

n  In-Memory column store engine (32bit 주의, AWE 지원 안함)

n  높은 데이터 압축률과 향상된 I/O 성능

n  비트맵 인덱스

-       Create nonclustered column index IndexName on TableName (ColumnName)

-       제한사항

n  지원하지 않는 데이터 형식이 있음

n  기본키, 외래키 사용불가

n  고유 인덱스 생성 불가

n  뷰 또는 인덱싱 된 뷰에 생성 불가

 

Big Data 와 DQ를 통한 게임분석

Big Data란 무엇인가 – 다양하고 크고 속도가 빠른 가운데 2개 이상에 해당한다면 Big Data!!

-       품질 저하로 인한 통계의 부 정확성

-       데이터의 폭발적 증가에 따른 저장문제

-       대용량 분석에 따른 속도 문제

품질향상

-       데이터 오류

n  표준화 (M/F, 남/여, 0/1, 남자/여자, …)

n  완전성 (쓰다가 만 주소)

n  명확성 (1년전 20살이 현재도 같은 나이)

n  유효성 (10레벨 이상 특정 아이템 소유)

n  유일성 (A 라는 유저는 오직 한명)

-       Data Cleaning

n  프로파일링(기술검색), 기술관리(도메인 관리), 수집(데이터 정리), 일치, 기술자료검색

n  DQ (Case 정제 또는 update, DQS)

분석주제

-       분석 주제를 설정하고 최대한 저장

-       로그 데이터 효과적인 적재

통찰력

-       다차원 분석 (이것저것 해보고 의미있는 데이터를 추려냄)

-       SSAS의 큐브에 접속하여 Excel을 이용한 분석

-       데이터 마트를 Azure에 업로드 한 후 분석

n  접속 및 권한 이슈를 어느정도 해결


 

“80 Cores 256GB Memory” 그 장비에 무슨 일이 있었나?

기존 32Cores, 64GB Memory 시스템의 하드웨어 업그레이드 이슈에 따라 80Cores, 256 Memory 를 도입한 회사가 있었다. Storage는 이미 잘 구성되어있어 업그레이드 대상에서 제외되었다 한다.

8 Socket * 10 Cores (10Core 라니.. 이런게 있엇나) No Hyper-Threading

그런데 SQL Server 가 40core만 감지했고 이것의 원인으로 Process Group을 지목했다. Process Group란 Windows Server 2008 R2 에 도입된 새로운 CPU 관리 개념이며 최개 4개를 만들 수 있다. 한 그룹에서 최대 64Core를 인지할 수 있으므로 Windows Server 2008 R2가 256Core까지 지원한다는 이야기이다.

그럼 왜 64개가 아닌 40개만 인식한 것인가?

64개 이하로는 단일 그룹으로 동작하지만 별도의 설정을 하지 않으면 64개가 넘는 경우 Core 개수를 균등하게 배분한다고 한다. 그래서 40개씩 2개의 그룹을 만들게 되었고 한 프로세스는 하나의 그룹으로 로드되기 때문에 40개만 인지했다는 것이다.

여기서 다른 문제점.. SQL Server 2005의 최대 CPU 지원 개수는 문서상으로 Operration system maximum 이다. 하지만 하나의 프로세스 그룹만 인지하게 되므로 64개 까지만 지원하게 된다. 이것을 해결하기 위해 SQL Server 2008 R2나 SQL Server 2012를 도입할 필요가 있다고 한다. 이것들은 프로세스 그룹을 인식하도록 만들어져 있어 더 많은 CPU를 지원할 수 있다고 한다.

64 코어를 인지 시키기 bcdedit /set groupsize 64 명령으로 그룹사이즈 조절 시도했지만 실패, 원인은 소켓 단위로 인지하기 때문 그래서 소켓 당 Core 수 8로 조정 8core * 8socket = 64core. 그럼 16 core는 ? 놀림.

성능 향상을 위해 고민해 볼 만한 것

Windows 전원 관리 옵션

-       고성능 옵션 권장 (10~30% 성능 이득)

-       Bios 전원 관리 옵션 최적화

-       Hyper-Threading은 다차원적인 판단이 필요

-       외부 장치 성능에도 영향

메모리 페이지 잠금 권한 할당

-       대형 메모리 장비용 (최대 2배 성능 향상 사례가 있음)

Large Page Allocations

-       추적 플래그 834 (5~10% 처리 성능 증가)

-       SQL Server 전용장비 64bit, EE

-       서비스 시작 시간 증가 고려

Max Worker Threads

-       CPU 수에 따른 자동 설정

-       계산식(64bit) = 512 + ((#CPU) – 4 ) *16

-       Max server memory 설정 시 변수로 사용

Max Server Memory

-       일반적으로 알려진 공식 = 물리적 메모리 – OS(2GB) – SQLThread(2MB) * Worker Thread 수 – 기타메모리(XP, In-Proc OLEDB, CLR GC, …) – 기타 Application 메모리

Max Degree of Parallelism(Maxdop)

-       쿼리/연산자 당 동시 최대 병렬처리 수준(CPU 수)

-       최소한 Maxdop 보다 많은 Worker 소비(심한 경우 Maxdop의 3배 이상도 소비)

-       기본값은 0 -> 지원하는대로 -> 64개

-       권장 사항

n  순수 OLTP = 1

n  OLTP + OLAP = N (환경을 고려하여 사용)

n  병렬 처리를 위한 개별 쿼리별로 MAXDOP 힌트 사용

'스터디' 카테고리의 다른 글

2012 BIG DATA 전문가로 가는길 (2012.07.18.DBGuide.)  (0) 2012.07.19