비전통적인 데이터 스토리지에 대한 데이터 엔지니어 가이드

게시 됨: 2022-03-11

데이터 엔지니어링

빅 데이터 및 데이터 과학의 부상으로 많은 엔지니어링 역할이 도전받고 확장되고 있습니다. 새로운 시대의 역할 중 하나는 데이터 엔지니어링 입니다.

원래 데이터 엔지니어링의 목적은 외부 데이터 소스의 로딩과 데이터베이스 설계(데이터 수집, 조작, 저장 및 분석을 위한 파이프라인 설계 및 개발)였습니다.

이후 빅 데이터의 양과 복잡성을 지원하도록 성장했습니다. 따라서 데이터 엔지니어링은 이제 웹 크롤링, 데이터 정리, 분산 컴퓨팅, 데이터 저장 및 검색에서 광범위한 기술을 요약합니다.

데이터 엔지니어링 및 데이터 엔지니어에게 데이터 저장 및 검색은 데이터 사용 및 분석 방법과 함께 파이프라인의 중요한 구성 요소입니다.

최근에는 새롭고 다양한 데이터 저장 기술이 많이 등장했습니다. 그러나 데이터 엔지니어링에 가장 적합하고 가장 적합한 기능은 무엇입니까?

대부분의 엔지니어는 PostgreSQL, MSSQL 및 MySQL과 같은 SQL 데이터베이스에 익숙합니다. SQL 데이터베이스는 행 지향 스토리지가 있는 관계형 데이터 테이블로 구조화되어 있습니다.

이러한 데이터베이스가 얼마나 널리 퍼져 있는지를 감안할 때 오늘은 이에 대해 논의하지 않겠습니다. 대신 인기가 높아지고 있으며 데이터 처리에 대한 다양한 접근 방식을 도입한 세 가지 유형의 대체 데이터 저장소를 살펴봅니다.

데이터 엔지니어링의 맥락에서 이러한 기술은 검색 엔진, 문서 저장소 및 열 형식 저장소입니다.

  • 검색 엔진 은 텍스트 쿼리에 탁월합니다. LIKE 와 같은 SQL 데이터베이스의 텍스트 일치와 비교할 때 검색 엔진은 기본적으로 더 높은 쿼리 기능과 더 나은 성능을 제공합니다.
  • 문서 저장소 는 기존 데이터베이스보다 더 나은 데이터 스키마 적응성을 제공합니다. 데이터를 개별 문서 객체(종종 JSON으로 표시됨)로 저장함으로써 스키마 사전 정의가 필요하지 않습니다.
  • 기반 저장소 는 단일 열 쿼리 및 값 집계를 전문으로 합니다. SUMAVG 와 같은 SQL 작업은 동일한 열의 데이터가 하드 드라이브에 더 가깝게 저장되기 때문에 열 저장에서 훨씬 더 빠릅니다.

이 기사에서는 검색 엔진으로 Elasticsearch, 문서 저장소로 MongoDB, 열 기반 저장소로 Amazon Redshift의 세 가지 기술을 모두 살펴봅니다.

대체 데이터 스토리지를 이해함으로써 각 상황에 가장 적합한 스토리지를 선택할 수 있습니다.

데이터 엔지니어링을 위한 스토리지: 어느 것이 최고입니까?

데이터 엔지니어에게 데이터 스토리지의 가장 중요한 측면은
데이터를 인덱싱, 샤딩 및 집계하는 방법.
트위터

이러한 기술을 비교하기 위해 이 기술이 데이터를 인덱싱, 분할 및 집계하는 방법을 살펴보겠습니다.

각 데이터 인덱싱 전략은 특정 쿼리를 개선하고 다른 쿼리는 방해합니다.

가장 자주 사용되는 쿼리를 아는 것은 채택할 데이터 저장소에 영향을 줄 수 있습니다.

