서재(書齋)

15 May 2023 - ID G00789838

By Mayank Talwar, Joe Antelmi 

개요

• 데이터 가상화(DV, Data Virtualizaion)는 온프레미스, 엣지 컴퓨팅, 클라우드 등 다양한 환경을 갖춘 복잡한 데이터 생태계 관리/거버넌스를 간소화
• 데이터의 과도한 물리적 이동 없이도 통합이 가능
• 데이터 관리 플랫폼의 기능을 향상시키지만 대체제는 아님
• 데이터 패브릭/데이터 매시와 같은 최신 데이터 아키텍처를 형성하는 데 중요한 역할

추천사항

• 복잡한 추출, ETL, 대용량 데이터 처리 등 복잡한 데이터 구조가 포함된 시나리오에서는 적합하지 않음

데이터 가상화란?

• 이기종 데이터 소스에 대한 쿼리 및 결과를 가상 뷰로 통합
• 물리적 X, 메모리 O
• 물리적 데이터 소스 위의 가상화 레이어가 추가되는 것
• 복잡한 쿼리, 네트워크 지연, 트랜젝션 단위로 처리되는 시스템이 데이터 소스로서 다수 등의 환경에서는 적합하지 않음

장점

• 무엇을 질의할지 정해지지 않은 경우 (Known Data / Unknown Questions)
  - IT가 유용한지 아닌지 알기 위해 PoC 등에 기간을 낭비하는 대신 DV를 도입해 유용성을 검증한 후 구축/개발 요청
  - 단, DV를 사용하는 주된 방법은 GUI가 아닌 SQL이므로 검증 단계에서 데이터 스키마나 품질에 대한 이해가 없다는 단점
• 무엇을 가지고 있는지 정해지지 않은 경우 (Known Questions / Unknown Data)
  - 데이터가 알려지지 않으면 메타 데이터 부족, 카탈로그화, 구조화되지 않은 환경인 상황. 이 때는 실제 파이프라인 구축 없이 데이터 탐색이 가능한 장점 발휘
• 여러 소스의 메타데이터 저장, 캐싱을 통한 쿼리 가속화

분석 사용 사례

• 신속한 프로토타입 제작
• 의미 계층(Semantic Layer)
• Data Prep. / Data Science Sandbox
• 데이터 규제 요구사항 처리
  - 데이터를 물리적을 전송하는 것을 제한하는 조항 등이 있는 경우
• 데이터 거버넌스
  - 모든 데이터를 쉽게 검색, 중복성 및 품질 문제 등을 빠르게 Catch, 다수 소스의 데이터에 대한 마스킹
  - 데이터 쿼리 감시, 전체 로그 보관, 데이터 엑세스 확인 등 가능
• 가상 데이터 마트
  - DW에서 DM으로의 물리적 데이터 이동 프로세스 감소
  - 실시간 라이브 데이터 확인 가능

운영 사용 사례

• 신속한 인사이트 도출
  - Ex. 실시간 재고 관리
• Time To Market
  - ETL 등 절차를 생략한 빠른 통합, 신속한 제품 출시
• 가상 운영 데이터 저장소(ODS)
  - 데이터 페더레이션을 통한 통합 뷰 생성
  * 데이터 페더레이션은 여러 데이터 저장소에 존재하는 데이터의 물리적 요소를 추상화하여, 단일 엑세스 채널을 통해 조회하고 메모리 상에서 통합하는 가상적 통합 방식
  * 데이터 페더레이션은 데이터 가상화를 이루는 기반 기술로 더 하위 개념
• '레지스트리 스타일'의 마스터 데이터 관리
  - 고객, 업체, 제품 등 주요 비즈니스 엔터티에 대한 단일 뷰 생성
• Legacy System Migration to Cloud
  - 마이그레이션 프로토타입 : 레거시 시스템 -> 추상화 계층으로써의 DB -> 클라우드
  - 실제 마이그레이션 시 ETL Flow로 채택 가능
  - 클라우드 데이터의 Egress 비용 절약
• 캐싱
  - 데이터 이동 최소화를 통한 성능 향상
  - Egress 비용 절약
  - 로컬 파일 또는 DB에 캐싱

데이터 가상화 구성 요소

1. 연결 계층 (Connectivity layer)
   - RDB(w/ JDBC, ODBC), Kafka, 플랫 파일 및 CSV 파일 등과 호환되는 전체 데이터 소스 연결부
2. 연합 및 분산 쿼리 엔진 (Federated and distributed query engine)
   - 입력 쿼리를 서브쿼리로 분할
   - 쿼리 실행 계획을 통한 실행
3. 쿼리 최적화 (Query optimization)
   - 캐시, 쿼리 재구성, 푸시다운, MPP 지원 등
