[IT] 견고한 데이터 엔지니어링 정리 및 영어 공부 5

 

< 5. 원천 시스템에서의 데이터 생성 >

 

- OLTP 데이터베이스는 보통 짧은 지연 시간과 높은 동시성을 지원한다.

- OLTP 시스템은 단일 쿼리로 방대한 양의 데이터를 검색해야 하는 대규모 분석에 기반한 사용 사례에는 적합하지 않다.

- ACID 에서 일관성(consistency)이란 데이터베이스를 읽을 때 검색된 항목의 마지막으로 기록된 버전이 반환되는 것을 의미한다.

- ACID 에서 독립성(isolation)은 트랜잭션 간 간섭이나 영향이 없는 것을 의미한다.

- ACID 에서 내구성(durability)이란 정전 등 어떤 상황에서도 데이터가 손실되지 않음을 의미한다.

- ACID 제약을 완화하면, 복잡성은 증가하지만 성능과 확장성에 상당한 이점이 될 수 있다.

- ACID 특성은 데이터베이스가 일관된 형상을 유지하도록 보장하고, 앱 개발자의 작업을 획기적으로 간소화한다.

- OLAP 시스템은 대규모 분석 쿼리를 실행하도록 구축되어 있으며, 일반적으로 개별 레코드의 조회 처리에는 비효율적이다.

- OLAP 의 '온라인' 부분은 '들어오는 쿼리를 지속해 수신 대기하는 시스템'이라는 뜻으로, OLAP 시스템이 대화형 분석에 적합하다는 것을 의미한다.

- CDC(change data capture)는 데이터베이스에서 발생하는 각 변경 이벤트(입력, 갱신, 삭제)를 추출하는 방법이다.

- 로그는 최소한 누가, 무엇을, 언제 수행했는지를 수집해야 한다.

- 로그 해상도(log resolution)는 로그에 캡처된 이벤트 데이터의 양을 나타낸다.

- 로그 레벨(log level)이란 로그 엔트리(entry)를 기록하는 데 필요한 조건, 특히 에러와 디버깅에 관한 조건이다.

- WAL(write-ahead logging)은 undo 와 redo 기능을 활용하여 데이터베이스 보장과 복구에 중요한 역할을 수행한다.

- 생성, 조회, 갱신, 삭제를 의미하는 CRUD는 프로그래밍에서 일반적으로 사용되는 트랜잭션 패턴으로, 영구 스토리지의 네 가지 기본적인 연산 작업을 나타낸다.

- 이벤트 기반 아키텍처와 관련해 '메세지 큐(message queue)'와 '스트리밍 플랫폼(streaming platform)'이라는 용어가 서로 혼용되는 경우를 흔히 볼 수 있는데, 두 용어 사이에는 미묘하지만 본질적인 차이점이 있다.

- 메세지(message)는 둘 이상의 시스템 간에 전달되는 원시 데이터다.

- 이와 대조적으로 스트림(stream)은 이벤트 레코드의 추가 전용 로그이며, 이벤트가 발생하면 순서대로 누적된다.

- 스트림은 타임스탬프 또는 ID 로 이벤트 순서를 정렬할 수 있다.

- 시간은 모든 데이터 수집에서 중요한 고려 사항이다.

- 특히 스트리밍의 맥락에서는 데이터가 연속적인 것으로 간주되고 데이터가 생성된 직후 소비될 것으로 예상되는 만큼 시간이 훨신 더 중요하고 미묘해진다.

- '이벤트 시간(event time)'은 원본 이벤트 자체의 타임스탬프를 포함해 원천 시스템에서 이벤트가 생성된 시점을 나타낸다.

- 데이터가 생성된 후에는 어딘가로 수집된다. '수집 시간(ingestion time)'은 원천 시스템에서 메세지 대기열, 캐시, 메모리, DB, 혹은 데이터가 저장된 다른 위치로 이벤트가 언제 수집되었는지를 나타낸다.