데이터베이스가 데이터를 청크로 분할하는 방법론인 샤딩은 더 많은 데이터가 수집됨에 따라 인프라가 어떻게 성장할 것인지를 결정합니다.

성장 계획과 예산에 맞는 회사를 선택하는 것이 중요하며 이는 규모에 관계없이 모든 데이터 과학 회사에 적용됩니다.

마지막으로, 이러한 기술은 각각 데이터를 매우 다르게 집계합니다.

기가바이트와 테라바이트의 데이터를 다룰 때 잘못된 집계 전략으로 인해 생성할 수 있는 보고서의 유형과 성능이 제한될 수 있습니다.

데이터 엔지니어는 서로 다른 데이터 저장소를 평가할 때 세 가지 측면을 모두 고려해야 합니다.

경쟁자

검색 엔진: Elasticsearch

Elasticsearch는 확장성과 통합 용이성으로 인해 동료들 사이에서 빠르게 인기를 얻었습니다. Apache Lucene을 기반으로 구축되었으며 강력한 즉시 사용 가능한 텍스트 검색 및 인덱싱 기능을 제공합니다. 기존 검색 엔진 작업, 텍스트 검색 및 정확한 값 쿼리 외에도 Elasticsearch는 계층화된 집계 기능도 제공합니다.

문서 저장소: 몽고DB

이 시점에서 MongoDB는 Go-to NoSQL 데이터베이스로 간주될 수 있습니다. 사용 용이성과 유연성으로 인해 빠르게 인기를 얻었습니다. MongoDB는 복잡한 문서를 파헤치기 위한 풍부하고 적응 가능한 쿼리를 지원합니다. 자주 쿼리되는 필드는 인덱싱을 통해 속도를 높일 수 있으며, 많은 양의 데이터를 집계할 때 MongoDB는 다단계 파이프라인을 제공합니다.

컬럼 스토어: Amazon Redshift

NoSQL의 인기가 높아짐에 따라 특히 데이터 분석을 위해 컬럼형 데이터베이스가 주목받고 있습니다. 일반적인 행이 아닌 열에 데이터를 저장하여 디스크에서 직접 집계 작업을 실행할 수 있어 성능이 크게 향상됩니다. 몇 년 전 Amazon은 Redshift라는 기둥형 스토어를 위한 호스팅 서비스를 출시했습니다.

인덱싱

Elasticsearch의 인덱싱 기능

여러 면에서 검색 엔진은 텍스트 인덱싱을 전문으로 하는 데이터 저장소입니다.

다른 데이터 저장소는 필드의 정확한 값을 기반으로 인덱스를 생성하지만 검색 엔진은 (보통 텍스트) 필드의 일부만 사용하여 검색을 허용합니다.

기본적으로 이 검색은 분석기를 통해 모든 필드에 대해 자동으로 수행됩니다.

분석기 는 필드 값을 평가하고 더 작은 값으로 분해하여 여러 인덱스 키를 생성하는 모듈입니다.

예를 들어 기본 분석기는 "게으른 개를 뛰어넘은 빠른 갈색 여우"를 "빨리", "갈색", "여우" 등과 같은 단어로 조사할 수 있습니다.

이 방법을 사용하면 동일한 문서 데이터와 일치하는 단편 수에 따라 순위가 지정된 결과 내 단편을 검색하여 데이터를 찾을 수 있습니다.

보다 정교한 분석기는 편집 거리, n-그램 및 불용어별 필터링을 활용하여 포괄적인 검색 색인을 구축할 수 있습니다.

MongoDB의 인덱싱 기능

일반 데이터 저장소인 MongoDB는 데이터 인덱싱에 많은 유연성을 가지고 있습니다.

Elasticsearch와 달리 기본적으로 _id 필드만 인덱싱하며 일반적으로 쿼리되는 필드에 대한 인덱스를 수동으로 생성해야 합니다.