4. 지속성 (Persistence)
   - 소스 데이터에 대한 수정 가능
5. 메타데이터 저장소 (Metadata repository)
   - 페더레이션 조인을 가능하게 함
   - 데이터 패브릭 기능의 기반을 형성
6. 보안 및 거버넌스 계층 (Security and governance layer)
   - 개인 정보 인식 및 권한에 따른 마스킹 처리
   - 표준 권한 부여, 인증 메커니즘, 행/열 수준 보안 제공
   - 기존 ID 및 액세스 관리 도구를 대체할 수는 없음
7. 소비 계층 (Consumption layer)
   - API, 연결 표준, 인터페이스 등으로 데이터를 사용자에 제공
   - 표준 오류 메시지 및 오류 코드 추가
8. 디자인 인터페이스 및 도구 (Design interfaces and tools)
   - CDE 및 전문 DE 모두 활용 가능한 UI 제공

최신 데이터 아키텍처를 위한 데이터 가상화

• 데이터 허브
  - 데이터 종속성을 모두 수용하는 것이 마이그레이션의 가장 큰 어려움
  - 커넥션(복잡성)의 수 : M(분석 도구)*N(데이터 소스) (각 데이터 소스에서 개별 연결) vs M+N (추상화 계층 사용)
  - 즉, 마이그레이션 된 데이터와 데이터 추상화 계층과의 관계만 잘 조정하면 됨
  - 아래 조건이 추가로 충족되면 데이터 허브로 사용할 수 있음
     1) DV 서버 중 하나가 고성능 데이터 저장소
     2) 각 원본 데이터 저장소에 Write 할 수 있어야 함 (솔루션에 따라 ACID 지원 불가할 수 있음)
• 논리적 DW (LDW) / Lakehouse
  - LDW는 이미 성숙한 개념으로써 BP임
  - LDW의 주 목표는 개별 구성 요소/엔진의 재사용 극대화를 통한 총 소유 비용 최소화
  - 각기 흩어진 DL, DW, 레거시 BI 및 DB를 통합하기 위한 LDW 아키텍처에서 다양한 구성 요소의 가상화 및 통합을 가능하게 함
  - 이미 많은 DW 플랫폼이 DL에 External Table을 만들어 접근하고 있으며 이 단계에서 가상화는 여러 저장소의 데이터 결합에 사용됨
• 데이터 패브릭
  - 다양한 데이터 통합 스타일의 조합
  - 활성 메타데이터, 지식 그래프, 시멘틱, 머신 러닝을 활용하여 데이터 통합 설계 및 제공 증강
  - 새로운 데이터 관리 설계이며 단일 도구나 기술이 아님
  - 필수 구성 요소 (단, 모든 구성 요소가 다 필요한 것은 아님) : 증강 데이터 카탈로그, 시멘틱 강화 지식 그래프, 메타데이터 활성화, 추천 엔진, 데이터 프렙 및 전달 계층, 오케스트레이션 및 DataOps
    * 데이터 프렙 및 전달 계층 : 수집 및 연결 등을 조합하여 가장 최적의 방안을 제공해야 함
    * 증강 데이터 카탈로그 : 메타데이터 관리를 통한 기존의 카탈로그 + ML을 통한 자동화
       Google 스타일 검색, 개인화 및 추천, 비즈니스별 데이터 프렙, 소셜미디어 스타일 협업, 리니지 등에 활용 가능
       데이터 소스별 활용 빈도, 성능 등 각종 메타데이터를 AI/ML 엔진에 공급 및 활용
• 데이터 매시
  - 모놀리식 데이터 플랫폼(중앙 집중형 데이터레이크)을 넘어 분산 도메인 소유권
  - 원본 소스와 유즈케이스에 초점
  - 네 가지 핵심 개념 : 도메인 중심 데이터 소유권, 제품으로써의 데이터, 데이터 즉각 접근(셀프 서비스), 분산 데이터 거버넌스
  (추가 작성 필요)

공급업체

• Denodo
• IBM
• SAP
• SAS
• TIBCO Software 등

성공 요인

• 가용한 데이터 소스
  - 데이터 소스의 라이브 데이터를 사용하므로 다양한 데이터 소스 필요
  - 동시 작업 빈도, 수평/수직 확장 가능 여부 등
• 데이터 전환의 복잡성
• 기존 데이터 통합을 통한 데이터 가상화 보완
  - ETL, ELT, CDC 등 기존 데이터 통합 스타일 대체에 DV 사용 시 실패함
  - DV는 알려지지 않은 것을 발견하거나 모든 데이터 소스 상위에 단일 데이터 창을 형성할 때 성공
  - 일반적인 데이터 통합은 유지하고, 구축된 DW 등에서 데이터를 가져오는 것이 더 좋음
