주요 IT 기업의 모던 데이터 시스템

이번 글에서는 주요 IT기업의 데이터 시스템을 중점으로 데이터 엔지니어링이 무엇인지 알아보려고 합니다. 

이 글은 한글로 된 데이터 엔지니어링 관련 자료가 많이 없는 것으로 보여 이해를 돕기 위해 고려사이버대학 소프트웨어공학과 졸업 논문으로 쓰여진 원문(영어)을 바탕으로 작성하였습니다. 

초록

최근 IT 기업에서 발생하는 다양한 요구사항을 충족시키기 위해서 많은 데이터 도구들이 개발되어 왔습니다. 각 도구들의 탄생 배경은 다양하고 달라보이나 추상화와 구조화를 통해 다양한 도구들을 일관된 프레임으로 비교하고 분석할 수 있습니다.

 

아래에서는 기존에 데이터 파이프라인[3]에 자주 사용되던 개념인 ETL을 확장하여 6가지 단계(Collect, Move, Store, Process, Use, Orchestrate)로 나누고 주요 IT 기업들의 다양한 데이터 도구들을 그룹화하였습니다.

 

참고한 IT 기업들은 주로 애플리케이션 서비스 기업들로 Google, Amazon, Microsoft, Uber, Netflix, LinkedIn, Facebook, Huawei 등을 고려하였습니다.

 

 

개요

전통적으로 데이터 시스템은 RDBMS에 있는 Transactional 데이터를 분석하고 통계를 얻는 것으로부터 시작되었습니다. 데이터 웨어하우징, OLAP[10], 전사적 정보 관리와 같은 개념들이 탄생하였고, Vertica[5],Sybase IQ[6]와 같은 도구들을 통해 분석가, business intelligence 매니저의 요구사항을 다루던 시기였습니다. 이후 데이터 사이즈가 증가하고 Hadoop 환경에서 대규모 데이터 저장, 처리와 함께 많은 주변 기능을 제공하면서 데이터 시스템의 메인스트림이 Hadoop 환경으로 이동하기 시작하였습니다. Hadoop 환경으로 이동하면서 크게 변화한 성능에 대한 개념은 scaling-up 보다는 scaling-out이 주요한 확장방법이 된 부분입니다[1]. 

하둡 환경 구성 - 출처: Architecting Modern Data Platforms

이전의 변화는 BI 또는 기존의 분석 측면에서의 요구로 촉발된 반면, 이어지는 변화는 A/B 테스팅[7] 또는 딥러닝[8]과 같은 측면에서 발전해가며 서비스와도 좀 더 연계성이 높은 형태를 보이고 있습니다. Data Lake[14], Feature Store, HTAP[15]와 같은 개념들이 도구들과 함께 만들어지 탄생하였습니다.

 

데이터 환경의 프로세스의 상세한 부분은 기업의 고유의 환경에 따라 다르지만 수집(Collect), 이동(Move), 저장(Store), 가공(Process), 사용(Use), 운영관리(Orchestrate)이라는 추상화된 관점에서는 유사한 형태를 보입니다. 예로, Netflix의 추천시스템이라는 부분을 보았을 때는 아래와 같은 단계별 도구와 이행이 필요합니다:

 

• 수집: 사용자들의 영상 시청 시간, 평점 등의 데이터를 수집
• 이동: 수집한 데이터를 저장소로 이동
• 저장: 이동시킨 데이터를 추후 가공 및 사용 목적에 맞는 곳에 저장
• 가공: Raw 데이터를 가공하여 사용할 데이터를 생성
• 사용: 가공한 데이터와 다양한 데이터 도구들을 통해 데이터를 사용
• 운영관리: 위의 다양한 단계에서 다양한 도구들을 요구사항에 맞게 운영하고 관리함

또한, 아래의 Google의 데이터 환경을 살펴보아도 상세한 부분은 조금 다르나 큰 관점에서 위의 Hadoop 환경과 유사한 목적의 도구들이 각 단계에 위치해있는 것을 관찰할 수 있습니다.

The Goole Infrastructure Stack - 출처 [31]

아래에서는 위에서 언급한 데이터 파이프라인 6단계(Stage)와 각 단계별 도구들을 살펴보겠습니다.

 

728x90