Elasticsearch와 비교하여 MongoDB의 텍스트 분석기는 그다지 강력하지 않습니다. 그러나 최적의 쿼리를 위한 복합 및 지리 공간에서부터 스토리지 축소를 위한 TTL 및 희소에 이르기까지 인덱싱 방법에 많은 유연성을 제공합니다.

Redshift의 인덱싱 기능

Elasticsearch, MongoDB 또는 PostgreSQL을 포함한 기존 데이터베이스와 달리 Amazon Redshift는 인덱싱 방법을 지원하지 않습니다.

대신 디스크에서 일관된 정렬을 유지하여 쿼리 시간을 줄입니다.

사용자는 정렬된 열 값 집합을 테이블 정렬 키로 구성할 수 있습니다. 데이터가 디스크에 정렬된 상태에서 Redshift는 값이 쿼리된 범위를 벗어나면 검색 중에 전체 블록을 건너뛸 수 있어 성능이 크게 향상됩니다.

샤딩

Elasticsearch의 샤딩 기능

Elasticsearch는 Lucene을 기반으로 구축되어 수평적으로 확장되고 프로덕션 준비가 되었습니다.

확장은 여러 Lucene 인스턴스(샤드)를 만들고 클러스터 내의 여러 노드(서버)에 배포하여 수행됩니다.

기본적으로 각 문서는 _id 필드를 통해 해당 샤드로 라우팅됩니다.

검색하는 동안 마스터 노드는 각 샤드에 쿼리 사본을 전송한 후 최종적으로 집계하여 출력 순위를 매깁니다.

MongoDB의 샤딩 기능

MongoDB 클러스터에는 라우터, 구성 및 샤드의 세 가지 유형의 서버가 있습니다.

라우터를 확장하면 서버가 더 많은 요청을 수락할 수 있지만 샤드 서버에서 무거운 작업이 발생합니다.

Elasticsearch와 마찬가지로 MongoDB 문서는 기본적으로 _id 를 통해 해당 샤드로 라우팅됩니다. 쿼리 시점에 config 서버는 쿼리를 sharding하는 라우터에 알리고 라우터 서버는 쿼리를 배포하고 결과를 집계합니다.

Redshift의 샤딩 기능

Amazon Redshift 클러스터는 하나의 리더 노드와 여러 컴퓨팅 노드로 구성됩니다.

리더 노드는 쿼리의 컴파일 및 배포는 물론 중간 결과의 집계도 처리합니다.

MongoDB의 라우터 서버와 달리 리더 노드는 일관성이 있으며 수평으로 확장할 수 없습니다.

이로 인해 병목 현상이 발생하지만 인기 있는 쿼리에 대해 컴파일된 실행 계획을 효율적으로 캐싱할 수도 있습니다.

집계

Elasticsearch의 집계 기능

Elasticsearch 내의 문서는 정확한, 범위 또는 시간 및 지리적 위치 값으로 버킷화할 수 있습니다.

이러한 버킷은 중첩 집계를 통해 더 세부적으로 그룹화할 수 있습니다.

평균 및 표준 편차를 포함한 메트릭은 각 계층에 대해 계산할 수 있으며 단일 쿼리 내에서 분석 계층을 계산하는 기능을 제공합니다.

문서 기반 저장소이기 때문에 문서 내 필드 비교의 한계가 있습니다.

예를 들어 필드 팔로워 가 10보다 크면 필터링은 잘 하지만 팔로워 가 다른 필드 팔로워 보다 큰지 확인할 수 없습니다.

대안으로 스크립트를 사용자 정의 술어로 주입할 수 있습니다. 이 기능은 일회성 분석에 유용하지만 프로덕션에서는 성능이 저하됩니다.

MongoDB의 집계 기능

집계 파이프라인은 강력하고 빠릅니다.

이름에서 알 수 있듯이 반환된 데이터에 대해 단계별 방식으로 작동합니다.

각 단계는 문서를 필터링, 집계 및 변환하고, 새 메트릭을 도입하거나, 이전에 집계된 그룹을 해제할 수 있습니다.