- 수집 이후 데이터는 즉시 처리할 수도 있고, 몇 분, 몇 시간 또는 며칠 이내에 처리할 수도 있으며 단순히 무기한 스토리지에 보관할 수도 있다.

- '처리시간(process time)'은 수집 시간 이후 데이터가 처리(변환)될 때 발생한다.

- '처리에 걸린 시간(processing time)'은 데이터를 처리하는 데 걸린 시간으로 초,분,시간 등으로 측정된다.

- 정규화는 레코드의 데이터가 여러 곳에 중복되지 않도록 하려는 전략으로, 여러 곳의 상태를 동시에 갱신할 필요가 없으며 불일치를 방지할 수 있다.

- RDBMS 시스템은 일반적으로 ACID 를 준수한다.

- 시계열(time series)은 시간별로 정리된 일련의 값이다.

- 시계열 데이터베이스(time-series database)는 시계열 데이터의 검색과 통계 처리에 최적화됐다.

- 측정 데이터(measurement data)는 온도 센서와 같이 정기적으로 생성된다.

- 이벤트 기반 데이터(event-based data)는 모션 센서가 움직임을 감지할 때처럼 이벤트가 발생할 때마다 생성되는 불규칙하 데이터다.

- API(application programming interface)는 시스템 간에 데이터를 교환하는 표준 방식이며, HTTP 를 중심으로 구축된 인터페이스이다.

- 데이터 엔지니어는 종종 맞춤형 API 연결을 유지하는 데 상당한 에너지를 투자해야 한다.

- 현재 지배적인 API 패러다임은 REST(representational state transfer)이다.

- REST 는 GET, PUT 과 같은 HTTP 동사를 중심으로 구축되었지만, 실제로 현대의 REST 는 원래 논문에 기재된 동사 중 일부만 사용한다.

- REST 의 주요 아이디어 중 하나는 상호 작요이 무상태성(stateless)이라는 것이다. 즉 상태를 저장하지 않는다.

- 리눅스 터미널이 갖는 세션의 개념은 없으며, 각 REST 호출은 독립적이다.

- REST API 에서 데이터 수집 파이프라인 설정이 간소화됐다.

- 첫째로, 다양한 언어에서 클라이언트 라이브러리를 제공하는 경우가 많다.

- 클라이언트 라이브러리는 API 상호 작용(interaction) 코드를 구축하는 데 필요한 대부분의 표준 문안(기본 코드) 작업을 제거한다.

- 둘째로, API 와 상호 작용하고 데이터 동기화를 관리하는 다양한 서비스와 오픈 소스 라이브러리가 등장했다.

- 웹훅(webhook)은 단순한 이벤트 기반 데이터 전송 패턴이다.

- 원천 시스템에서 지정된 이벤트가 발생하면, 발생한 이벤트가 데이터 소비자의 HTTP 엔드포인트를 통해 소비자에게 전송된다.

- 일반적인 API 와는 반대로, 원천 시스템에서 데이터 싱크로 연결이 진행된다는 점에서 역 API(reverse API) 라고도 불린다.

- RPC(remote procedure call)은 분산 컴퓨팅에서 일반적으로 사용된다. 이를 통해 원격 시스템에서 프로시저를 실행할 수 있다.

- 메세지 큐(message queue)는 게시 및 구독 모델을 사용해 개별 시스템 간에 데이터를 비동기적으로 전송하는 매커니즘이다.

- 내결함성(fault tolerance)과 복원성(resilience) 덕분에 데이터를 안정적으로 생성, 저장 및 수집할 수 있다.

- 서비스 수준 목표(service-level objective. SLO)는 SLA 에서 합의한 내용과 비교해 성능을 측정한다.

- 원천 시스템은 일반적으로 데이터 엔지니어의 통제 밖에 있다.

- 보안은 매우 중요하며 원천 시스템에 실수로 취약점을 만드는 건 절대 바람직하지 않다.