데이터 파이프라인의 단계와 각 단계의 구성

이번 문단은 아래의 6단계로 구성되어 있습니다:

• 수집: 일시적인(transient)한 데이터를 임시적 또는 영구적 사용 목적으로 인프라 시스템으로 수집합니다
• 이동: 수집된 데이터를 버퍼(또는 fast-storage)나 장기 저장소로 이동(그리고 어떤 경우는 전처리)시킵니다
• 저장: 저장소(주로 분산저장소)에 데이터를 저장합니다
• 가공: 프로세싱 엔진을 사용하여 데이터를 가공하거나 변형합니다
• 사용: 데이터 자산을 직접 사용하거나 다양한 서비스를 통해 데이터를 사용합니다
• 운영관리: 위 단계의 여러 서비스와 리소스, 관련 업무를 운영하고 관리합니다

수집

대부분의 애플리케이션 서비스 기업에서 데이터의 원천은 주로 아래 4개의 그룹으로 나누어 집니다:

• 상용 데이터와 변동로그(Change logs): Transactional 데이터베이스와 주로 CDC[11]로 수집되는 해당 데이터베이스의 변동로그
• 서버로그[12]: 서버에 요청한 client의 요청에 대한 서버의 로그
• 클라이언트이벤트로그(Clieckstream): 클라이언트 기기에서의 이벤트 트래킹[13] 결과 로그로 서버나 시스템에 저장을 위해 클라이언트에서 송신
• 외부 데이터: 서비스 내에서 발생한 데이터가 아닌, 외부에서 유입된 데이터

'운영계' 데이터와 변동로그

이벤트 소싱과 같은 아키텍쳐 패턴이 나오지만, 뒷단의 OLTP 데이터베이스는 아직 산업표준[16]으로 여겨지고 있습니다. 데이터 사이즈가 상대적으로 작을 때는 단순한 RDBMS로 서비스 요구사항을 다룰 수 있으나 데이터 사이즈가 커지고 복잡한 요구사항이 발생하며 좀 더 발전한 CDC[17] 같은 도구들을 사용하게 됩니다. 이 경우 CDC는 데이터를 복제하고 모든 변동로그를 남기기위해 사용될 수 있습니다. CDC는 구현 방법에 따라 3가지 그룹(Log reader, Query, Trigger[11])으로 나뉘며(예시로, Oracle OGG[18],Striim[19]), 현재 시점에서는 데이터를 복제하여 write과  read를 분리하는 목적으로 주로 사용되는 듯 합니다(CDC 변동로그를 사용하는 형태는 데이터 운영과 시스템이 충분히 고도화 된 사례에서만 가능할 듯 합니다). 

 

서버로그

전통적으로 로그는 주요 목적이 보안[20]이나 운영을 위한 시각화된 모니터링[21]에 있었습니다. 이후 로그의 크기가 점점 증가하게 되면서, 통합적이고 효율적인 로그 관리가 필요하게 되면서 로그 운영(log management)[22]의 개념이 탄생하였습니다. 시장의 많은 로그 관련 도구들은 모니터링을 위한 GUI 서비스가 포함되어 있습니다. 현재까지도 많은 서버 로그들이 보안[23]에 사용되고, 추가적으로 분석[24]을 위해서도 사용되고 있습니다. 인하우스 도구로는 Facebook의 Scrib와 같은 것이 존재하고 여러 상용 또는 오픈 소스(Filebeat, Fluentd) 등이 존재하며 대부분 agent-aggregator 구조를 가지고 있습니다. 

 

Clickstream

클릭 이벤트 트래킹은 초기에 identification을 위해서 다양한 방법의 fingerprinting 기법[25]에 기반한 웹 트래킹으로 시작하였습니다. 그러한 identification은 디지털 마케팅, 보안, 트래픽 검증[26]에 사용되었었습니다. 프라이버시 이슈가 점차 부각되면서 이전 보다는 점점 기기에서 데이터를 수집하는 것이 까다로워지고 있기는 하나[27], A/B testing 또는 추천시스템 등 다양한 데이터 서비스들의 기반에는 clickstream 데이터가 중심적인 역할을 하고 있습니다. 

 