• 데이터 엔지니어링 및 IT 지원
• 데이터 거버넌스
• 올바른 도구 선택 및 기존 기능과의 중복 방지
• 하이브리드 및 멀티 클라우드

강점

약점

안내사항

Ideation

• 데이터 가상화 기반의 Gen BI 적용
  - LLM에 RAG 적용 시 데이터 가상화 기반의 데이터 메타 제공

관련 자료

• https://www.datanews.co.kr/news/article.html?no=125831

• https://www.dvirtual.kr/function-intro1/

• https://www.ibm.com/kr-ko/products/watson-query

What happend?

puppeteer 기반의 크롤러 기능 중 loop를 돌며 화면 내의 '다음' 이동 버튼을 클릭하며 데이터를 수집하는 부분을 개발하고 있었다.

클릭 후 자체적으로 setTimeOut을 활용해 만든 delay 함수를 호출시켜 대기 후 루프를 돌게 했는데도 자꾸만 몇개 데이터가 중복으로 들어가서 원인을 찾느라 몇 시간을 썼다.

What went wrong?

루프를 도는 함수 내에서 click에 await를 걸어주지 않았다.

여기서 주의할 점이, puppeteer에서 제공하는 $를 사용해 가져온 객체는 ElementHandle로 반환되고, querySelector를 사용해 가져온 객체는 그냥 Element로 반환된다는 점이다.

다른 로직에서는 eval 함수 내부에서 특정 버튼을 querySelector로 가져왔다. 

그렇게 가져온 요소는 Element이므로 click 시에도 Promise를 반환하지 않으므로 그냥 await 없이 동기 호출했다.

이 기억때문에 오류가 난 부분에도 동일하게 await를 걸어주지 않았고, 따라서 click 이후 await 대기한 뒤 후속 작업을 진행해야 하는데 대기 없이 비동기 로직들은 남겨두고 루프가 추가로 돌아버렸고, 그래서 몇번의 중복 루프가 추가적으로 수행 & 중복 데이터가 입력된 것으로 보인다.

Lesson & Learned

따라서 puppeteer $ 함수로 가져온 객체를 click시, async 함수 내에서는 반드시 await로 호출해 대기하자.

끝.

What happend?

서비스에 Drag & Drop 기능이 필요하여 react-beautiful-dnd 라이브러리를 사용해 Component를 구현하였다.

DragDropContext와 Droppable을 합쳐 하나로, Draggable을 또 다른 하나로 해서 2개 컴포넌트로 분리했다.

리팩토링을 하던 중, 기존에는 발생하지 않던 Warning이 반복적으로 발생하였다.

DragDropUserAttrCard는 사용자가 직접 눌러서 드래그 앤 드롭을 할 컴포넌트(Draggable)인데, 아래와 같이 분리한 해당 컴포넌트 내에는 분명히 key가 존재하는데도 계속 Warning이 발생하였다.

What went wrong?

Key는 분리한 컴포넌트 내부가 아니라, 외부에서 할당해야 오류가 해결되었다.

내가 Customizing한 Draggable인 DragDropUserAttrCard가 사용되는 부분에 key를 선언해야 한다.

또 하나, 나는 이 key가 prop인 줄 알고 그대로 받아서 DragDropUserAttrCard 내부에서 다시 한 번 key를 할당했으나, 그렇게 하면 key는 prop이 아니라는 오류가 떴다.

아무리 생각해도 이상해서 DragDropUserAttrCard 선언 시 key를 이상한 값으로 넣어보고 생성된 html을 살펴보니, 해당 key값은 렌더링 시 사용되지 않는 것 같았다.

Lesson & Learned

• react-beautiful-dnd 라이브러리 사용 시, Draggable 컴포넌트의 key prop은 크게 의미가 없으며, 렌더링 시 사용되는 Unique한 구분자는 draggable-id이다.
• 다만 react를 일반 html로 컴파일 시, 해당 라이브러리의 Droppable이나 Draggable과 같은 컴포넌트들이 각각 ul와 li와 같은 html 컴포넌트로 변환되는 과정에서 ul과 li에 필요한 key 속성을 Draggable에 반드시 입력해주어야 하는 것으로 보인다.
• 이 때, Draggable 영역을 따로 묶어 별도 컴포넌트를 만들었다면, 해당 컴포넌트 소스 코드 내부가 아닌, 컴포넌트를 선언해 사용하는 상위 컴포넌트에서 key를 할당해주어야 한다.

끝.

한동안 잘 사용하고 있던 Docker Desktop이 언젠가부터 'Docker Desktop Starting...' 메시지만 무한정 표시되더니 정상적으로 실행되지 않는 현상이 발생하였다.