- 원천 시스템은 데이터가 저장 및 전송되는 동안 데이터를 안전하게 암호화하도록 설계되어 있는가?

- 공용 인터넷을 통해 원천 시스템에 접근해야 하는가? 아니면 VPN 을 사용하는가?

- 원천 시스템에 대한 비밀번호, 토큰 및 자격 증명을 안전하게 보관하자. 예를 들어 SSH(Secure Shell) 키를 사용하는 경우에는 키 관리자를 사용해 키를 보호한다.

- 비밀번호에도 동일한 규칙이 적용된다. 비밀번호 관리자 또는 SSO(Single Sign-On) 벤더를 활용하자.

- 원천 시스템을 신뢰하는가? 원천 시스템이 합법적인지 확인하되 항상 신뢰해야 한다. 당신은 악의적인 행위자로부터 데이터를 수신하고 싶지는 않을 것이다.

- 데이터 거버넌스 : 업스트림 데이터와 시스템은 신뢰성이 높고 이해하기 쉬운 방식으로 관리되고 있는가? 누가 데이터를 관리하는가?

- 데이터 품질 : 업스트림 시스템에서 데이터 품질과 무결성(integrity)을 어떻게 보장하는가? 원천 시스템 팀과 협력해 데이터 및 통신에 대한 기대치를 설정하자.

- 스키마 : 업스트림 스키마가 변경되리라 예상하자. 가능한 경우 원천 시스템 팀과 협력해 스키마 변경에 대한 알림을 받자.

- 개인정보보호와 윤리 : 원시 데이터에 접근할 수 있는가? 아니면 데이터가 난독화되는가? 소스 데이터의 의미는 무엇인가? 얼마나 오래 보존되는가? 보존 정책에 따라 위치가 변경되는가?

- 규정 : 규정에 따라 데이터에 접근해야 하는가?

- 원천 시스템의 데이터가 다운스트림 사용에 대한 예상과 일치하는지 확인할 수 있는 검사를 설정하자. 예를 들어 데이터의 품질은 양호한가? 스키마가 적합한가? 고객 기록은 일관성이 있는가? 사내 정책에 따라 데이터가 해시 처리되고 있는가?

- 원천 시스템에 장애 발생 후 복구되면 그 동안 손실된 데이터를 다시 채울 계획을 마련해야 한다.

- 시스템이 예측 가능한 출력을 생성하는가?

- 시스템의 장애 발생 빈도는 어느 정도인가?

- 시스템이 충분한 신뢰성을 갖추도록 수리하는 데 걸리는 평균 시간은 얼마나 되는가?

- 불가피한 장애 또는 운영 중단이 관리되는 데이터 시스템에 미치는 영향을 고려해야 한다.

- 장기간에 걸친 운영 중단에 대처하고 그 폭발 반경을 제한하는 계획은 무엇인가?

- 원천 시스템이 예정된 시간에 정상적으로 가동되고 실행되며 사용할 수 있음을 보증하는 것은 무엇인가?

- 데이터 엔지니어는 원천 시스템을 유지 관리하는 팀과 협력해 이러한 시스템이 안정적으로 설계되도록 확인해야 한다.

- 원천 시스템 팀과 SLA 를 작성해 잠재적인 시스템 장애에 대한 예상치를 설정하자.

- 주기와 빈도 : 데이터가 정해진 일정에 따라 제공되는가? 아니면 언제든지 새로운 데이터에 접근할 수 있는가?

- 인증과 권한 : 원천 시스템에 접근하기 위한 적절한 자격 증명(토큰, 사용자 아이디 및 패스워드)을 가지고 있는가? 코드 또는 버전 컨트롤에 표시되지 않도록 이러한 자격 증명을 어디에 저장할 것인가? 코드화된 작업을 수행할 올바른 IAM role 이 있는가?

- 모든 접근 패턴에서 재시도나 타임아웃 등은 어떻게 처리되는가?

- 원천 시스템에 대한 병렬 접근을 어떻게 관리하고 확장하고 있는가?