구현에 있어서는 이벤트 로그에 대한 정의와 포맷[28]을 정하고, 서비스에 트래킹 코드를 심고 데이터를 받은 API endpoint를 셋업하는 형태로 대부분 유사한 구조로 구현되고 있습니다[29, 30].

 

 

이동

이동은 앞단의 수집에서 수집한 데이터를 저장소로 이동시키는 부분입니다. 일부 구현에 따라 수집 부분 또는 이후의 저장 단계와 얽혀 의존성이 강하거나 약할 수 있고, 또한 실제 서비스도 결합되어 있는 경우[33]가 있습니다. 이 부분에서는 앞단에 이어 각 수집 형태별로 주 이동 형태를 살펴보겠습니다.

 

파이프라인의 다른 단계에서도 배치(Batch) vs 스트림(Stream, 실시간)[9]으로 구분되는 형태가 자주 발생합니다. 이후의 설명을 위해, 짧게 정의하자면 아래와 같습니다:

- 배치: 일정 기간 동안 이미 저장된 데이터 블럭을 프로세스 하는 것
- 스트림: 데이터를 받은 시점으로부터 짧은 시간의 간격을 빠르게 감지하여 데이터를 실시간으로 프로세스 하는 것

 

'운영계' 데이터와 변동로그

실시간으로 CDC와 같은 형태로 '운영계' 데이터를 수집하고 더 세밀한 데이터 사용을 하는 것은 더 풍부한 데이터라는 점에서는 좋지만, 배치 형태의 데이터 이동은 아직 많은 기업에 존재합니다[32]. 비록 많은 프로세싱 엔진(Apache Spark, Mapreduce, Presto 등)이 배치 또는 (준) 실시간으로 데이터를 이동시키는 데에도 사용될 수 있지만, 이 부분에 좀 더 특화된 도구들을 꼽자면 Apache Sqoop, Embulk, AWS DMS 등이 존재합니다. 

 

운영과 관련해서는 운영계의 데이터의 경우 개인정보를 포함하거나 권한에 따라 접근 가능여부가 달라야 하므로 컬럼의 선택, 암호화 등의 전처리가 포함되는 경우가 종종 존재합니다.

 

서버로그

서버로그와 같은 경우 수집 단에서(주로 agent) 저장소까지 데이터를 저장하는 형태가 대부분입니다(카카오의 KEMI와 같이 일부 polling 방식으로 사용하기도 합니다). 이 구간에서는 서버로그의 경우 대부분 저장소로 수집단에서 바로 송신되기에 aggregator나 간단한 API 정도가 존재합니다. 

 

Clickstream

클릭 이벤트 데이터의 경우 클라이언트 기기에서 수집을 위해 구축된 API endpoint로 송신하고 해당 endpoint에서 데이터를 받아 실시간으로(비록 성능을 위해 일정한 단위로 압축하거나하여 처리하나) 저장소로 옮겨집니다. 역시 '운영계' 데이터와 변동로그에서와 유사하게 일부 데이터의 경우 개인정보와 관련된 부분이 존재하거나 이동 시 암호화를 요구하기에 클라이언트 단에서 암호화 된 것을 복호화해서 저장하거나, 그대로 암호화된 상태로 저장하거나, 암호화해서 저장하는 등 개인정보 데이터 특성에 따라 전처리되는 경우가 있습니다. 

 

저장

저장과 관련한 부분에서는 저장소, 파일시스템, 파일포맷과 압축형태 등 다양한 개념이 있으나 이 글에서는 저장소와 관련된 부분을 중점적으로 다루려 합니다. 또한, 초록에서 언급한대로 Hadoop 환경의 중심적인 역할을 하는 HDFS(GFS)와 같은 분산저장소를 중심으로 특징과 관련 도구들을 살펴보겠습니다.

 

Google File System(HDFS 구현의 모태)이 해결하려고 했던 문제는 아래의 4가지 였습니다[38]:

• 가성비있는 상용 컴퓨터 수천대에 데이터를 저장하기 위해 읽고 쓰는 것
• 데이터 크기의 확장성
• append가 중심적인 일(task)의 최적화
• 애플리케이션 측면의 복잡성을 단순화할 수 있는 유연성

그리고 그것에 기반해 만들어진 HDFS는, 일부 multiple writer 지원과 같은 부분을 빼고는, 대부분의 기능을 똑같이 구현하였습니다.

