Introduction
세계는 디지털 변환으로 가득 차 있으며, 연결된 모든 장치(Device)의 중심에서 기업용 애플리케이션(Enterprise applications)으로 가는 모든 방법이 메시지입니다.
Rise of the Message Queue
디지털 메시지의 모든 입력 및 출력에 보조를 맞추기 위해 메시지 큐가 발전했습니다. 지난 몇 년 동안 Apache Kafka가 메시지 큐 환경을 지배하게되었습니다.
RabbitMQ, ZeroMQ, 물론 AWS Kinesis와 같은 유용한 메시지 큐가 있습니다. 이 가이드의 일부는 다른 메시지 큐에도 적용되지만 이 문서에서는 Kafka에 초점을 맞추고 있습니다.
카프카 기본에는 한 명 또는 여러 명의 생산자가 제공 한 데이터를 섭취하고 하나 또는 여러 명의 소비자가 해당 데이터를 소비하는 것이 포함됩니다. 카프카는 이러한 엔드 포인트 간의 메시지 흐름을 관리하는 중앙 리소스 역할을합니다.
또한 아파치 카프카 (Apache Kafka)는 분산 시스템으로, 더 큰 부하를 수용하기 위해 수평으로 확장 할 수 있습니다. 데이터 증가와 실시간 결과에 대한 요구가 합쳐져 카프카의 분산 아키텍처가 빛을 발합니다.
The Real-Time Infrastructure Data Pipeline
메시지 큐 너머에는 실시간 데이터 파이프 라인을 애플리케이션 및 분석에 이르기까지 확장하는 데 필요한 더 광범위한 인프라가 있습니다.
Edge Capture 이것은 모바일 장치, 공장 자동화 장비 또는 전세계 센서에있을 수 있습니다. 사용자 또는 기계의 모든 데이터 수집 유형이 여기에 표시됩니다.
Message Queue Apache Kafka와 같은 메시지 큐는 메시지를 수집하고 배포합니다.
변환 계층 (Transformation Tier) 변환 계층은 지속성이 필요한 데이터 스트림의 경우 올바른 형식으로 데이터를 저장합니다. 이 계층은 기계 학습 모델을 기반으로 데이터 정리, 확장(enrichment) 또는 채점(scoring)을 통합 할 수도 있습니다.
Datastore 데이터베이스와 같은 장기 데이터 스토어는 실시간 및 기록 데이터를 동시에 분석 할 수 있게 합니다.
애플리케이션 및 분석 새로운 데이터는 애플리케이션 및 분석에 통합 될 때 가치를 창출합니다.
실시간 데이터 이동에 대한 과제
데이터 이동은 오랫동안 모든 사람들이 싫어하는 과정이었습니다. 당신은 그것을 해야하지만, 대량으로 또는 고속으로 데이터를 움직이는 것에 대해서는 아무 것도 재미있지 않습니다.
요점은 확장 가능한 시스템에서 비롯된 급변하는 대량의 데이터를 처리하고 쿼리 가능한 데이터베이스로 가져올 필요가 있다는 것입니다.
확장형 시스템은 Kafka 또는 Kinesis와 같은 메시지 큐일 수도 있고 AWS S3 또는 Hadoop Distributed File System (HDFS)과 같은 대형 객체 또는 파일 저장소 일 수도 있습니다.
문제는 스트림을 쉽게 쿼리 할 수 없고 일부 쿼리를 사용할 수있는 경우 일반적으로 작은 데이터 창(window)으로 이전된다는 것입니다.
시기 적절하고 정확한 분석을 위해서는 실시간 데이터 및 전체 기록 데이터에 액세스해야하며, 변경 데이터를 실시간으로 데이터베이스에 로드해야합니다.
데이터 소스와 데이터베이스간에 이러한 실시간 데이터 전송은 일반적으로 서로 다른 샤딩 스키마가 있으므로 까다로울 수 있습니다. 예를 들어, S3의 파일은 시간에 따라 분할 될 수 있지만 데이터베이스는 사용자 ID별로 분할될 수 있습니다. 시간 기반 샤드와 사용자 ID 샤드가 일치하지 않기 때문에 데이터가 곧바로 로드되면 쿼리가 효율적이지 않습니다.
실시간 데이터 이동에 대한 초기 접근법
하나의 분산 시스템 (메시지 대기열)에서 다른 분산 시스템 (데이터베이스)으로 이동할 필요성은 처음에는 데이터를 변환하는 또 다른 분산 시스템이 필요했습니다.
이 "미들웨어"분산 시스템은 원본에서 가져 와서 데이터베이스에 대해 LOAD DATA 쿼리를 실행하는 중간 단계로 작동합니다. 단순한 개념이지만 실제 배포에서는 어려운 접근 방식입니다.
그러나 다양한 변형을 전달하는 복잡성 외에도 어떤 파일이로드되었는지 또는 어떤 오프셋을로드해야 하는지를 추적하는 것은 더욱 어려워집니다.
전반적으로이 접근법은 가장 엄격한 스케일링 목표를 충족시키지 못합니다.
왼쪽에있는 사각형을 미들웨어 솔루션의 노드로 간주하고 오른쪽에있는 원을 데이터베이스 파티션으로 간주하고 샤딩 스키마가 다르다는 것을 인식하십시오.
미들웨어 솔루션은 일련의 메시지 또는 트랜잭션과 이들을 분리 된 상태로 유지해야한다는 요구 사항을 제시합니다. 모든 직업은 필연적으로 경쟁합니다. 예를 들어 하나의 작업이 $ 5를 지불하기 위해 트랜잭션을 전달하고 다른 작업이 $ 10을 지불하기 위해 다른 트랜잭션을 전달하는 경우 첫 번째 작업은 행의 잠금을 취하고 두 번째 작업은 대기해야합니다.
짧게 말하면, 필요한 조정은 규모에 맞춰 유지할 수 없습니다.
데이터베이스 및 기본 파이프 라인 지원
좋은 소식은 올바르게 구조화된 분산 데이터베이스를 사용하면 변환을 포함하여 실시간 데이터 이동에 미들웨어 시스템이 필요하지 않습니다. 특히 고유 파이프 라인이 있는 데이터베이스는 확장성이 뛰어난 트랜잭션 마이크로 배치로 이동 데이터를 지원합니다.
데이터베이스는 모든 데이터 이동이 사실상 하나의 작업임을 알고 있으며 정확히 한 번 시맨틱(exactly-once semantics)을 유지하는 기능을 포함하여 리소스를 현명하게 공유하여 작업을 효율적으로 관리합니다. 정확히 한 번 시맨틱은 실시간 파이프 라인의 정확성을 보장합니다. 예를 들어, S3에서 데이터를 가져올 때 파일이 누락되면 고통스럽지만 파일을 두 번 로드하면 더 큰 불편과 문제 해결이 발생할 수 있습니다.
CREATE PIPELINE 소개
실시간 데이터 파이프 라인을 쉽게 만들 수 있도록 SingleStore는 SQL 구문에 CREATE PIPELINE 명령을 추가했습니다. 이는 쿼리 가능 데이터 저장소에서 전체 데이터 지속성을 통해 스트림을 캡처하는 것으로부터 데이터 파이프 라인을 생성하고 관리하기위한 기본 지원을 제공합니다.
SQL 구문은 다음과 같습니다.
|
CREATE PIPELINE my_pipeline AS LOAD DATA KAFKA 'host:port/topic' INTO TABLE my_table |
일반적인 데이터 이동 시나리오에서는 조정 데이터베이스 노드가 작업을 시작합니다. 로드 된 파일, 카프카 파티션을 가져오는 파일 및 오프 세트 상태를 알 수 있습니다. 이 노드는 각 데이터베이스 파티션이 데이터 소스에서 병렬로 끌어 당겨서 효율적인로드 조작을 지시합니다. 데이터는 한 번 데이터베이스 트랜잭션을 나타내는 각 마이크로 배치로 마이크로 배치로 이동합니다. 데이터가 데이터베이스로 스트리밍되면 조정된 재구성 (reshuffle) 작업으로 데이터가 올바르게 저장됩니다.
초기 데이터 이동 접근법의 초기 다이어그램과 비교할 때 기본 파이프 라인은 조정 된 작업으로 작동합니다.
기본 파이프 라인 세부 정보
각 데이터베이스 파티션에는 추출기가 있으며 특정 Kafka 파티션에서 추출하도록 지정됩니다. 이러한 형식은 Avro, CSV, JSON 이상일 수 있으며 일반적으로 데이터베이스에 저장하기 전에 일부 유형의 변환이 필요합니다.
오프셋을 데이터베이스에 로컬로 저장하면 이전 지점에서 Kafka를 재생하고, 파이프 라인을 변경하고, 오프셋을 설정하는 것이 쉽습니다.
일부 유형의 변환이 필요하면 추출기와 데이터베이스간에 스크립트를 실행할 수있는 기능이 있습니다. 변형은 모든 스크립트가 될 수 있으며 단순히 표준에서 읽은 다음 표준 출력으로 인쇄합니다. 그런 다음 데이터가 재구성되어 데이터베이스에 삽입됩니다.
특히 이 재구성 작업은 SingleStore에서 유사한 프로세스를 실행하면 매우 효율적입니다. 예를 들어, SingleStore가 분산 조인을 수행하는 것과 동일한 논리를 사용하여 이 재편성을 관리 할 수 있습니다.
네이티브 파이프 라인을 사용하여 정확히 한 번 시맨틱
파이프 라인을 무너뜨리는(collapsing) 주된 이점은 정확히 한 번 시맨틱(semantics)을 지원할 수 있다는 것입니다.
오늘날 대부분의 데이터 저장소는 메시지 큐를 추적하고 메시지가 수신되면 큐에 'ack' 메시지를 다시 보냄으로써 이를 수행하려고 합니다.
이것은 트랜잭션이 멱등수 (Idempotent) 여야한다는 데이터베이스 스키마 설계자에게 제한을 두거나, 특히 두 번 무언가를 하는 것은 동일한 결과를 한 번 수행하는 것입니다.
5 달러를 한 번 지불 한 다음 다른 10 달러를 지불하는 예제를 먼저 생각해 보면 데이터 저장소는 반드시 메시지 내에 고유 ID가 없어도 카운터를 증가시키고 있습니다.
네이티브 파이프 라인은 스키마 디자이너가 이러한 파이프 라인이 최신 오프셋을 저장하기 위해 데이터베이스 트랜잭션을 사용하므로 멱등수를 고려할 필요가 없으며 이 시스템도 데이터를 저장하는 동일한 시스템입니다. 최신 오프셋을 알면 데이터베이스가 올바른지 확인하고 질문이 있으면 쿼리 할 수 있습니다.
이 접근법은 엔터프라이즈 애플리케이션을 위한 실시간 데이터 이동의 중요한 요소인 보다 직관적이고 간소화된 정확한 한 번 시맨틱(exactly-once semantics)를 제공합니다.
Get The Message
2016 년 12 월에 발표 된 가트너 보고서에 따르면, 2016 년에서 2019 년 사이에 실시간 분석에 대한 지출은 비 실시간 분석에 대한 지출보다 3 배나 빠르게 증가 할 것입니다.
분석을 제공하는 실시간 파이프 라인의 핵심 요소는 메시지 큐와 실시간 쿼리를 지원할 수있는 영구 데이터베이스에 데이터를 빠르고 안정적으로 이동시키는 기능입니다.
To take a test drive today, download SingleStore at singlesotre.com/download
- SingleStore 공식문서 - Kafka pipeline
Kafka Pipelines Quickstart
To create and interact with a Kafka pipeline quickly, follow the instructions in this section. There are three parts to this Quickstart: Part 1: Running a Kafka Cluster in Docker Part 2: Sending Messages to Kafka Part 3: Creating a Kafka Pipeline in Single
docs.singlestore.com
- Apache Kafka 공식문서 - 카프카의 핵심 개념과 원리
http://kafka.apache.org/documentation.html
Apache Kafka
Apache Kafka: A Distributed Streaming Platform.
kafka.apache.org
※ www.a-platform.biz | info@a-platform.biz
'SingleStoreDB > 엔지니어링' 카테고리의 다른 글
| SingleStore, Apache Spark 연동 개요 (0) | 2019.07.25 |
|---|---|
| SingleStore, Apache Kafka 연동 실습 - Quickstart (0) | 2019.07.24 |
| SingleStore, Operator for Kubernetes 출시 (0) | 2019.07.24 |
| SingleStore 설치 방법 - On premises Multi Host (0) | 2019.07.24 |
| SingleStore 설치 방법 - On premises Single Host (0) | 2019.07.24 |
