Ingestion

https://startree.ai/resources/a-tale-of-three-real-time-olap-databases

 

Ingestion

Before a database can run analytical queries, the data must get into the system. This is the process of ingestion . This layer deals with all the capabilities required for ingesting data into the OLAP system from various kinds of data sources, as mentioned above. As we go through the details of each data source, here are the key things to keep in mind:

• Append only vs upserts : Append only ingestion is the minimum requirement from an OLAP database. But supporting upserts provides data and query consistency.
• Pull vs push : Can the OLAP database support a pull / push based ingestion or both. Each one has its pros and cons.
• At least once vs exactly once : At-least-once semantics is the minimum requirement to ensure there’s no data loss. Having the ability to do exactly once data ingestion is great for certain business critical applications.

Real-Time Ingestion

Ingesting data from real-time data sources like Apache Kafka is integral to real-time analytics. In this section, we will look at the different ways of ingesting real-time data and compare the nuances of each system.

Pull vs Push Based Real-Time Ingestion

There are two ways of ingesting real-time data:

• Pull based: Actively poll/fetch data from the real-time data source
• Push based: Push messages directly into the database

A native pull-based ingestion model is generally considered to be better than a push-based model for real-time data ingestion. Here are the reasons why:

• Fewer moving parts : A native pull-based approach works great with systems like Apache Kafka and Amazon Kinesis and obviates the need for an intermediate connector (e.g., the Kafka Connect framework). This improves overall freshness and error probability by reducing the number of hops in the pipeline.
• More scalable : Based on empirical data, the pull-based approach supports higher throughput than a corresponding push-based approach.
• Ease of replication : The pull-based model makes it very easy to replicate data since all replicas can fetch independently from the data source. In addition, strict partition ordering within the data source also alleviates the need for strong coordination among replicas to keep them in sync. For instance, replicas can all agree on the same Kafka offset to ensure data synchronization. A push-based model has to deal with the overhead of how to keep the replicas in sync.
• Ease of exactly once semantics : A pull-based model makes it easier to guarantee exactly once semantics with systems like Kafka. Arguably, a push based model has to do more work to ensure correctness in this case.

Need for Push Based Ingestion

There are certain cases where push based ingestion is preferred. For instance, in some cases, the real-time data might be generated directly by an application/service without any Kafka in the picture. In other cases, even though data might exist in a Kafka cluster, pull based ingestion may not be possible due to network connectivity issues (eg: Kafka in another VPC without any inbound access). For all such cases, we need the ability to push events directly to the database.

 

 

데이터 인제스천(Ingestion) 개요

원문:
"Before a database can run analytical queries, the data must get into the system. This is the process of ingestion. This layer deals with all the capabilities required for ingesting data into the OLAP system from various kinds of data sources, as mentioned above. As we go through the details of each data source, here are the key things to keep in mind:"

해석 및 설명:

• 데이터 인제스천이란?
  데이터베이스가 분석 쿼리를 실행하기 전에, 외부의 다양한 데이터 소스에서 데이터를 시스템 내부로 가져오는 과정이 필요합니다. 이 과정을 "인제스천(ingestion)"이라고 합니다.
• OLAP 시스템 내 인제스천 계층:
  이 계층은 여러 종류의 데이터 소스(예: 스트리밍, 배치 데이터 등)에서 OLAP(온라인 분석 처리) 시스템으로 데이터를 받아들이는 데 필요한 모든 기능을 다룹니다.
• 중요 고려사항:
  각 데이터 소스별로 데이터를 어떻게 받아들이는지에 대해 살펴볼 때, 아래의 핵심 사항들을 염두에 두어야 합니다.

---

인제스천 방식의 핵심 고려사항

1. Append Only vs Upserts
   • Append Only (추가 전용):
     데이터를 단순히 추가만 하는 방식입니다. 대부분의 OLAP 데이터베이스에서는 최소한의 요구 사항으로 append-only 인제스천을 지원합니다.
   • Upserts (업서트):
     새로운 데이터를 추가하는 동시에, 기존 데이터에 대해 업데이트(수정)를 수행하는 기능입니다. Upsert를 지원하면 데이터 일관성과 쿼리 결과의 정확성을 높일 수 있습니다.