Distributed Storage System Genealogy - 출처 [2]

HDFS의 대안으로는 Microsoft의 TidyFS[39], Neflix의 NMDB[52] 또는 특정 케이스를 위한 Facebook의 Haystack[40] 등이 있으며, 여기서 분산저장소시스템의 비교를 위해서는 아래의 5가지 기준[2]을 사용하려 합니다:

• 파티셔닝: 노드 간의 데이터 분산 관리
• 변형(Mutation): 데이터 변경에 대한 지원
• read paths: 데이터 액세스 방법
• 가용성(Availability)와 일관성(Consistency): 가용성과 일관성 간의 Trade-off 균형
• 사용례

 

파티셔닝

노드 간에 데이터를 분산하기 위해 사용되는 메커니즘인 파티셔닝은 하나의 파티션의 복사본이 여러 노드에 분산되어 저장될 수 있도록 복제(replication)의 개념과 연관됩니다. 분산데이터시스템에는 제한된 3가지 옵션이 존재합니다(centralized, range, hash 파티셔닝). GFS와 HDFS는 centralized에 해당되며, centralized 파티셔닝은 무결성(integrity), 균일하게 파티션된 데이터(rebalancing을 통해)라는 장점이 있는 반면에, centralized 노드가 병목이 될 수 있는 단점을 가지고 있습니다. Range 파티셔닝은 HBase[42], BigTable[43], RethinkDB 그리고 MongoDB(버젼 2.4이전)에 사용되고 있습니다. Hash 파티셔닝은[44]는 range 파티셔닝의 단점(skew와 hot spots)을 피하기 위해 hash 함수를 사용하는 형태입니다. Cassandra, MongoDB, DynamoDB[45]가 Hash 파티셔닝의 예시에 해당됩니다.

 

BigTable의 Tablet Location Hierarchy - 출처 [43]

변형

데이터 시스템은 다양한 범위의 변형을 지원하기 위해 특정 목적에 매우 튜닝되어 있습니다. 변형 방법(append, update 등), 변형 레벨(file 또는 record), 크기, 지연속도(latency) 등을 그러한 튜닝에 고려할 수 있습니다. HDFS는 append 보다는 re-writing을 선호하며 특정 형태의 데이터 접근 방식을 위해 디자인 되었기에 update를 지원하지 않지만[38] 대부분의 (분산) NoSQL 시스템은 update를 지원합니다. 그리고, GFS, HDFS, S3는 파일 / 오브젝트 레벨의 변형을 지원하는 반면 다른 저장소는 record-level의 변형을 지원합니다. HBase와 Cassandra는 10KB 전후, BigTable은 64KB 전후의 데이터 청크(Chunks)를 사용하는 반면 HDFS는 128MB를 사용합니다.

 

Read Paths

'Read Paths'는 시스템이 데이터에 어떻게 접근하는가에 대한 부분을 다룹니다: 인덱스 레벨, 컬럼 또는 행 기준으로 접근하는지 등.

 

HDFS는 Hive(Hive 파티셔닝)를 통해 파일 레벨의 인덱싱을 지원합니다[46]. Key-Value 저장소는 multiple indexing에 대해 다양한 전략을 구사하기는 하나[47] 모두 레코드 레벨의 인덱싱을 지원합니다. 그리고 Solr와 ElasticSearch는 Lucene 기반의 inverted-indexing[48]을 지원합니다. 

 

컬럼 또는 행 기준에 대한 부분과 관련해서는 어떤 저장소는 저장소의 고유한 데이터 모델을 갖는 반면 다른 저장소는 다양한 데이터 포맷(ORC, Parquet, Avro 등)에 그것을 일임합니다.

 

가용성과 일관성

전통적인 CAP 이론은 이 부분에 대한 기본적인 관점을 제공하나 각 개념에는 매우 넓은 범위의 스펙트럼이 존재하기에 ACID, isolcation 개념[49] 등과 잘 매칭되지는 않습니다. 

 