이러한 작업은 단계별로 수행되고 문서와 필드를 필터링만 하도록 줄임으로써 메모리 비용을 최소화할 수 있습니다. Elasticsearch 및 Redshift와 비교할 때 Aggregation Pipeline은 데이터를 보는 매우 유연한 방법입니다.

적응성에도 불구하고 MongoDB는 Elasticsearch와 마찬가지로 문서 내 필드 비교가 부족합니다.

또한 $group 을 포함한 일부 작업에서는 결과를 마스터 노드로 전달해야 합니다.

따라서 분산 컴퓨팅을 활용하지 않습니다.

단계별 파이프라인 계산에 익숙하지 않은 사용자는 특정 작업이 직관적이지 않다는 것을 알게 될 것입니다. 예를 들어, 배열 필드의 요소 수를 합산하려면 먼저 $unwind$group 작업의 두 단계가 필요합니다.

관련 항목: 비즈니스 인텔리전스 플랫폼: MongoDB 집계 파이프라인을 사용하는 자습서

Redshift의 집계 기능

Amazon Redshift의 이점은 아무리 강조해도 지나치지 않습니다.

Amazon Redshift는 모바일 트래픽을 분석하는 동안 MongoDB에서 엄청나게 느린 집계를 신속하게 해결합니다.

SQL을 지원하는 기존 데이터베이스 엔지니어는 쿼리를 Redshift로 쉽게 마이그레이션할 수 있습니다.

온보딩 시간을 제외하고 SQL은 입증되고 확장 가능하며 강력한 쿼리 언어로 문서 내/행 필드 비교를 쉽게 지원합니다. Amazon Redshift는 컴퓨팅 노드에서 실행되는 인기 쿼리를 컴파일하고 캐싱하여 성능을 더욱 향상시킵니다.

관계형 데이터베이스인 Amazon Redshift에는 MongoDB 및 Elasticsearch와 같은 스키마 유연성이 없습니다. 읽기 작업에 최적화되어 업데이트 및 삭제 중에 성능 저하가 발생합니다.

최상의 읽기 시간을 유지하려면 행을 정렬해야 하므로 추가 작업이 필요합니다.

페타바이트 크기의 문제가 있는 사용자에 맞게 조정되었으며 다른 데이터베이스에 확장 문제가 없는 한 저렴하지 않고 투자 가치도 없습니다.

승자 고르기

이 기사에서는 데이터 엔지니어링의 맥락에서 Elasticsearch, MongoDB 및 Amazon Redshift의 세 가지 기술을 살펴보았습니다. 그러나 이러한 각 기술이 스토리지 유형 범주에서 선두주자이기 때문에 확실한 승자는 없습니다.

데이터 엔지니어링의 경우 사용 사례에 따라 일부 옵션이 다른 옵션보다 낫습니다.

  • MongoDB 는 환상적인 스타터 데이터베이스입니다. 데이터 스키마가 아직 결정되지 않은 경우 원하는 유연성을 제공합니다. 즉, MongoDB는 다른 데이터베이스가 전문으로 하는 특정 사용 사례를 능가하지 않습니다.
  • Elasticsearch 는 MongoDB와 유사한 유동적인 스키마를 제공하지만 쓰기 성능과 스토리지 크기를 희생하면서 여러 인덱스 및 텍스트 쿼리에 최적화되어 있습니다. 따라서 MongoDB에서 수많은 인덱스를 유지 관리해야 하는 경우 Elasticsearch로 마이그레이션하는 것을 고려해야 합니다.
  • Redshift 에는 사전 정의된 데이터 스키마가 필요하며 MongoDB가 제공하는 적응성이 부족합니다. 그 대가로 단일(또는 몇 개) 열만 포함하는 쿼리에 대해 다른 데이터베이스를 능가합니다. 예산이 허락한다면 Amazon Redshift는 다른 사람들이 데이터 양을 처리할 수 없을 때 훌륭한 비밀 무기입니다.