빅 데이터 아키텍처는 기존 데이터베이스 시스템에 비해 너무 크거나 복잡한 데이터의 수집, 처리 및 분석을 관리합니다. 빅 데이터 영역을 입력하는 임계값은 도구 및 사용자 기능에 따라 조직마다 다릅니다. 일부 조직에서는 수백 기가바이트의 데이터를 관리하고, 다른 조직에서는 수백 테라바이트 단위를 관리합니다. 빅 데이터 세트 작업을 위한 도구가 발전함에 따라 빅 데이터 정의는 데이터 크기에만 집중하는 것에서 고급 분석에서 파생된 가치를 강조하는 것으로 바뀝니다. 이러한 유형의 시나리오에는 많은 양의 데이터가 있는 경향이 있습니다.
수 년에 걸쳐 데이터 환경이 변경되어 왔습니다. 데이터로 수행할 수 있는 작업이나 수행하려는 작업이 변경되었습니다. 스토리지 비용은 크게 감소했으며 데이터 수집 방법은 계속 확장됩니다. 일부 데이터는 빠른 속도로 도착하며 연속 수집 및 관찰이 필요합니다. 다른 데이터는 더 느리게 도착하지만 큰 청크로, 종종 수십 년의 기록 데이터 형태로 도착합니다. 고급 분석 문제 또는 기계 학습을 해결해야 하는 문제가 발생할 수 있습니다. 빅 데이터 아키텍처는 이러한 문제를 해결하기 위해 노력합니다.
빅 데이터 솔루션에는 일반적으로 다음 유형의 워크로드 중 하나 이상이 포함됩니다.
- 보관 중인 빅 데이터 원본 일괄 처리
- 동작 중인 빅 데이터의 실시간 처리
- 빅 데이터의 대화형 탐색
- 예측 분석 및 기계 학습
다음 작업을 수행해야 하는 경우 빅 데이터 아키텍처를 고려합니다.
- 기존 데이터베이스에 비해 너무 큰 볼륨에 데이터 저장 및 처리
- 분석 및 보고를 위해 구조화되지 않은 데이터 변환
- 실시간으로 또는 짧은 대기 시간으로 바인딩되지 않은 데이터 스트림 캡처, 처리 및 분석
빅 데이터 아키텍처의 구성 요소
다음 다이어그램에서는 빅 데이터 아키텍처의 논리적 구성 요소를 보여 줍니다. 개별 솔루션에는 이 다이어그램의 모든 항목이 포함되지 않을 수 있습니다.
대부분의 빅 데이터 아키텍처에는 다음 구성 요소 중 일부 또는 전부가 포함됩니다.
데이터 원본: 모든 빅 데이터 솔루션은 하나 이상의 데이터 원본으로 시작합니다. 예를 들면 다음과 같습니다.
- 관계형 데이터베이스와 같은 애플리케이션 데이터 저장소
- 웹 서버 로그 파일과 같이 애플리케이션에서 생성하는 정적 파일입니다.
- IoT(사물 인터넷) 디바이스와 같은 실시간 데이터 원본
데이터 스토리지: 일괄 처리 작업을 위한 데이터는 일반적으로 다양한 형식의 대용량 파일을 저장할 수 있는 분산 파일 저장소에 저장됩니다. 이러한 종류의 저장소는 종종 데이터 레이크라고 불립니다. 이 스토리지를 구현하기 위한 옵션으로는 Azure Data Lake Store, Azure Storage의 Blob 컨테이너 또는 Microsoft Fabric의 OneLake가 있습니다.
일괄 처리: 데이터 세트는 크기가 크므로 빅 데이터 솔루션은 장기 실행 일괄 처리 작업을 사용하여 데이터를 필터링, 집계 및 준비하여 분석할 데이터를 처리하는 경우가 많습니다. 일반적으로 이러한 작업에는 원본 파일을 읽고, 처리하고, 출력을 새 파일에 쓰는 작업이 포함됩니다. 사용할 수 있는 옵션은 다음과 같습니다.
Azure Data Lake Analytics에서 U-SQL 작업을 실행합니다.
Azure HDInsight Hadoop 클러스터에서 Hive, Pig 또는 사용자 지정 MapReduce 작업을 사용합니다.
HDInsight Spark 클러스터에서 Java, Scala 또는 Python 프로그램을 사용합니다.
Azure Databricks Notebook에서 Python, Scala 또는 SQL 언어를 사용합니다.
Fabric Notebook에서 Python, Scala 또는 SQL 언어를 사용합니다.
실시간 메시지 수집: 솔루션에 실시간 원본이 포함된 경우 아키텍처는 스트림 처리를 위해 실시간 메시지를 캡처하고 저장해야 합니다. 예를 들어 처리를 위해 들어오는 메시지를 수집하는 간단한 데이터 저장소가 있을 수 있습니다. 그러나 많은 솔루션은 메시지의 버퍼 역할을 하고 스케일 아웃 처리, 신뢰할 수 있는 배달 및 기타 메시지 큐 의미 체계를 지원하기 위해 메시지 수집 저장소가 필요합니다. 스트리밍 아키텍처의 이 부분을 스트림 버퍼링이라고도 합니다. 옵션에는 Azure Event Hubs, Azure IoT Hub 및 Kafka가 포함됩니다.
스트림 처리: 솔루션은 실시간 메시지를 캡처한 후 필터링, 집계 및 분석을 위해 데이터를 준비하여 처리해야 합니다. 그러면 처리된 스트림 데이터가 출력 싱크에 기록됩니다.
Azure Stream Analytics는 바인딩되지 않은 스트림에서 작동하는 지속적으로 실행되는 SQL 쿼리를 사용하는 관리되는 스트림 처리 서비스입니다.
HDInsight 클러스터 또는 Azure Databricks에서 Spark Streaming과 같은 오픈 소스 Apache 스트리밍 기술을 사용할 수 있습니다.
Azure Functions는 간단한 스트림 처리 작업에 이상적인 이벤트 기반 코드를 실행할 수 있는 서버리스 컴퓨팅 서비스입니다.
패브릭은 이벤트 스트림 및 Spark 처리를 사용하여 실시간 데이터 처리를 지원합니다.
기계 학습: 일괄 처리 또는 스트림 처리에서 준비된 데이터를 분석하려면 기계 학습 알고리즘을 사용하여 결과를 예측하거나 데이터를 분류하는 모델을 빌드할 수 있습니다. 이러한 모델은 큰 데이터 세트에 대해 학습할 수 있습니다. 결과 모델을 사용하여 새 데이터를 분석하고 예측을 수행할 수 있습니다.
Azure Machine Learning을 사용하여 이러한 작업을 수행합니다. Machine Learning은 모델을 빌드, 학습 및 배포하는 도구를 제공합니다. 또는 비전, 음성, 언어 및 의사 결정 작업과 같은 일반적인 기계 학습 작업에 Azure AI 서비스의 미리 빌드된 API를 사용할 수 있습니다.
분석 데이터 저장소: 많은 빅 데이터 솔루션은 분석을 위해 데이터를 준비한 다음 분석 도구에서 쿼리할 수 있는 구조화된 형식으로 처리된 데이터를 제공합니다. 이러한 쿼리를 제공하는 분석 데이터 저장소는 Kimball 스타일의 관계형 데이터 웨어하우스일 수 있습니다. 대부분의 기존 BI(비즈니스 인텔리전스) 솔루션은 이러한 유형의 데이터 웨어하우스를 사용합니다. 또는 HBase와 같은 대기 시간이 짧은 NoSQL 기술 또는 분산 데이터 저장소의 데이터 파일에 대한 메타데이터 추상화 기능을 제공하는 대화형 Hive 데이터베이스를 통해 데이터를 표시할 수 있습니다.
Azure Synapse Analytics는 대규모 클라우드 기반 데이터 웨어하우징을 위한 관리형 서비스입니다.
HDInsight는 대화형 Hive, HBase 및 Spark SQL을 지원합니다. 이러한 도구는 분석을 위해 데이터를 제공할 수 있습니다.
Fabric은 SQL 데이터베이스, 데이터 웨어하우스, 레이크하우스 및 이벤트하우스를 비롯한 다양한 데이터 저장소를 제공합니다. 이러한 도구는 분석을 위해 데이터를 제공할 수 있습니다.
Azure는 Azure Databricks, Azure Data Explorer, Azure SQL Database 및 Azure Cosmos DB와 같은 다른 분석 데이터 저장소를 제공합니다.
분석 및 보고: 대부분의 빅 데이터 솔루션은 분석 및 보고를 통해 데이터에 대한 인사이트를 제공하기 위해 노력합니다. 사용자가 데이터를 분석할 수 있도록 아키텍처에는 다차원 온라인 분석 처리 큐브 또는 Azure Analysis Services의 테이블 형식 데이터 모델과 같은 데이터 모델링 계층이 포함될 수 있습니다. Power BI 또는 Excel에서 모델링 및 시각화 기술을 사용하여 셀프 서비스 BI를 지원할 수도 있습니다.
데이터 과학자 또는 데이터 분석가는 대화형 데이터 탐색을 통해 분석하고 보고할 수도 있습니다. 이러한 시나리오의 경우 많은 Azure 서비스는 Jupyter와 같은 분석 Notebook을 지원하여 이러한 사용자가 Python 또는 Microsoft R에서 기존 기술을 사용할 수 있도록 합니다. 대규모 데이터 탐색의 경우 독립 실행형 또는 Spark에서 Microsoft R Server를 사용할 수 있습니다. 패브릭을 사용하여 데이터 모델링 및 분석을 위한 유연성과 효율성을 제공하는 데이터 모델을 편집할 수도 있습니다.
오케스트레이션: 대부분의 빅 데이터 솔루션은 워크플로에 캡슐화된 반복된 데이터 처리 작업으로 구성됩니다. 작업은 다음 작업을 수행합니다.
- 원본 데이터 변환
- 여러 원본과 싱크 간에 데이터 이동
- 처리된 데이터를 분석 데이터 저장소에 로드
- 보고서 또는 대시보드에 직접 결과 푸시
이러한 워크플로를 자동화하려면 Azure Data Factory, Fabric 또는 Apache Oozie 및 Apache Sqoop과 같은 오케스트레이션 기술을 사용합니다.
람다 아키텍처
큰 데이터 세트를 사용하는 경우 클라이언트에 필요한 쿼리 유형을 실행하는 데 시간이 오래 걸릴 수 있습니다. 이러한 쿼리는 실시간으로 수행할 수 없습니다. 또한 전체 데이터 세트에서 병렬로 작동하는 MapReduce 와 같은 알고리즘이 필요한 경우가 많습니다. 쿼리 결과는 원시 데이터와 별도로 저장되며 추가 쿼리에 사용됩니다.
이 방법의 한 가지 단점은 대기 시간을 도입한다는 것입니다. 처리에 몇 시간이 걸리는 경우 쿼리는 몇 시간 전의 결과를 반환할 수 있습니다. 이상적으로는 정확도가 손실될 수 있는 몇 가지 결과를 실시간으로 가져오고 이러한 결과를 일괄 처리 분석의 결과와 결합해야 합니다.
람다 아키텍처는 데이터 흐름에 대한 두 개의 경로를 만들어 이 문제를 해결합니다. 시스템에 들어오는 모든 데이터는 다음 두 경로를 통과합니다.
일괄 처리 계층(콜드 경로)은 들어오는 모든 데이터를 원시 형식으로 저장하고 데이터에 대한 일괄 처리를 수행합니다. 이 처리의 결과는 일괄 처리 보기로 저장됩니다.
속도 계층(핫 경로)은 데이터를 실시간으로 분석합니다. 이 계층은 정확도는 떨어지지만 짧은 대기 시간을 제공하도록 디자인되었습니다.
일괄 처리 계층은 효율적인 쿼리를 위해 일괄 처리 보기를 인덱싱하는 서비스 계층으로 이동됩니다. 빠른 계층은 가장 최근 데이터를 기준으로 하는 증분 업데이트로 서비스 계층을 업데이트합니다.
속도 계층에 적용되는 대기 시간 요구 사항 때문에 핫 경로로 흐르는 데이터를 신속하게 처리해야 합니다. 빠른 처리를 통해 데이터를 즉시 사용할 준비가 되었지만 부정확성을 도입할 수 있습니다. 예를 들어 수많은 온도 센서가 원격 분석 데이터를 보내는 IoT 시나리오를 고려해 보세요. 속도 계층은 들어오는 데이터의 슬라이딩 타임 창을 처리할 수 있습니다.
콜드 경로로 흐르는 데이터에는 동일한 짧은 대기 시간 요구 사항이 적용되지 않습니다. 콜드 경로는 큰 데이터 세트 간에 높은 정확도 계산을 제공하지만 시간이 오래 걸릴 수 있습니다.
결과적으로, 핫 경로 및 콜드 경로가 분석 클라이언트 애플리케이션에서 합쳐집니다. 클라이언트가 적시에 표시해야 하지만 잠재적으로 정확도가 낮은 데이터를 실시간으로 표시해야 하는 경우 핫 경로에서 결과를 가져옵니다. 그렇지 않으면 클라이언트는 콜드 패스에서 결과를 선택하여 덜 시기적이지만 더 정확한 데이터를 표시합니다. 즉, 핫 패스는 비교적 짧은 시간 동안 데이터를 가지고 있으며, 그 이후에는 콜드 패스의 더 정확한 데이터로 업데이트됩니다.
일괄 처리 계층에 저장된 원시 데이터는 변경할 수 없습니다. 들어오는 데이터는 기존 데이터에 추가되고 이전 데이터는 덮어쓰여지지 않습니다. 특정 데이텀 값에 대한 변경 내용은 새 타임스탬프를 적용한 이벤트 레코드로 저장됩니다. 타임스탬프 이벤트 레코드를 사용하면 수집된 데이터의 기록에서 언제든지 다시 계산할 수 있습니다. 시스템이 발전함에 따라 새 뷰를 만들 수 있으므로 원래 원시 데이터에서 일괄 처리 뷰를 다시 계산하는 기능이 중요합니다.
카파 아키텍처
람다 아키텍처의 단점은 복잡성입니다. 처리 논리는 서로 다른 프레임워크를 통해 콜드 및 핫 경로의 두 가지 위치에 나타납니다. 이 프로세스는 두 경로에 대한 아키텍처의 중복 계산 논리 및 복잡한 관리로 이어집니다.
카파 아키텍처는 람다 아키텍처의 대안입니다. 람다 아키텍처와 동일한 기본 목표를 가지고 있지만 모든 데이터는 스트림 처리 시스템을 통해 단일 경로를 통해 흐릅니다.
람다 아키텍처의 일괄 처리 계층과 마찬가지로 이벤트 데이터는 변경할 수 없으며 데이터의 하위 집합 대신 모든 데이터가 수집됩니다. 데이터는 분산된 내결함성 통합 로그에 이벤트 스트림으로 수집됩니다. 이러한 이벤트는 순서대로 정렬되며, 이벤트의 현재 상태는 추가되는 새 이벤트에 의해서만 변경됩니다. 람다 아키텍처의 속도 계층과 마찬가지로 모든 이벤트 처리는 입력 스트림에서 수행되고 실시간 보기로 유지됩니다.
전체 데이터 세트를 다시 계산해야 하는 경우(람다 아키텍처에서 일괄 처리 계층이 수행하는 것과 동일) 스트림을 재생할 수 있습니다. 이 프로세스는 일반적으로 병렬 처리를 사용하여 적시에 계산을 완료합니다.
레이크하우스 아키텍처
데이터 레이크는 정형 데이터(데이터베이스 테이블), 반구조화된 데이터(XML 파일) 및 구조화되지 않은 데이터(이미지 및 오디오 파일)를 저장하는 중앙 집중식 데이터 리포지토리입니다. 이 데이터는 원래 원시 형식이며 미리 정의된 스키마가 필요하지 않습니다. 데이터 레이크는 대량의 데이터를 처리할 수 있으므로 빅 데이터 처리 및 분석에 적합합니다. 데이터 레이크는 많은 양의 데이터를 저장하는 비용 효율적인 방법을 제공하는 저비용 스토리지 솔루션을 사용합니다.
데이터 웨어하우스는 보고, 분석 및 BI 목적으로 구조화되고 반구조화된 데이터를 저장하는 중앙 집중식 리포지토리입니다. 데이터 웨어하우스는 일관되고 포괄적인 데이터 보기를 제공하여 정보에 입각한 의사 결정을 내리는 데 도움이 될 수 있습니다.
Lakehouse 아키텍처 데이터 레이크 및 데이터 웨어하우스의 최상의 요소를 결합합니다. 이 패턴은 효율적인 데이터 관리 및 분석을 가능하게 하는 구조적 데이터와 구조화되지 않은 데이터를 모두 지원하는 통합 플랫폼을 제공하는 것을 목표로 합니다. 이러한 시스템은 일반적으로 Parquet 또는 Optimized Row Columnar와 같은 개방형 형식의 저비용 클라우드 스토리지를 사용하여 원시 및 처리된 데이터를 모두 저장합니다.
레이크하우스 아키텍처의 일반적인 사용 사례는 다음과 같습니다.
통합 분석: 기록 및 실시간 데이터 분석을 위해 단일 플랫폼이 필요한 조직에 적합합니다.
기계 학습: 데이터 관리 기능을 통합하여 고급 분석 및 기계 학습 워크로드 지원
데이터 거버넌스: 대규모 데이터 세트의 규정 준수 및 데이터 품질 보장
사물 인터넷(IoT
IoT는 인터넷에 연결하고 데이터를 보내거나 받는 모든 디바이스를 나타냅니다. IoT 디바이스에는 PC, 휴대폰, 스마트 워치, 스마트 자동 온도 조절기, 스마트 냉장고, 연결된 자동차 및 심장 모니터링 임플란트가 포함됩니다.
연결된 디바이스의 수는 매일 증가하며 생성되는 데이터 양도 증가합니다. 이 데이터는 종종 상당한 제약 조건과 경우에 따라 대기 시간이 긴 환경에서 수집됩니다. 다른 경우에는 수천 또는 수백만 대의 디바이스가 짧은 대기 시간 환경에서 데이터를 전송하므로 신속한 수집 및 처리가 필요합니다. 이러한 제약 조건 및 고유한 요구 사항을 적절하게 처리할 계획을 세워야 합니다.
이벤트 기반 아키텍처는 IoT 솔루션의 핵심입니다. 다음 다이어그램에서는 IoT에 대한 논리 아키텍처를 보여 있습니다. 다이어그램은 아키텍처의 이벤트 스트리밍 구성 요소를 강조합니다.
클라우드 게이트웨이는 신뢰할 수 있는 짧은 대기 시간 메시징 시스템을 통해 클라우드 경계에서 디바이스 이벤트를 수집합니다.
디바이스는 클라우드 게이트웨이 또는 필드 게이트웨이를 통해 직접 이벤트를 보낼 수 있습니다. 필드 게이트웨이는 이벤트를 수신하여 클라우드 게이트웨이에 전달하는 특수 디바이스 또는 소프트웨어이며 일반적으로 디바이스와 함께 배치됩니다. 필드 게이트웨이는 필터링, 집계 또는 프로토콜 변환 함수 수행을 포함하는 원시 디바이스 이벤트를 전처리할 수도 있습니다.
수집 후 이벤트는 스토리지와 같은 대상으로 데이터를 라우팅하거나 분석 및 기타 처리를 수행할 수 있는 하나 이상의 스트림 프로세서 를 통과합니다.
일반적인 처리 유형은 다음과 같습니다.
보관 또는 일괄 처리를 위해 콜드 스토리지에 이벤트 데이터 쓰기
핫 경로 분석. 이벤트 스트림을 거의 실시간으로 분석하여 변칙을 검색하거나, 롤링 시간 기간 동안 패턴을 인식하거나, 스트림에서 특정 조건이 발생할 때 경고를 트리거합니다.
알림, 경보 등 디바이스에서 수신된 특수 유형의 비원격 분석 메시지 처리.
기계 학습.
이전 다이어그램에서 회색 상자는 이벤트 스트리밍과 직접 관련이 없는 IoT 시스템의 구성 요소입니다. 완성도를 위해 다이어그램에 포함됩니다.
디바이스 레지스트리 디바이스 ID 및 일반적으로 디바이스 메타데이터(예: 위치)를 포함하여 프로비전된 디바이스의 데이터베이스입니다.
프로비전 API 새 디바이스를 프로비전하고 등록하기 위한 일반적인 외부 인터페이스입니다.
일부 IoT 솔루션을 사용하면 명령 및 제어 메시지 디바이스로 보낼 수 있습니다.