아래의 이미지는 1000 ~ 7000개 노드의 GFS를 1년 동안 운영 시에 발생한 비가용율(unavailability) 통계입니다. 이러한 수치의 비가용율의 원인에는 다양한 이유가 있습니다: 저장 노드나 네트워크 스위치의 과부하, 노드 binary 또는 OS가 crash 또는 재시작, 기기의 하드웨어 에러, 자동 복구 프로세스가 디스크 또는 기기를 일시적으로 제거, 유지를 위해 전체 클러스터를 내리는 경우 등[50].

Cumulative Distribute Function of the Duration of Node Unavailability Periods - 출처 [50]

고가용성( High Availability)를 보장하기 위해서, 주로 시스템에서는 일관성을 낮춥니다(희생합니다)[47 ,51]. 일관성을 낮추는 것은 파티션닝-가능한 조건의 시스템에서 일관성을 가능하게 하는 반면에, 일관성을 최우선으로 하는 것은 특정 조건에서 시스템을 가용하지 않은 상태로 만들게 됩니다[53].

 

사용례

GFS와 많은 변형된 형태(HDFS, S3, TidyFS)는 데이터 시스템의 중심에 위치하여 사용되는 것으로 보이며, 종종 특정 목적을 위해서만 사용되는 경우도 있긴 합니다(Haystack, f4 등). 그리고 kay-value 형태의 저장소(BigTable, HBase, Cassandra, DynamoDB)는 주로 OLTP 형태의 요청을 핸들링하기 위해서 사용되고 있습니다. 다른 한편, aggregating task에 대한 요구는 Redshift, Druid[54]와 같은 형태의 저장소를 탄생시켰습니다. 최근에는 HTAP 개념[55]과 함께 Huawei의 FI-MPPDB, 그리고 Databrick's의 Delta Lake[57](update와 ACID를 지원하는 부분이 있으나 transactional 성격이 약하긴 합니다. 비슷한 Apache Hudi, Apache Iceberg가 있습니다) 등이 만들어져 왔습니다.

 

가공

비록 분산 프로세싱이라는 개념이 20년간 parallel SQL 데이터 운영 시스템에 존재하였고 성능도 SQL DBMS에서 더 우세하나[58], MapReduce는 분산 프로세싱의 개념을 구현해낸 첫 구현체였습니다.

 

MapReduce는  map과 reduce로 언급되는 프로세싱 단계로 이뤄진 DAG(Directed acyclic graph) 관리를 구현하였습니다. 마스터 노드는 아래 이미지와 같이 전체 DAG을 핸들링합니다. MapReduce는 주로 SQL 형태의 인터페이스(Hive[60], Tenzing[61] 등)로 감싸져(wrapped) 사용됩니다.

MapReduce Execution Overview - 출처 [59]

MapReduce는 점점 Hive with Tez, Impala, Apache Spark, Apache Flink, Presto, Dremel, Druid와 같은 모던 프로세싱 엔진으로 대체되어 왔습니다[64]. 특히(위에서 언급된 것처럼) MapReduce의 DAG 생성은 코드로 작성하기가 매우 복잡하여 주로 Hive의 SQL 형태의 쿼리를 통해 감싸져 사용됩니다.

 

위의 다양한 프로세싱 엔진은 아래와 같은 특성을 가지며 각 부분에 대해 좀 더 상세히 살펴보겠습니다:

• Compute Isolation과 동시실행(Concurrency)
• 성능 

 

Compute Isolation과 동시실행(Concurrency)

프로세싱 엔진은 CI(Compute Isolation)에 기반해 데이터 처리를 데이터 저장으로부터 독립시키고 위의 DAG 운영을 통해 처리를 나누어 동시실행을 가능하게 합니다. CI는 크게 node, container, task 3가지 레벨로 나누어 집니다.

• Node: 노드 레벨 isolation은 Amazon Elastic MapReduce와 같은 클라우드 서비스가 발전하면서 많이 사용되었습니다[2] 
• Container: 컨테이너 레벨 isolation은 Hadoop 환경에서는 Yarn, Mesos 또는 Apache Slider와 같은 orchestrators(schedulers)를 필요로 하거나 Docker나 Kubernetes 환경에서도 상응하는 서비스를 필요로 합니다
• Task: 대부분의 프로세싱 엔진에서 지원하는 Task 레벨 isolation은 다양한 워크로드가 실행될 수 있도록 합니다

