빅 데이터 아키텍처 스타일

빅 데이터 아키텍처는 기존의 데이터베이스 시스템에 비해 너무 크거나 복잡한 데이터의 수집, 처리 및 분석을 수행하도록 디자인되었습니다.

빅 데이터 솔루션에는 일반적으로 다음 중 하나 이상의 워크로드 유형이 포함됩니다.

• 미사용 빅 데이터 원본의 일괄 처리
• 사용 중인 빅 데이터의 실시간 처리
• 빅 데이터의 대화형 탐색
• 예측 분석 및 기계 학습

대부분의 빅 데이터 아키텍처에는 다음 구성 요소의 일부 또는 전체가 포함됩니다.

• 데이터 원본: 모든 빅 데이터 솔루션은 하나 이상의 데이터 원본에서 시작합니다. 다음은 이러한 템플릿의 예입니다.

  • 애플리케이션 데이터 저장소(예: 관계형 데이터베이스)
  • 애플리케이션에서 생성하는 정적 파일(예: 웹 서버 로그 파일)
  • 실시간 데이터 원본(예: IoT 디바이스)

• 데이터 스토리지: 일괄 처리 작업을 위한 데이터는 대용량 대용량 파일을 다양한 형식으로 저장할 수 있는 분산 파일 저장소에 일반적으로 저장됩니다. 이런 종류의 저장소를 Data Lake라고도 합니다. 이 스토리지를 구현하기 위한 옵션으로는 Azure Data Lake Store 또는 Azure Storage의 BLOB 컨테이너가 있습니다.

• 일괄 처리: 데이터 집합이 너무 크기 때문에 빅 데이터 솔루션은 장기 실행 일괄 처리 작업을 사용하여 데이터 파일을 처리하여 분석을 위해 데이터를 필터링, 집계 및 준비해야 하는 경우가 많습니다. 일반적으로 이러한 작업은 원본 파일 읽기 및 처리와 새 파일에 출력 작성으로 이루어집니다. 옵션에는 Azure Data Lake Analytics에서 U-SQL 작업 실행, HDInsight Hadoop 클러스터에서 Hive, Pig 또는 사용자 지정 Map/Reduce 작업 사용, HDInsight Spark 클러스터에서 Java, Scala 또는 Python 프로그램 사용 등이 있습니다.

• 실시간 메시지 수집: 솔루션에 실시간 원본이 포함된 경우 아키텍처는 스트림 처리를 위해 실시간 메시지를 캡처하고 저장하는 방법을 포함해야 합니다. 이는 들어오는 메시지가 처리를 위해 폴더에 저장되는 간단한 데이터 저장소일 수 있습니다. 그러나 많은 솔루션에는 메시지에 대한 버퍼로 작동하고 스케일 아웃 처리, 안정적인 전달 및 기타 메시지 큐 의미 체계를 지원하는 메시지 수집 저장소가 필요합니다. 옵션에는 Azure Event Hubs, Azure IoT Hubs 및 Kafka가 포함됩니다.

• 스트림 처리: 실시간 메시지를 캡처한 후 솔루션은 필터링, 집계 및 분석을 위해 데이터를 준비하여 처리해야 합니다. 그런 다음, 처리된 스트림 데이터는 출력 싱크에 기록됩니다. Azure Stream Analytics는 제한되지 않은(Unbounded) 스트림에서 작동하는 영구적으로 실행되는 SQL 쿼리를 기반으로 관리되는 스트림 처리 서비스를 제공합니다. HDInsight 클러스터에서 Spark Streaming과 같은 오픈 소스 Apache 스트리밍 기술을 사용할 수도 있습니다.

• 분석 데이터 저장소: 많은 빅 데이터 솔루션은 분석을 위해 데이터를 준비한 다음 분석 도구를 사용하여 쿼리할 수 있는 구조화된 형식으로 처리된 데이터를 제공합니다. 이러한 쿼리를 처리하는 데 사용되는 분석 데이터 저장소로는 대부분의 기존 BI(비즈니스 인텔리전스) 솔루션에서 볼 수 있는 Kimball 스타일의 관계형 데이터 웨어하우스가 있습니다. 또는 HBase와 같이 대기 시간이 짧은 NoSQL 기술이나, 분산 데이터 저장소의 데이터 파일에 대한 메타데이터 추상화를 제공하는 대화형 Hive 데이터베이스를 통해 데이터를 제공할 수 있습니다. Azure Synapse Analytics는 클라우드 기반의 대규모 데이터 웨어하우징을 위한 관리형 서비스를 제공합니다. HDInsight는 대화형 Hive, HBase 및 Spark SQL을 지원하며 이들을 사용하여 분석용 데이터를 처리할 수도 있습니다.

