3강. ETL (Extraction, Transformation and Load)

ADP 2과목 데이터 처리 기술 이해 강좌의 맛보기 강의입니다.

강의 대본 보기

첫 번째 장인 데이터 처리 프로세스는 5개의 소제목으로 구성이 되어 있는데요. 첫 번째 소제목이 ETL이죠. ETL이라는 것은 무엇이냐면 데이터 웨어하우스나 데이터 마트 구축 시에 현재 운영하고 있는 시스템에 있는 소스 데이터를 추출 Extraction을 해서요. 가공, 즉 Transformation이라는 변형 단계를 거쳐서 최종 목표 시스템인 DW, DM에 적재하는, 로딩하는 일련의 과정들을 우리는 ETL이라고 하게 됩니다. 특히 ETL 과정 중에서 변환 단계, 즉 Transformation 단계가 역할이 무엇이냐 하면 소스 데이터를 추출을 했잖아요. 그러면 최종 목표 시스템인 DW나 DM에 적재를 해야 되는데 거기서 원하고자 하는 데이터 구성과 형태가 있어요. 이와 같은 형태를 처리하는 프로세스가 바로 변환 단계라고 할 수가 있고요. 전체 ETL 과정 중에서 60%에서 80%는 이 변환 단계에서 발생할 수 있다고 할 수가 있습니다. 예를 들자면 우리 다양한 종류의 DB가 있잖아요. 하지만 예를 들자면 어떤 DB는 남자를 M으로 코딩을 할 수가 있고 어떤 데는 Male로 될 수가 있을 테고요. 어떤 DB에서는 0과 1로 코딩이 될 수가 있겠죠. 하지만 이것을 원버전으로 변환을 해서 나중에 데이터 분석 처리를 할 수가 있잖아요. 이와 같은 과정들을 우리는 변환 단계라고 하고요. 이런 단계가 필요하기 때문에 우리는 ETL이라는 것을 하게 된다는 점, 여러분 꼭 기억하시기 바랍니다. 여기 슬라이드 보시면요. 다양한 DB들이 여기 있죠. 이와 같은 DB들을 우리는 Extraction, 추출하게 됩니다. 어디에 추출하게 되냐면 논리적인 가상공간이라 할 수 있는 Staging Table에 일단 적재를 하게 되고요. 그 다음에 ODS라는 것은 다음 슬라이드에 학습을 하시게 될 텐데요. DW나 DM에 가기 전에 잠정적인 영역이라고 할 수 있는 ODS를 거쳐서 최종 목표 시스템인 DW와 DM에 가게 되는데요. 중간중간에 다 Transformation과 적재 과정을 하게 됩니다. 이와 같은 일련의 모든 과정들이 우리는 ETL이라는 것을 여러분 꼭 기억하시기 바랍니다. ETL의 기능은 세 가지가 있는데요. 첫 번째 기능이 소스 데이터를 Extraction, 추출하는 과정이라고 할 수가 있고요. 여기서 키워드는 데이터 획득입니다. 저장이 아니고 획득입니다. 우리 문제에서는 어떻게 출제가 되냐 하면요. Extraction 기능을 쭉 설명하면서 여기에 획득 대신 저장이라는 표현을 하게 됩니다. 여러분, 틀린 오답이 되겠다는 걸 꼭 기억하시고요. 두 번째는 Transformation입니다. 즉, 가공하는 변형 단계라고 할 수가 있는데요. 데이터를 클렌징하고 표준화시키고 원버전으로 Business Rule을 적용하는 것이 바로 Transformation, 변형 단계라고 할 수가 있고요. 마지막 Loading, 적재하는 거죠. 최종적인 목표 시스템인 DW, DM에 적재하는 이 세 가지 기능이 바로 ETL의 기능이라고 할 수가 있고요. 맨 마지막에 시스템의 적재라는 표현은 여러분 주요 키워드라고 할 수가 있는데요. 여기와 바꿔서 시스템의 추출 또는 획득이라고 하면 잘못된 적재에 대한 표현이라는 걸 여러분 꼭 기억하시기 바랍니다. ETL의 작업 단계는 6단계로 구분이 되는데요. 소스 데이터를 추출하는 인터페이스 단계, 가상적인 논리 공간에 적재를 하게 되는 스테이징 단계, 그 다음 단계는 무엇이냐면 스테이징 테이블의 특성을 측정하고 품질을 측정하는 프로파일링 단계, 그 다음에 데이터를 보정하는 클렌징 단계, 이와 같은 절차를 끝나고 나서 한 개의 테이블로 통합하게 되는 Integration 단계에 맨 마지막에는 비정규화 과정이 있는데요. 비정규화란 건 무엇이냐면 어떤 조회 성능을 높이기 위해서 데이터를 통합하고 중복성을 배제하지 않기 때문에 더 적은 테이블로 구성하는 단계가 바로 비정규화 과정이라고 할 수가 있고요. 이 부분은 어디서? Data Warehouse에서 Star Schema와 Snowflake Schema 할 때 다시 한 번 정규화와 비정규화 부분을 다시 한 번 말씀드리도록 하겠습니다. 이와 같은 6단계로 구성이 되어 있는 것이 바로 ETL의 작업 단계라고 할 수가 있고요. 우리 시험에서는 당연히 이 순서를 물어보는 문제가 출제가 되고요. 또 한 포인트는 무엇이냐면 여기 나와 있는 프로파일링과 클렌징과 Integration 단계를 설명을 잘못 연결된 부분을 찾는 문제가 출제된다는 점 여러분 꼭 기억하시기 바랍니다. 두 번째 ODS입니다. ODS는 Operational Data Store, 운영 데이터 저장소라고 하고요. 데이터 웨어하우스의 데이터를 저장, 관리, 유지하는 잠정 영역에 속하는 데이터베이스라고 할 수가 있습니다. 우리 시험에서는 ODS와 DW의 차이점을 물어보는 문제가 시험 문제에 등장하게 되는데요. DW라는 것은 공통된 변환을 통해서 대량의 데이터를 수반하는 것이라고 한다면 ODS는 소량의 데이터를 취급하되 항상 최신의 상태로 업데이트된 상태라고 할 수 있습니다. 따라서 하루에 그 업데이트되는 주기가 하루에도 수십 번씩 변할 수 있는 게 바로 ODS라고 할 수가 있고요. 따라서 ODS와 DW의 가장 큰 차이점은 무엇이냐면 DW의 가장 특징 중에 하나가 비휘발성이라고 할 수가 있죠. 하지만 ODS는 휘발성이라는 특성을 갖고 있는 특징이 서로 확연하게 구분되는 특징이라고 할 수 있다는 점, 여러분 꼭 기억하시길 바랍니다. 또한 DW는 저장과 접근 중심의 기능 중심이라고 한다면 ODS는 업데이트한 저장 환경에서 DB가 할 수 있는 모든 처리를 할 수 있는 것이 바로 ODS라고 할 수가 있고요. ODS 본연의 역할은 결국 무엇이냐면 운영 시스템에 있는 데이터를 통합을 해서 실시간으로 정보를 제공하는 것이 바로 ODS의 본연의 역할이라고 할 수가 있습니다. 여기서 키워드는 바로 실시간이라는 걸 여러분 꼭 기억하시기 바랍니다. 그래서 작업 단계는 ODS 작업 단계는 ETL 작업 단계와 같다고 할 수가 있는데요. 첫 번째 소스 데이터를 획득하는 인터페이스 단계, 가상 공간이라 할 수 있는 스테이징 테이블에 적재하는 단계, 해당되는 품질 점검을 하게 되는 프로파일링 단계, 오류 데이터를 수정하는 클렌징 단계, 마지막으로 우리 데이터를 한 개의 테이블로 통합하게 되는 인테그레이션 단계, 마지막으로 해당되는 목표 시스템에 적재를 하게 되는 DW, DM에 적재하게 되는 Export 단계로 구성이 되어 있고요. 당연히 우리 시험에서는 이 작업의 순서를 물어보는 문제가 출제된다는 점 꼭 기억하시기 바랍니다. 1장 데이터 처리 프로세스의 ETL 마지막 소제목이죠. 소제목 내용 중에 DW, 데이터 웨어하우스입니다. ODS를 통해 정제 및 통합된 데이터는 결국 데이터 분석을 위해서 DW, 데이터 웨어하우스로 적재가 되는데요. 이런 데이터 웨어하우스는 4가지 특성을 가지고 있습니다. 첫 번째가 주제의 중심, 주제 지향성이라고 할 수가 있는데요. 운영 시스템에 있는 데이터들은 기능 중심으로 구성이 되어 있다고 한다면 데이터 웨어하우스의 데이터들은 사용자 중심의 일정한 주제로 형성된 데이터라고 할 수가 있습니다. 예를 들자면 우리 보험회사가 보험이 여러 가지가 있죠. 자동차 보험도 있고 화재보험도 있고 생명보험도 있는데요. 데이터 웨어하우스는 그것을 고객 또는 약관 또는 보험 상품으로 같은 주제 중심으로 묶여져 있는 것이 바로 데이터 웨어하우스라고 할 수가 있습니다. 다음 두 번째 특징으로는 영속성 또는 비휘발성이라고 할 수가 있는데요. 데이터 웨어하우스의 데이터는 어떤 시점에서 대용량의 데이터를 로드하고 그 다음에 액세스하는 반면에 일정 데이터들이 갱신 없이 읽기 전용의 데이터라고 할 수가 있습니다. 데이터 웨어하우스는 두 가지 오퍼레이션만 존재하게 되는데요. 바로 로딩과 액세스라고 할 수가 있습니다. 따라서 데이터 웨어하우스의 데이터가 로드가 되면서 우리는 읽기 전용의 스냅샷 형태로 저장을 하게 되죠. 따라서 데이터 웨어하우스는 수시로 변하지 않는 비휘발적 특성을 가지고 있다고 할 수가 있습니다. 세 번째는 통합성인데요. 우리 다양한 어플리케이션을 통해서 우리는 DW 목표 시스템의 DW 적재가 되겠죠. 하지만 다양한 어플리케이션에 들어있는 코딩은 다 각기 다를 겁니다. 예를 들자면 어떤 DB에서는 남자를 Male로 되어 있을 테고요. 그 어플리케이션에서는 그거를 숫자로 아마 코딩이 되어 있겠죠. 이와 같은 것을 하나의 버전으로 데이터 웨어하우스에 적재하는 것을 우리는 통합성이라고 합니다. 마지막 특성이라고 할 수 있는 시계열성이라는 것은 무엇이냐면 우리 운영 시스템의 시스템은 항상 현재 시점을 기준으로 해서 최신값을 유지하려고 하는 반면에 데이터 웨어하우스는 일정 시간에 데이터를 수집했을 때 갱신 없이 기간별로 저장을 하게 되어 있는데요. 기간이라는 건 뭐냐면 월, 분기, 연 단위로 기간별 저장되어 있는 데이터라고 할 수가 있습니다. 따라서 여러분 한 가지 주의하실 것이 있는데요. 이 데이터 웨어하우스의 시계열성이라는 것은 시간에 따라 데이터가 변화가 된다는 의미가 절대로 아닙니다. 시간에 따른 변경사항을 항상 반영한다는 의미라는 것을 여러분 꼭 기억하시기 바랍니다. 따라서 데이터 웨어하우스의 데이터는 항상 현재와 과거 데이터를 다 동시에 보유한다고 할 수 있는 특성이 바로 데이터의 시계열성이라는 걸 여러분 꼭 기억하시고요. 우리 시험에서는 데이터 2의 1과목에서 데이터베이스의 특징을 기억하십니까? 그거와 혼용해서 문제가 나올 수도 있고요. 중요한 부분은 시계열성과 영속성, 비휘발성에 대한 개념을 물어보는 문제가 출제된다는 점, 여러분 꼭 기억하시기 바랍니다. 다음은 데이터 웨어하우스의 스키마 구조인데요. 데이터 웨어하우스는 사용자의 다양한 질의사항을 빠르게, 신속하게 처리하는 것이 목적이라고 할 수가 있어요. 그러면 기본적으로 모델링을 해야 되는데요. 우리가 RDB 2차원 모델, 2차원이잖아요. RDB는 가로, 세로, 엑셀과 같은 시트 모양이니까 그거를 모델링해서 다차원 모델링을 만들게 됩니다. 다차원 모델링은 크게 두 가지로 구성이 되어 있는데요. 개별 집계값을 볼 수 있는 Fact Table, 즉 사실 테이블과 관심 있는 Fact Table을 좀 더 자세히 확인하기 위해서 드릴다운하게 되는데, 그럼으로써 생기는 차원 테이블, 이 두 가지가 구성이 되어 있고요. 이 다차원 모델링을 구성하는 스키마가, 널리 사용하는 스키마가 두 가지가 또 있습니다. 그것이 바로 Star Schema와 Snowflake Schema가 있습니다. 여기에 등장하는 여러분 낯선 단어들이 존재를 하게 되는데요. 첫 번째가 정규화, 비정규화, 조인이라는 단어가 등장하게 돼요. 정규화, 비정규화 굉장히 중요한 개념이죠. 아마 정보처리 기사나 IT 관련 기술사 시험 문제에서는 아주 중요한 개념이라고 할 수가 있습니다. 하지만 우리 시험에서는 스타 스키마와 스노우플레이크 스키마의 장단점을 구분할 때 이 정규화와 비정규화 개념이 사용된다는 점 여러분 꼭 기억하시고요. 따라서 우리는 이 두 가지 특장점을 기억할 때 쓰는 개념 정도만 여러분 알고 가셔도 충분하다는 말씀 제가 말씀을 드립니다. 정규화라는 것은 어떠한 개념이냐 하면요. 관계 데이터베이스에서 중복을 최소화하기 위해서 데이터를 구조화하는 방법이라고 할 수가 있는데요. 여기서 키워드는 중복을 최소화한다는 것입니다. 그럼으로 인해서 중복을 최소화하기 위해서는 여러 테이블들이 쓰이게 되는데요. 나중에 스키마를 할 때 다시 한번 설명을 드리도록 하겠고요. 반면에 우리 비정규화라는 것은 어떤 의미냐 하면요. 좀 전에 정규화의 특성은 중복을 최소화하고 무결성을 유지하는 것이 정규화인 건 반면에 비정규화라는 것은 무엇이냐면요. 의미 있는 내용을 한 곳에 모아두자는 컨셉이에요. 단 그렇게 하기 위한 이유는 조회 성능을 업 시키기 위해서 이렇게 비정규화를 하게 되는 거죠. 또 한 가지 단어 Join이라는 말이 등장하게 돼요. Join은 여러 테이블 있을 때, 두 개 이상의 테이블 있을 때 그 테이블을 연결해서 검색하는 방법이라고 생각하시면 되는데요. 당연히 테이블 개수가 많아지면 많아질수록 Join의 수는 많아지겠죠. 그럼 Join이 많다는 건 뭡니까? 조회 성능이 떨어진다는 걸 의미하죠. 대신에 우리 여러 가지 다차원 모델링을 한다고 했잖아요. 하지만 복잡한 모델링을 하기에는 Join의 수가 증가할 수밖에 없겠죠. 그럴 때는 조인의 개수가, 테이블의 개수가, 즉 조인의 횟수 또는 테이블의 개수가 많아질 수밖에 없다는 사실 여러분 꼭 기억하시기 바랍니다. 그래서 우리는 크게 스키마 구조가 Star Schema와 Snowflake Schema가 두 가지가 있다고 말씀을 드렸고요. Star Schema는 무엇이냐면 팩트 테이블과 차원 테이블의 관계예요. 팩트 테이블은 우리 정규화가 되어 있고요. 제3정규화라는 정규화로 되어 있고 이 차원 테이블은 비정규화로 되어 있어요. 아까 비정규화 개념이 뭐라고 그랬죠? 중요한 걸 한 테이블에다 모아둔다는 얘기 말씀드렸죠? 그렇게 하는 이유는 조회 성능을 높이기 위해서 한다고 말씀을 드렸고요. 스노우플레이크 스키마는 무엇이냐면 차원 테이블과 차원 테이블의 관계예요. 위 구조 팩트 테이블은 똑같은데요. 스노우플레이크 스키마는 차원 테이블을 정규화 시켰어요. 하지만 스타 스키마는 비정규화 시켰죠. 정규화 시켰다는 건 무엇인가요? 테이블을 쪼갰다는 의미입니다. 중복 방지를 하기 위해서 테이블을 여러 개로 쪼갰다는 얘기예요. 이 개념 아주 중요합니다. 다음 장에 보시는 우리 시험에 늘상 항상 한 문제에 등장하게 되는 스타 스키마와 스노우플레이크 스키마의 특장점을 구별하도록 하겠습니다. 여기 보시면 이 개념들을 여러분이 이해하셔야 되는데요. 먼저 스타 스키마의 장점을 보도록 하겠습니다. 스타 스키마는 팩트 테이블이 제3정규화되어 있고 차원 테이블도 역시 차원 테이블은 비정규화되어 있다고 했죠. 비정규화는 한 테이블에 이미 있는 정보를 다 몰아넣은 거예요. 단지 조회 성능을 높이기 위해서 대신에 뭐가 희생이 되나요? 중복 최소화가 희생이 되고 무결성이 희생이 되는 거겠죠. 개념을 확인하도록 하겠습니다. 장점, 모델이 단순합니다. 눈 모양이잖아요. 정중앙에는 사실 테이블, 그리고 바깥에는 차원 테이블로만 구성이 되어 있습니다. 계층 구조고 단순하고, 조인 횟수를 줄인다? 당연히 차원 테이블이 비정규화, 한 테이블에 다 모아져 있으니까 테이블을 쪼갤 필요가 없잖아요. 그렇죠? 그래서 당연히 조인 횟수를 줄임으로써 응답 성능을 향상시키고자 하는 목적이 바로 비정규화입니다. 단순한 모형이고요. 단점이 하나 있어요. 중요한 포인트는 뭐냐면 이렇게 비정규화시키면서 잃는 게 아까 뭐라고 그랬죠? 중복성과 무결성을 잃게 됩니다. 그렇죠? 그다음에 비정규화니까 테이블이 한 개잖아요. 그러니까 모델이 유연하지 못해요. 복잡한 걸 처리하지 못한다는 말씀입니다. 그래서 단점 중에 중요한 키워드가 모델이 유연하지 못하다는 단점이 있습니다. 그럼 스노우플레이크 스키마를 확인하도록 하겠습니다. 장점, 여기는 정규화시켰죠. 차원 테이블을. 당연히 무결성과 중복성 굉장히 좋아지고요. 여기 중요한 키워드가 있는데요. Star Schema에 비해 상대적으로 작은 저장 공간을 요구한다는 의미가 있습니다. 정규화를 시키게 되면 테이블이 쪼개지잖아요. 쪼개진 테이블의 크기는 비정규화된 테이블이 다 모아지는 것보다 저장 공간이 되게 작아요. 정규화시킨 테이블들은 비정규화시킨 것에 비해서 공간이 작습니다. 이 점 중요한 개념입니다. 그 다음에 모델에 대한 이해도가 Star Schema에 비해 상대적으로 어렵다. 당연히 테이블이 다 쪼개져 있으니까 다 순차적으로 들어가서 확인해야 되니까 굉장히 어렵겠죠. 이와 같은 스타 스키마와 스노우플레이크 스키마의 장점과 단점을 구분하는 개념, 결국 이게 정규화와 비정규화를 구분하는 개념과 똑같다고 할 수가 있습니다. 따라서 굉장히 중요한 부분이고요. ADP 2과목 시험에서는 거의 매해 한 문제 스타 스키마와 스노우플레이크 스키마에서 문제가 난다는 점, 여러분 꼭 확인하시기 바랍니다. 기출문제 확인하도록 하겠습니다.

이 강좌의 맛보기 강의

ADP 2과목 데이터 처리 기술 이해
ADP 2과목 데이터 처리 기술 이해강좌 자세히 보기