전통적인 Queue 레벨의 isolation은 위의 구분에서 컨테이너-Task 레벨 isolation 어딘가에 존재하게 됩니다[62].

 

사용

데이터 시스템에 기반한 애플리케이션의 수가 매우 많기에 이 부분에서는 다음과 같이 범위가 넓은 4가지로 구분할 수 있습니다:

• API: API는 기존의 다른 서비스와 유사한 배포 프로세스나 도구를 통해 운영할 수 있습니다
• Dashboard & Visualization: API와는 다르게 대쉬보드와 시각화 도구와 관련해서는 다양한 도구가 특징적인 목적을 위해 존재합니다. Grafana, Kibana와 같이 기존 모니터링에 사용되는 도구와 Supersets, Looker, Google Analytics(일부), D3[66] 등 범용적인 데이터 분석과  BI관련 도구, 특정 목적에 좀 더 특화된 Uber의 deck.gl[67]과 같은 도구가 있습니다. 통계와 같은 수치를 위해 Tableau 등의 대쉬보드 뒷단에는 Redshift, Druid와 같은 저장소를 사용합니다[68].
• Internal Platform: Jupyter Notebook 및 Zeppelin과 같이 데이터 분석가, 데이터 사이언티스트 등 사용자에게 분석환경을 제공하는 서비스 부터 Feature Store와 ML Platform [69, 70]와 같이 데이터 상품의 관리, 개선, 배포를 빠르고 용이하게 사용할 수 있는 서비스를 제공하는 것까지 다양한 내부 플랫폼 도구가 포함됩니다
• Metadata

운영관리

이 단계는 앞의 5단계에 해당되는 부분들을 운영하고 관리하기 위하여 존재하는 단계로 크게 아래의 3가지 컨텍스트로 나누어 살펴보겠습니다:

• 지원서비스: 앞의 5단계를 구성하는 서비스를 지원하기 위해 사용되는 도구
• Workflow Management: 데이터 파이프라인에서 데이터의 흐름 전반을 관리하기 위해 사용되는 도구
• 권한관리도구: 단계별 서비스 또는 데이터에 대한 접근 권한을 관리하고 적절하게 AAA하기 위해 사용되는 도구

지원서비스

Configuration과 Synchronization 관리

Hadoop 환경에서 Zookeeper의 대안을 찾기는 매우 어렵습니다(있긴 있슴, Kafka에 비견되는 Apahce Pulsar는 Zookeeper 대신 Bookeeper를 사용). 많은 분산데이터시스템은 클러스터 metadata와 상태 관리를 위해 Zookeeper와 같은 coordination 서비스에 의존합니다. Zookeeper와 같은 서비스가 configuration과 synchronization을 담당해주기에, 여타 resource orchestrators 서비스는 클러스터 사용성을 높이기 위한 목적으로 개발될 수 있었습니다[71].

Using Zookeeper to keep track of the assignment of partitions to nodes - 출처 [41]

Resource Orchestraction

가공의 isolation을 언급하며 다루었던 것과 같이 리소스 편성을 위해 다양한 도구들이 존재합니다: Google의 Borg, Google의 Omega[72], Facebook의 Bistro[73], Apache Yarn, Apache Mesos[74], Apache Helix 등.

The high-level architecture of Borg. Only a tiny fraction of the tousands of worker nodes are shown - 출처 [71]

대부분은 마스터-슬레이브 구조로 비록 다양한 isolation 레벨을 가지나 admission control, 효율적인 task-packing, over-commitment 및 machine sharing 등의 특성을 구현하였습니다[71, 74].

 

Workflow Management

작업 흐름 관리 도구는 데이터 라우팅, 변형 등의 DAG를 코드 또는 GUI 기반의 웹 UI로 관리할 수 있도록 합니다. Apache Nifi[75], StreamSets[76] 등은 GUI 환경을 통해 데이터 흐름을 관리할 수 있고 비교적 다양한 종류의 IO 및 서비스와 결합할 수 있는 반면, Apache Oozie와 같은 서비스는 Hadoop과 강하게 결합되어[77] 있습니다. 또한, Apache Airflow와 같은 경우 코드를 통해 작업 흐름을 생성하며(Oozie 또한 그러함) 많은 클라우드 환경의 interface도 제공합니다[78].

 

 

Reference