• 분석 및 보고: 대부분의 빅 데이터 솔루션의 목표는 분석 및 보고를 통해 데이터에 대한 정보를 제공하는 것입니다. 사용자의 데이터 분석을 지원하도록 아키텍처에는 Azure Analysis Services의 다차원 OLAP 큐브 또는 테이블 형식 데이터 모델과 같은 데이터 모델링 계층이 포함될 수 있습니다. 또한 Microsoft Power BI 또는 Microsoft Excel의 모델링 기술 및 시각화 기술을 사용하여 셀프 서비스 BI를 지원할 수도 있습니다. 분석 및 보고는 데이터 과학자 또는 데이터 분석가에 의한 대화형 데이터 탐색의 형태를 취할 수도 있습니다. 이러한 시나리오의 경우 많은 Azure 서비스가 Jupyter와 같은 분석용 노트북을 지원하므로 사용자가 Python 또는 R을 사용하여 기존 기술을 활용할 수 있습니다. 대규모 데이터 탐색의 경우 Microsoft R Server를 독립적으로 또는 Spark와 함께 사용할 수 있습니다.

• 오케스트레이션: 대부분의 빅 데이터 솔루션은 반복적인 데이터 처리 작업으로 구성되며, 워크플로에 캡슐화되어 원본 데이터를 변환하거나, 여러 원본과 싱크 간에 데이터를 이동하거나, 처리된 데이터를 분석 데이터 저장소에 로드하거나, 결과를 보고서 또는 대시보드로 바로 푸시합니다. 이러한 워크플로를 자동화하기 위해 Azure Data Factory 또는 Apache Oozie 및 Sqoop과 같은 오케스트레이션 기술을 사용할 수 있습니다.

Azure에는 빅 데이터 아키텍처에서 사용할 수 있는 많은 서비스가 포함되어 있습니다. 이 서비스들은 크게 두 가지 범주로 나뉩니다.

• Azure Data Lake Store, Azure Data Lake Analytics, Azure Synapse Analytics, Azure Stream Analytics, Azure Event Hubs, Azure IoT Hub 및 Azure Data Factory를 포함한 관리되는 서비스.
• HDFS, HBase, Hive, Spark, Oozie, Sqoop 및 Kafka를 비롯한 Apache Hadoop 플랫폼을 기반으로 하는 오픈 소스 기술입니다. 이러한 기술은 Azure HDInsight 서비스의 Azure에서 사용할 수 있습니다.

위 옵션들은 상호 배타적이지 않으며 대부분의 솔루션은 오픈 소스 기술과 Azure 서비스를 결합합니다.

이 아키텍처를 사용하는 경우

다음 작업을 수행해야 하는 경우 이 아키텍처 스타일을 고려합니다.

• 기존 데이터베이스에 비해 너무 큰 볼륨의 데이터 저장 및 처리
• 분석 및 보고를 위해 구조화되지 않은 데이터 변환
• 제한되지 않은 데이터 스트림을 실시간으로 또는 짧은 대기 시간으로 수집, 처리 및 분석
• Azure Machine Learning 또는 Azure Cognitive Services를 사용합니다.

이점

• 기술 선택. HDInsight 클러스터의 Azure 관리 서비스 및 Apache 기술을 혼합하고 일치하여 기존 기술 또는 기술 투자를 활용할 수 있습니다.
• 병렬 처리를 통한 성능 빅 데이터 솔루션은 병렬 처리를 활용하여 대량의 데이터로 확장되는 고성능 솔루션을 가능하게 합니다.
• 탄력적 확장. 빅 데이터 아키텍처의 모든 구성 요소는 스케일 아웃 프로비저닝을 지원하므로 솔루션을 작거나 큰 워크로드에 맞게 조정하고 사용하는 리소스에 대해서만 비용을 지불할 수 있습니다.
• 기존 솔루션과의 상호 운용성. 빅 데이터 아키텍처의 구성 요소는 IoT 처리 및 엔터프라이즈 BI 솔루션에도 사용되므로 데이터 워크로드 간에 통합 솔루션을 만들 수 있습니다.

챌린지

