Microsoft Fabric 의사 결정 가이드: 데이터 저장소 선택
이 참조 가이드와 예제 시나리오를 사용하여 Microsoft Fabric 워크로드에 대한 데이터 저장소를 선택할 수 있습니다.
데이터 저장소 속성
이 정보를 사용하여 데이터 볼륨, 형식, 개발자 페르소나, 기술 집합, 작업 및 기타 기능을 기반으로 웨어하우스, 레이크하우스, Eventhouse, SQL 데이터베이스 및 Power BI 데이터 마트와 같은 패브릭 데이터 저장소를 비교합니다. 이러한 비교는 다음 두 테이블로 구성됩니다.
표 1 (총 2개 중) | Lakehouse | 웨어하우스 | Eventhouse |
---|---|---|---|
데이터 볼륨 | 제한 없음 | 제한 없음 | 제한 없음 |
데이터 유형 | 구조화 되지 않은 반구조화, 구조화됨 |
구조화 된 반구조화 (JSON) |
구조화 되지 않은 반구조화, 구조화됨 |
기본 개발자 가상 사용자 | 데이터 엔지니어, 데이터 과학자 | 데이터 웨어하우스 개발자, 데이터 설계자, 데이터 엔지니어, 데이터베이스 개발자 | 앱 개발자, 데이터 과학자, 데이터 엔지니어 |
기본 개발 기술 | Spark(Scala, PySpark, Spark SQL, R) | SQL | 코드 없음, KQL, SQL |
다음으로 구성된 데이터 | 폴더 및 파일, 데이터베이스 및 테이블 | 데이터베이스, 스키마 및 테이블 | 데이터베이스, 스키마 및 테이블 |
읽기 작업 | Spark, T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
작업 쓰기 | Spark(Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Spark, 커넥터 에코시스템 |
다중 테이블 트랜잭션 | 예 | 예 | 예, 다중 테이블 수집의 경우 |
기본 개발 인터페이스 | Spark Notebook, Spark 작업 정의 | SQL 스크립트 | KQL 쿼리 세트, KQL 데이터베이스 |
보안 | RLS, CLS**, 테이블 수준 (T-SQL), Spark에 대한 없음 | 개체 수준, RLS, CLS, DDL/DML, 동적 데이터 마스킹 | RLS |
바로 가기를 사용하여 데이터에 액세스 | 예 | 예, SQL 분석 엔드포인트를 통해 | 예 |
바로 가기의 원본이 될 수 있습니다 | 예(파일 및 테이블) | 예(테이블) | 예 |
항목 간 쿼리 | 예 | 예 | 예 |
고급 분석 | 대규모 데이터 처리, 기본 제공 데이터 병렬 처리 및 내결함성을 위한 인터페이스 | 대규모 데이터 처리, 기본 제공 데이터 병렬 처리 및 내결함성을 위한 인터페이스 | 시계열 네이티브 요소, 전체 지역 공간 및 쿼리 기능 |
고급 서식 지원 | PARQUET, CSV, AVRO, JSON 및 Apache Hive 호환 파일 형식을 사용하여 정의된 테이블 | PARQUET, CSV, AVRO, JSON 및 Apache Hive 호환 파일 형식을 사용하여 정의된 테이블 | 무료 텍스트 및 JSON과 같은 반정형 데이터를 위한 전체 인덱싱 |
수집 대기 시간 | 쿼리에 즉시 사용 가능 | 쿼리에 즉시 사용 가능 | 대기 중인 수집, 스트리밍 수집에는 몇 초의 대기 시간이 있습니다. |
* Spark는 바로 가기를 사용하여 테이블에서 읽기를 지원하며 뷰, 저장 프로시저, 함수 등에 대한 액세스를 아직 지원하지 않습니다.
표 2/2 | 패브릭 SQL 데이터베이스 | Power BI 데이터 마트 |
---|---|---|
데이터 볼륨 | 4 TB | 최대 100GB |
데이터 유형 | 구조화 된 반구조화, 비구조적 |
구조적 |
기본 개발자 가상 사용자 | AI 개발자, 앱 개발자, 데이터베이스 개발자, DB 관리자 | 데이터 과학자, 데이터 분석가 |
기본 개발 기술 | SQL | 코드 없음, SQL |
다음으로 구성된 데이터 | 데이터베이스, 스키마, 테이블 | 데이터베이스 테이블, 쿼리 |
읽기 작업 | T-SQL | Spark, T-SQL |
작업 쓰기 | T-SQL | 데이터 흐름, T-SQL |
다중 테이블 트랜잭션 | 예, 전체 ACID 규정 준수 | 예 |
기본 개발 인터페이스 | SQL 스크립트 | Power BI |
보안 | 개체 수준, RLS, CLS, DDL/DML, 동적 데이터 마스킹 | 기본 제공 RLS 편집기 |
바로 가기를 사용하여 데이터에 액세스 | 예 | 예 |
바로 가기의 원본이 될 수 있습니다 | 예(테이블) | 예 |
항목 간 쿼리 | 예 | 예 |
고급 분석 | T-SQL 분석 기능, 분석을 위해 OneLake의 델타 parquet에 복제된 데이터 | 자동화된 성능 튜닝을 사용하여 데이터 처리를 위한 인터페이스 |
고급 서식 지원 | OLTP, JSON, 벡터, 그래프, XML, 공간, 키-값에 대한 테이블 지원 | PARQUET, CSV, AVRO, JSON 및 Apache Hive 호환 파일 형식을 사용하여 정의된 테이블 |
수집 대기 시간 | 쿼리에 즉시 사용 가능 | 쿼리에 즉시 사용 가능 |
** T-SQL을 사용하여 SQL 분석 엔드포인트를 통해 Lakehouse에서 사용할 수 있는 열 수준 보안입니다.
시나리오
Fabric에서 데이터 저장소를 선택하는 데 도움이 필요하면 이러한 시나리오를 검토하세요.
시나리오 1
전문 개발자인 Susan은 Microsoft Fabric의 새로운 기능입니다. 데이터 정리, 모델링 및 분석을 시작할 준비가 되었지만 데이터 웨어하우스 또는 레이크하우스를 빌드해야 합니다. 이전 테이블의 세부 정보를 검토한 후 기본 의사 결정 지점은 사용 가능한 기술 집합 및 다중 테이블 트랜잭션의 필요성입니다.
Susan은 관계형 데이터베이스 엔진에서 데이터 웨어하우스를 빌드하는 데 수년을 보냈으며 SQL 구문 및 기능에 익숙합니다. 더 큰 팀을 고려할 때 이 데이터의 주요 소비자는 SQL 및 SQL 분석 도구에도 능숙합니다. Susan은 패브릭 웨어하우스를 사용하기로 결정하여 팀이 주로 T-SQL과 상호 작용할 수 있는 동시에 조직의 모든 Spark 사용자가 데이터에 액세스할 수 있도록 허용합니다.
Susan은 새 데이터 웨어하우스를 만들고 다른 SQL Server 데이터베이스와 마찬가지로 T-SQL을 사용하여 상호 작용합니다. SQL Server에서 웨어하우스를 빌드하기 위해 작성한 대부분의 기존 T-SQL 코드는 패브릭 데이터 웨어하우스에서 작동하므로 쉽게 전환할 수 있습니다. 선택한 경우 SQL Server Management Studio와 같은 다른 데이터베이스에서 작동하는 동일한 도구를 사용할 수도 있습니다. Fabric 포털의 SQL 편집기를 사용하여 Susan과 다른 팀 구성원들은 레이크하우스 내의 다른 데이터 웨어하우스와 델타 테이블을 참조하는 분석 쿼리를 작성합니다. 이렇게 하기 위해, 그들은 데이터베이스 간 쿼리를 쉽게 수행할 수 있도록 세 부분으로 이루어진 이름을 사용합니다.
시나리오 2
데이터 엔지니어인 Rob은 몇 테라바이트 단위의 데이터를 Fabric에 저장하고 모델링해야 합니다. 팀에는 PySpark 및 T-SQL 기술을 함께 사용하고 있습니다. T-SQL 쿼리를 실행하는 대부분의 팀은 소비자이므로 INSERT, UPDATE 또는 DELETE 문을 작성할 필요가 없습니다. 나머지 개발자는 Notebook에서 편안하게 작업할 수 있으며, 데이터가 Delta에 저장되므로 유사한 SQL 구문과 상호 작용할 수 있습니다.
Rob은 데이터 엔지니어링 팀이 데이터에 대해 다양한 기술을 사용할 수 있도록 하는 레이크하우스를 사용하기로 결정하고, T-SQL에 고도로 숙련된 팀원이 데이터를 사용할 수 있도록 합니다.
시나리오 3
시민 개발자인 Ash는 Power BI 개발자입니다. Excel, Power BI 및 Office에 익숙합니다. 사업부에 대한 데이터 제품을 빌드해야 합니다. 그들은 데이터 웨어하우스나 레이크하우스를 빌드할 수 있는 기술이 없다는 것을 알고 있으며, 요구 사항과 데이터 볼륨에 비해 너무 과하다고 생각합니다. 이전 표의 세부 정보를 검토하고 기본 의사 결정 지점이 자체 기술과 셀프 서비스에 대한 필요성, 코드 기능 없음 및 100GB 미만의 데이터 볼륨임을 확인합니다.
Ash는 Power BI 및 Microsoft Office에 익숙한 비즈니스 분석가와 함께 작동하며 이미 프리미엄 용량 구독이 있음을 알고 있습니다. 더 큰 팀에 대해 생각할 때 이 데이터의 기본 소비자는 코드 없음 및 SQL 분석 도구에 익숙한 분석가라는 것을 알게 됩니다. Ash는 코드 없는 환경을 사용하여 팀이 기능을 빠르게 빌드할 수 있도록 하는 Power BI 데이터 마트를 사용하기로 결정합니다. 쿼리는 Power BI 및 T-SQL을 통해 실행할 수 있으며 조직의 Spark 사용자도 데이터에 액세스할 수 있습니다.
시나리오 4
Daisy는 Power BI를 사용하여 대형 글로벌 소매 체인의 공급망 병목 상태를 분석한 경험이 있는 비즈니스 분석가입니다. 수십억 개의 데이터 행을 처리할 수 있고 비즈니스 의사 결정을 내리는 데 사용할 수 있는 대시보드 및 보고서를 빌드하는 데 사용할 수 있는 확장 가능한 데이터 솔루션을 빌드해야 합니다. 데이터는 다양한 구조적, 반구조적 및 비구조적 형식의 공장, 공급 업체, 배송업체 및 기타 소스에서 제공됩니다.
Daisy는 확장성, 빠른 응답 시간, 시계열 분석, 지리 공간적 함수 및 Power BI의 빠른 직접 쿼리 모드를 비롯한 고급 분석 기능으로 인해 Eventhouse를 사용하기로 결정했습니다. Power BI 및 KQL로 쿼리를 실행하여 현재 기간과 이전 기간을 비교하거나, 새로운 문제를 신속하게 식별하거나, 육상 및 해상 경로의 지리적 공간 분석을 제공할 수 있습니다.
시나리오 5
커비는 운영 데이터를 위한 .NET 애플리케이션을 개발한 애플리케이션 설계자입니다. 전체 ACID 트랜잭션 규정 준수와 관계형 무결성을 위해 강력하게 적용되는 외래 키가 있는 높은 동시성 데이터베이스가 필요합니다. 커비는 일상적인 데이터베이스 관리를 간소화하기 위해 자동 성능 튜닝의 이점을 원합니다.
커비는 Azure SQL Database와 동일한 SQL 데이터베이스 엔진 사용하여 Fabric의 SQL 데이터베이스를 결정합니다. 패브릭의 SQL 데이터베이스는 업무 일 내내 수요에 맞게 자동으로 확장됩니다. 트랜잭션 테이블의 전체 기능과 직렬화 가능에서 커밋된 스냅샷 읽기까지 트랜잭션 격리 수준의 유연성이 있습니다. 패브릭의 SQL 데이터베이스는 시간이 지남에 따라 관찰된 실행 계획의 강력한 신호에 따라 비클러스터형 인덱스를 자동으로 만들고 삭제합니다.
커비의 시나리오에서 운영 애플리케이션의 데이터는 Spark, 웨어하우스 및 Eventhouse의 실시간 이벤트에서 패브릭의 다른 데이터와 조인되어야 합니다. 모든 패브릭 데이터베이스에는 SQL 분석 엔드포인트가 포함되어 있으므로 DirectLake 모드를 사용하여 Spark 또는 Power BI 쿼리에서 실시간으로 데이터에 액세스할 수 있습니다. 이러한 보고 솔루션은 분석 워크로드의 오버헤드에서 주 운영 데이터베이스를 절약하고 비정규화를 방지합니다. 또한 커비는 다른 SQL 데이터베이스에 기존 운영 데이터를 가지고 있으며 변환 없이 해당 데이터를 가져와야 합니다. 데이터 형식 변환 없이 기존 운영 데이터를 가져오기 위해, 커비는 Fabric Data Factory를 사용하여 데이터 파이프라인을 설계하여 데이터를 Fabric SQL 데이터베이스로 가져옵니다.