[1] Jan Kunigk, Ian Buss, et al.: “Architecting Modern Data Platforms: A guide to enterprise Hadoop at scale,” O’Reilly Media, Inc., 2019.

[2] Ted Malaska, Jonathan Seidman: “Foundations for Architecting Data Solutions,” O’Reilly Media, Inc., 2018.

[3] https://cloud.google.com/solutions/migration/dw2bq/dw-bq-data-pipelines.

[4] John Ladley: “Data Governance: How to design, deploy, and sustain an effective data governance program,” Elsevier Inc., 2012.

[5] https://en.wikipedia.org/wiki/Vertica.

[6] https://en.wikipedia.org/wiki/SAP_IQ.

[7] https://hbr.org/2017/09/the-surprising-power-of-online-experiments.

[8] Zhu, X: “Do we Need More Training Data?,” 2015.

[9] https://medium.com/@gowthamy/big-data-battle-batch-processing-vs-stream-processing-5d94600d8103.

[10] Michael Stonebraker and Uğur Çetintemel: “‘One Size Fits All’: An Idea Whose Time Has Come and Gone,” at 21st International Conference on Data Engineering (ICDE), April 2005.

[11] Kevin Petrie, Dan Potter, et al.: “Streaming Change Data Capture,” O’Reilly Media, Inc., 2018.

[12] https://en.wikipedia.org/wiki/Server_log.

[13] https://developers.google.com/analytics/devguides/collection/gajs/eventTrackerGuide.

[14] https://en.wikipedia.org/wiki/Data_lake.

[15] https://en.wikipedia.org/wiki/Hybrid_transactional/analytical_processing_(HTAP).

[16] https://insights.stackoverflow.com/survey/2018#technology-_-databases.

[17] https://eng.uber.com/uber-big-data-platform/.

[18] https://docs.oracle.com/cd/E21043_01/integrate.1111/e12644/ogg.htm.

[19] https://www.striim.com/change-data-capture/.

[20] https://en.wikipedia.org/wiki/Log_management.

[21] L. Girardin and D. Brodbeck. ‘‘A Visual Approach for Monitoring Logs.’’ Proc. of the 12th Large Installation Systems Administration (LISA) Conf., 1998.

[22] Adam Sah: “A New Architecture for Managing Enterprise Log Data,” Sixteenth Systems Administration Conference, 2002.

[23] https://www.snowflake.com/security-data-analytics/.

[24] https://www.joe0.com/2017/02/05/applying-big-data-analytics-to-logging/.

[25] Cao, Yinzhi: “(Cross-)Browser Fingerprinting via OS and Hardware Level Features,” 2017–03–07.

[26] Elie Bursztein, Artem Malyshey, et al.: “Picasso: Lightweight Device Class Fingerprinting for Web Clients,” 2016.

[27] https://techcrunch.com/2019/08/22/google-proposes-new-privacy-and-anti-fingerprinting-controls-for-the-web/.

[28] https://github.com/snowplow/snowplow/wiki/snowplow-tracker-protocol.

[29] https://en.wikipedia.org/wiki/Google_Analytics.

[30] https://github.com/awslabs/amazon-kinesis-producer.

[31] Malte Schwarzkopf, “Operating system support for warehouse-scale computing,” University of Cambridge Computer Laboratory, 2015.

[32] https://keen.io/blog/architecture-of-giants-data-stacks-at-facebook-netflix-airbnb-and-pinterest/.

[33] https://www.linkedin.com/pulse/nifi-vs-sqoopflumeoozie-birender-saini/.

[34] Jay Kreps, Neha Narkhede, et al.: “Kafka: a Distributed Messaging System for Log Processing,” LinkedIn Corp.

[35] Tyler Akidau, Alex Balikov, et al.: “MillWheel: Fault-Tolerant Stream Processing at Internet Scale.” Google.

[36] https://rongxinblog.wordpress.com/2016/07/29/kafka-high-watermark/.

[37] https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/.

[38] Sanjay Ghemawat, Howard Gobioff, et al.: “The Google File System,” Google, 2003.

[39] Dennis Fetterly, Maya Haridasan, et al.: “TidyFS: A Simple and Small Distributed File System,”, Microsoft.