• 복잡성. 빅 데이터 솔루션은 여러 데이터 원본에서 데이터 수집을 처리하는 다양한 구성 요소에 의해 매우 복잡할 수 있습니다. 빅 데이터 프로세스를 빌드, 테스트 및 해결하는 것은 어려울 수 있습니다. 또한 성능을 최적화하기 위해 사용해야 하는 여러 시스템에서 많은 수의 구성 설정이 있을 수 있습니다.
• 기능. 많은 빅 데이터 기술은 고도로 전문화되어 있으며 일반적인 애플리케이션 아키텍처가 아닌 프레임워크 및 언어를 사용합니다. 반면, 빅 데이터 기술은 더 확립된 언어를 기반으로 하는 새로운 API를 발전하고 있습니다. 예를 들어 Azure Data Lake Analytics의 U-SQL 언어는 TRANSACT-SQL 및 C#의 조합을 기반으로 합니다. 마찬가지로 Hive, HBase 및 Spark에 SQL 기반 API를 사용할 수 있습니다.
• 기술 완성도. 빅 데이터에 사용되는 많은 기술이 진화하고 있습니다. Hive 및 Pig와 같은 핵심 Hadoop 기술이 안정화되는 동안 Spark와 같은 새로운 기술은 새로운 릴리스마다 광범위한 변경 및 향상된 기능을 도입합니다. Azure Data Lake Analytics 및 Azure Data Factory와 같은 관리되는 서비스는 다른 Azure 서비스와 비교하여 비교적 젊으며 시간이 지남에 따라 발전할 가능성이 높습니다.
• 보안. 빅 데이터 솔루션은 일반적으로 모든 정적 데이터를 중앙 집중식 데이터 레이크에 저장하는 데 의존합니다. 특히 여러 애플리케이션 및 플랫폼에서 데이터를 수집하고 사용해야 하는 경우 이 데이터에 대한 액세스를 보호하는 것이 어려울 수 있습니다.

모범 사례

• 병렬 처리 활용. 대부분의 빅 데이터 처리 기술은 다중 처리 장치에 워크로드를 분산시킵니다. 이를 위해서는 분할 가능한 형식으로 정적 데이터 파일을 만들고 저장해야 합니다. HDFS와 같은 분산 파일 시스템은 읽기 및 쓰기 성능을 최적화할 수 있으며 실제 처리는 여러 클러스터 노드에서 병렬로 수행되므로 전체 작업 시간이 줄어듭니다.

• 데이터를 분할합니다. 일괄 처리는 일반적으로 매주 또는 매월과 같은 되풀이 일정에서 발생합니다. 처리 일정과 일치하는 임시 기간에 따라 데이터 파일 및 테이블과 같은 데이터 구조를 분할합니다. 이렇게 하면 데이터 수집 및 작업 예약을 단순화하고 오류를 쉽게 해결할 수 있습니다. 또한 Hive, U-SQL 또는 SQL 쿼리에 사용되는 테이블을 분할하면 쿼리 성능이 크게 향상될 수 있습니다.

• 읽기 시 스키마 의미 체계를 적용합니다. 데이터 레이크를 사용하면 구조적, 반구조적 또는 비구조적이든 관계없이 여러 형식의 파일에 대한 스토리지를 결합할 수 있습니다. 데이터가 저장될 때가 아니라 데이터를 처리할 때 스키마를 데이터에 프로젝터하는 스키마 온 읽기 의미 체계를 사용합니다. 이렇게 하면 솔루션에 유연성이 구축되고 데이터 유효성 검사 및 형식 검사 인해 발생하는 데이터 수집 중에 병목 현상이 발생하지 않습니다.

• 현재 위치에서 데이터를 처리합니다. 기존 BI 솔루션은 종종 ETL(추출, 변환 및 로드) 프로세스를 사용하여 데이터를 데이터 웨어하우스로 이동합니다. 대용량 데이터와 다양한 형식을 사용하는 빅 데이터 솔루션은 일반적으로 TEL(변환, 추출 및 로드)과 같은 ETL의 변형을 사용합니다. 이 방식을 사용하면 변환된 데이터를 분석 데이터 저장소로 이동하기 전에 분산 데이터 저장소에서 데이터를 처리하여 필요한 구조로 변환할 수 있습니다.

• 사용률 및 시간 비용의 균형을 조정합니다. 일괄 처리 작업의 경우 컴퓨팅 노드의 단위당 비용과 해당 노드를 사용하여 작업을 완료하는 분당 비용이라는 두 가지 요소를 고려해야 합니다. 예를 들어 네 개의 클러스터 노드로 8시간이 걸리는 일괄 처리 작업이 있다고 간주합니다. 그러나 작업에서 처음 두 시간 동안만 네 개의 노드를 모두 사용하고 그 후에는 두 개의 노드만 필요하다고 판명될 수 있습니다. 이 경우 두 노드에서 전체 작업을 실행하면 총 작업 시간이 늘어나지만 두 배가 되지 않으므로 총 비용이 줄어듭니다. 일부 비즈니스 시나리오에서는 활용도가 낮은 클러스터 리소스를 사용하는 데 드는 높은 비용보다 처리 시간이 길어지는 것을 선호할 수 있습니다.