구글링을 통해 여러 해결책을 찾아보았으나, 나의 경우(Windows 10 Home 환경)에는 아래와 같은 순서로 해결했다.

1. Docker Desktop 삭제
2. 재부팅
3. C:\Users\{본인 사용자 계정}
   위 경로에서 .docker 폴더 삭제
4. Docker Desktop 재 설치

.docker 폴더를 삭제하지 않고 재 설치시에는 동일한 현상이 여전히 유지되었으므로, 반드시 .docker 폴더를 삭제하고 재설치하도록 하자.

끝.

typeorm 공식 문서는 조금 불친절한 감이 있는 것 같다.

What happend?

CreateDateColumn 등의 데코레이터 사용과 관련, 공식 Document에는 별다른 설명 없이 아래와 같은 예제만 덜렁 주어져 있다.

 위 내용을 참고하여 해당 데코레이터만 추가했더니, 테스트 시 created_at 컬럼이 정상적으로 입력되지 않았다.

What went wrong?

검색 결과, 공식 문서에는 별다른 언급이 없지만 DB 내에서 Default Value 설정이 되어 있어야 해당 값을 입력해 주는 방식인 것 같았다.

MySQL 테이블 스키마의 디폴트 값을 아래와 같이 CURRENT_TIMESTAMP로 지정해 주어야 행 생성 시 생성 시점이 정상적으로 기록된다.

Lesson & Learned

• typeorm 공식 문서의 불친절함을 배움

끝.

NestJS 개발 시 DTO로 입력되는 값을 Validation 하고 싶을 때, ValidationPipe를 많이들 사용하곤 한다.

이번에 ValidationPipe를 활용하여 백엔드 API를 개발하던 중 겪은 에러가 있어 기록한다.

What happend?

우선, NestJS App 생성 시 ValidationPipe의 whitelist & forbidNonWhitelisted 옵션을 모두 true로 설정했다.

    this.defaultApp.useGlobalPipes(
      new ValidationPipe({
        whitelist: true,
        forbidNonWhitelisted: true,
        transform: true,
      }),

그리고 Postman을 활용하여 POST 로직을 테스트했는데, 아래와 같이 DTO가 상속한 Entity에는 네 항목이 모두 존재하는데도(우측 창 - 해결 후 상황을 재현하느라 Type Decorator들이 주석 처리되어 있다.) 모든 항목이 없어야 한다며 에러를 내뱉는다(좌측 창).

What went wrong?

졸린 와중에 개발 & 검색하느라 원문을 잃어버렸지만, 구글 검색 결과 중 특정 글에서 'DTO의 각 항목은 최소한 하나의 Type Decorator를 가져야 한다'는 글을 보고 아래와 같이 수정하였다.

수정 후에는 우측 아래 console.log를 보면 정상적으로 body 수신이 되고 있음을 볼 수 있다.

 Lesson & Learned

• ValidationPipe whiteList 옵션 사용 시 반드시 Type Check Decorator를 지정하자.

멍청한 에러들을 기록한다.

What happend?

NestJS로 백엔드 개발을 하던 중, 기존 Array에 push하는 부분에서 자꾸만 'ERROR [ExceptionsHandler] XXX is not a function' 에러가 발생했다.

로직도 수차례 변경해 보고, push 함수가 아니라 새로운 Array를 만들어 slice로 깊은 복사 후 재 할당도 해보고 온갖 짓을 다 했으나 해결이 안 됐다.

자고 일어난 다음날, 테스트를 하다가 해결했다.

역시 졸린 상태에서는 개발하는 거 아니다.

What went wrong?

Movie 정보를 담고 있는 this.movie는 Array인데, update시 호출하는 deleteMovie 로직에서 delete 후 Array가 아닌 List로 담는 바람에 오류가 발생했다.

List에는 당연히 push function이 없으니까 위와 같은 에러가 발생한다.

 Lesson & Learned

• API 테스트 결과 확실히 살피기 - 자료형이나 Depth 등이 변하진 않았는지
• TypeScript 맹신하지 않기 - movies를 Movie[]로 선언하였으나 로직 중에 해당 변수에 List를 할당해도 에러가 발생하지 않는다.
  (그러나 다이렉트로 movies = {}; 따위를 넣어버리면 오류가 발생한다.)

끝.

VSCode에 아직 익숙하지 않아서 자주 쓰는 단축키를 정리해 놓으려고 한다.

• 자동 정렬 - Shift + Alt + F
• 탭 간 이동 - Ctrl + Tab
• 주석 처리 - Ctrl + /
• 동일 단어 선택 (하나씩) - (특정 단어 블록 선택 후) Ctrl + D
• 라인 삭제 - Ctrl + Shift + K
• 이전 커서 위치로 이동 - Alt + 왼쪽 화살표