[40] Doug Beaver, Sanjeev Kumar, et al.: “Finding a needle in Haystack: Facebook’s photo storage,” Facebook.

[41] Martin Kleppmann: “Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems,” Oreily, 2017.

[42] https://hbase.apache.org/.

[43] Fay Chang, Jeffrey Dean, et al.: “Bigtable: A Distributed Storage System for Structured Data,” Google.

[44] David Karge, Eric Lehma, et al.: “Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web,” In Proceedings of the Twenty-Ninth Annual ACM Symposium on theory of Computing, 1997.

[45] Giuseppe DeCandia, Deniz Hastorun, et al.: “Dynamo: Amazon’s Highly Available Key-value Store,” amazon.com.

[46] Eduarda Costa, Carlos Costa, et al.: “Evaluating partitioning and bucketing strategies for Hive-based Big Data Warehousing systems,” Journal of Big Data, 2019.

[47] “Comparing the Use of Amazon DynamoDB and Apache HBase for NoSQL,” Amazon Web Service, 2018.

[48] https://sease.io/2015/07/exploring-solr-internals-lucene.html.

[49] Peter Bailis, Alan Fekete, et al.: “HAT, not CAP: Towards Highly Available Transactions,” at 14th USENIX Workshop on Hot Topics in Operating Systems (HotOS), 2013.

[50] Daniel Ford, Franc¸ois Labelle, et al.: “Availability in Globally Distributed Storage Systems,” Google.

[51] https://en.wikipedia.org/wiki/Eventual_consistency.

[52] https://medium.com/netflix-techblog/implementing-the-netflix-media-database-53b5a840b42a.

[53] https://queue.acm.org/detail.cfm?id=1466448.

[54] https://medium.com/airbnb-engineering/druid-airbnb-data-platform-601c312f2a4c.

[55] https://en.wikipedia.org/wiki/Hybrid_transactional/analytical_processing.

[56] Jianjun Chen, Yu Chen, et al.: “Data Management at Huawei: Recent Accomplishments and Future Challenges,” IEEE 35th International Conference on Data Engineering, 2019.

[57] https://delta.io/.

[58] Andrew Pavlo, Eric Paulson, et al.: “A Comparison of Approaches to Large-Scale Data Analysis,” ACM SIGMOD International Conference on Management of data, 2009.

[59] Jeffrey Dean, Sanjay Ghemawat: “MapReduce: Simplified Data Processing on Large Clusters,” Google.

[60] Ashish Thusoo, Joydeep Sen Sarma, et al.: “Hive — A Warehousing Solution Over a Map-Reduce Framework,” Facebook.

[61] Biswapesh Chattopadhyay, Liang Lin, et al.: “Tenzing A SQL Implementation On The MapReduce Framework,” Google.

[62] https://docs.aws.amazon.com/redshift/latest/dg/cm-c-defining-query-queues.html.

[63] https://community.dremio.com/t/performances-comparisons/1144/9.

[64] https://en.wikipedia.org/wiki/Comparison_of_OLAP_servers.

[65] https://towardsdatascience.com/designing-data-products-b6b93edf3d23.

[66] https://www.youtube.com/watch?v=nMyuCdqzpZc.

[67] https://deck.gl/.

[68] https://www.tableau.com/solutions/amazon-redshift.

[69] https://cloud.google.com/blog/products/ai-machine-learning/introducing-feast-an-open-source-feature-store-for-machine-learning.

[70] https://databricks.com/product/managed-mlflow.

[71] Abhishek Verma, Luis Pedrosa, et al.: “Large-scale cluster management at Google with Borg,” Google.

[72] Malte Schwarzkopf, Andy Konwinski, et al.: “Omega: flexible, scalable schedulers for large compute clusters,” Google.

[73] Andrey Goder, Alexey Spiridonov, et al.: Bistro: “Scheduling Data-Parallel Jobs Against Live Production Systems,” USENIX Annual Technical Conference, 2015.

[74] Benjamin Hindman, Andy Konwinski, et al.: “Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center,” University of California, Berkeley.

[75] https://nifi.apache.org/.

[76] https://streamsets.com/products/dataops-platform.

[77] https://oozie.apache.org.

[78] https://airflow.apache.org/docs/stable/.

[79] https://d2.naver.com/helloworld/29533