• 클러스터 리소스를 구분합니다. HDInsight 클러스터를 배포할 때 일반적으로 각 워크로드 유형에 대해 별도의 클러스터 리소스를 프로비전하여 더 나은 성능을 얻을 수 있습니다. 예를 들어 Spark 클러스터에 Hive가 포함되어 있지만 Hive 및 Spark를 사용하여 광범위한 처리를 수행해야 하는 경우 별도의 전용 Spark 및 Hadoop 클러스터를 배포하는 것이 좋습니다. 마찬가지로, 짧은 대기 시간 스트림 처리에 HBase 및 Storm을 사용하고 일괄 처리에 Hive를 사용하는 경우 Storm, HBase 및 Hadoop에 대해 별도의 클러스터를 고려합니다.

• 데이터 수집 오케스트레이션. 경우에 따라 기존 비즈니스 애플리케이션은 일괄 처리를 위한 데이터 파일을 Azure Storage Blob 컨테이너에 직접 쓸 수 있으며, 여기서 HDInsight 또는 Azure Data Lake Analytics에서 사용할 수 있습니다. 그러나 온-프레미스 또는 외부 데이터 원본에서 데이터 레이크로의 데이터 수집을 오케스트레이션해야 하는 경우가 많습니다. 이를 예측 가능하고 중앙 집중식 관리 방법으로 구현하도록 하려면 Azure Data Factory 또는 Oozie에서 지원하는 것과 같은 오케스트레이션 워크플로 또는 파이프라인을 사용합니다.

• 중요한 데이터를 일찍 스크러빙합니다. 데이터 수집 워크플로는 데이터 레이크에 저장하지 않도록 프로세스 초기에 중요한 데이터를 스크러빙해야 합니다.

IoT 아키텍처

IoT(사물 인터넷)는 빅 데이터 솔루션의 특수 하위 집합입니다. 다음 다이어그램은 IoT의 가능한 논리 아키텍처를 보여 줍니다. 이 다이어그램에서는 아키텍처의 이벤트 스트리밍 구성 요소가 강조 표시되어 있습니다.

클라우드 게이트웨이는 안정적이고 대기 시간이 짧은 메시징 시스템을 사용하여 클라우드 경계에서 디바이스 이벤트를 수집합니다.

디바이스는 클라우드 게이트웨이에 직접 또는 필드 게이트웨이를 통해 이벤트를 보낼 수 있습니다. 필드 게이트웨이는 이벤트를 수신하여 클라우드 게이트웨이에 전달하는 특수 디바이스 또는 소프트웨어이며 일반적으로 디바이스와 함께 배치됩니다. 필드 게이트웨이에서 필터링, 집계, 프로토콜 변환 등의 기능을 수행하여 원시 디바이스 이벤트를 전처리할 수도 있습니다.

수집된 이벤트는 데이터를 스토리지 등으로 라우트하거나 분석 및 기타 처리를 수행할 수 있는 하나 이상의 스트림 프로세서를 통과합니다.

다음은 몇 가지 일반적인 처리 유형입니다. (전체 목록은 아닙니다.)

• 보관 또는 배치 분석을 위해 콜드 스토리지에 이벤트 데이터 기록.

• 실행 부하 과다 경로 분석, (거의) 실시간으로 이벤트 스트림을 분석하여 이상 검색, 롤링 기간의 패턴 인식 또는 스트림에서 특정 조건이 발생할 때 경고 트리거.

• 알림 및 경보와 같은 디바이스에서 특수한 유형의 비 원격 분석 메시지 처리

• 기계 학습.

회색으로 표시된 상자는 이벤트 스트리밍과 직접 관련되지 않은 IoT 시스템의 구성 요소를 표시하지만 전체 표시를 위해 여기에 포함되었습니다.

• 디바이스 레지스트리는 디바이스 ID와 일반적으로 디바이스 메타데이터(예: 위치)를 포함하는 프로비전된 디바이스의 데이터베이스입니다.

• 프로비저닝 API는 새 디바이스를 프로비전 및 등록하기 위한 공통 외부 인터페이스입니다.

• 일부 IoT 솔루션에서는 명령 및 제어 메시지를 디바이스에 전송할 수 있습니다.

이 섹션에서는 IoT에 대한 매우 높은 수준의 보기를 제공했으며 고려해야 할 많은 미묘한 문제와 과제가 있습니다. 자세한 참조 아키텍처 및 논의 는 Microsoft Azure IoT 참조 아키텍처 (PDF 다운로드)를 참조하세요.

다음 단계

• 빅 데이터 아키텍처에 대해 자세히 알아보세요.
• IoT(사물 인터넷) 아키텍처 디자인에 대해 자세히 알아봅니다.