2. Pull vs Push 방식
   • Pull 방식:
     OLAP 데이터베이스가 외부 데이터 소스로부터 주기적으로(또는 필요할 때마다) 데이터를 "끌어오는" 방식입니다.
   • Push 방식:
     외부 데이터 소스가 데이터를 직접 데이터베이스에 "밀어넣는" 방식입니다.
   • 각 방식의 장단점:
     두 방식 모두 장단점이 있으며, 시스템의 요구사항과 환경에 따라 적절한 방식을 선택해야 합니다.
3. At least once vs Exactly once
   • At Least Once (최소 한 번):
     데이터 손실이 없도록 보장하는 최소한의 데이터 전달 보증 방식입니다. 즉, 각 데이터 항목이 최소 한 번은 처리되도록 하는 것입니다.
   • Exactly Once (정확히 한 번):
     각 데이터 항목이 중복 없이 정확히 한 번 처리되도록 하는 보증 방식입니다. 이는 매우 중요한 비즈니스 애플리케이션에서 필요하지만, 구현하기 어렵습니다.

---

실시간 데이터 인제스천 (Real-Time Ingestion)

원문:
"Ingesting data from real-time data sources like Apache Kafka is integral to real-time analytics. In this section, we will look at the different ways of ingesting real-time data and compare the nuances of each system."

해석 및 설명:

• 실시간 데이터 소스:
  예를 들어, Apache Kafka와 같은 실시간 데이터 스트리밍 시스템으로부터 데이터를 인제스천하는 것은 실시간 분석에 매우 중요합니다.
• 다양한 인제스천 방법 비교:
  실시간 데이터를 어떻게 시스템에 가져올 것인지에 대한 다양한 방법(예: pull 방식과 push 방식)을 살펴보고, 각각의 특징과 장단점을 비교합니다.

---

Pull 기반 vs Push 기반 실시간 인제스천

1. Pull 기반 인제스천

• 정의:
  OLAP 데이터베이스가 외부 실시간 데이터 소스(예: Kafka, Amazon Kinesis 등)에서 데이터를 주기적으로 폴링(요청)하여 가져오는 방식입니다.
• 장점:
  • 구성 요소가 적음 (Fewer Moving Parts):
    Kafka Connect와 같은 중간 커넥터 없이도 네이티브 방식으로 데이터를 끌어올 수 있으므로, 파이프라인에 포함되는 단계(홉)가 줄어듭니다. 이로 인해 데이터의 신선도(freshness)가 개선되고, 오류 발생 가능성이 낮아집니다.
  • 높은 처리량 (More Scalable):
    실제 경험적으로, pull 방식은 push 방식보다 더 높은 처리량(throughput)을 제공하는 경우가 많습니다.
  • 복제(replication) 용이:
    각 복제본이 독립적으로 데이터를 가져올 수 있어, 모든 복제본이 동일한 Kafka 오프셋(offset)을 기준으로 동기화할 수 있습니다. 반면, push 방식은 복제본 간의 동기화에 추가적인 오버헤드가 발생할 수 있습니다.
  • Exactly Once 보장 용이:
    Kafka와 같은 시스템과 함께 사용할 때, pull 방식은 중복 없이 정확히 한 번 처리(exactly once semantics)를 보장하기에 용이합니다.

2. Push 기반 인제스천

• 정의:
  데이터 소스가 데이터를 직접 데이터베이스로 밀어넣는 방식입니다.
• 필요한 경우:
  • 일부 애플리케이션이나 서비스에서 실시간 데이터가 Kafka 없이 직접 생성되는 경우.
  • 네트워크 연결 문제 등으로 인해 Kafka 클러스터에 접근이 어려운 경우 (예: 서로 다른 VPC 환경에서 Kafka에 인바운드 접근이 불가능한 경우).
• 장점:
  • 해당 상황에서는 외부 커넥터 없이 데이터를 직접 데이터베이스에 전달할 수 있는 유연성이 있습니다.