Microsoft Fabric 의사 결정 가이드: 데이터 저장소 선택
이 참조 가이드와 예제 시나리오를 사용하여 Microsoft Fabric 워크로드에 대한 데이터 저장소를 선택할 수 있습니다.
데이터 저장소 속성
이 테이블에서는 데이터 볼륨, 형식, 개발자 가상 사용자, 기능, 작업을 기반으로 웨어하우스, 레이크하우스, Power BI 데이터마트 및 Eventhouse와 같은 데이터 저장소를 비교합니다. 및 그 외 기능.
| 창고 | Lakehouse | Power BI 데이터 마트 | Eventhouse | |
|---|---|---|---|---|
| 데이터 볼륨 | 제한 없음 | 무제한 | 최대 100GB | 무제한 |
| 데이터 유형 | 구조적 | 비구조적, 반구조적, 구조적 | 구조적 | 비구조적, 반구조적, 구조적 |
| 기본 개발자 가상 사용자 | 데이터 웨어하우스 개발자, SQL 엔지니어 | 데이터 엔지니어, 데이터 과학자 | 시민 개발자 | 시민 데이터 과학자, 데이터 엔지니어, 데이터 과학자, SQL 엔지니어 |
| 기본 개발자 기능 | SQL | Spark(Scala, PySpark, Spark SQL, R) | 코드 없음, SQL | 코드 없음, KQL, SQL |
| 다음으로 구성된 데이터 | 데이터베이스, 스키마 및 테이블 | 폴더 및 파일, 데이터베이스 및 테이블 | 데이터베이스 테이블, 쿼리 | 데이터베이스, 스키마 및 테이블 |
| 읽기 작업 | T-SQL, Spark(바로 가기를 사용하여 테이블에서 읽기 지원, 뷰 액세스, 저장 프로시저, 함수 등을 아직 지원하지 않음) | Spark, T-SQL | Spark, T-SQL, Power BI | KQL, T-SQL, Spark, Power BI |
| 작업 쓰기 | T-SQL | Spark(Scala, PySpark, Spark SQL, R) | 데이터 흐름, T-SQL | KQL, Spark, 커넥터 에코시스템 |
| 다중 테이블 트랜잭션 | 예 | 없음 | 아니요 | 예, 다중 테이블 수집의 경우입니다. 정책 업데이트를 참고하세요. |
| 기본 개발 인터페이스 | SQL 스크립트 | Spark Notebook, Spark 작업 정의 | Power BI | KQL 쿼리 세트, KQL 데이터베이스 |
| 보안 | 개체 수준(테이블, 뷰, 함수, 저장 프로시저 등), 열 수준, 행 수준, DDL/DML, 동적 데이터 마스킹 | 행 수준, 열 수준(SQL 분석 엔드포인트를 통해 액세스하는 Lakehouse의 경우), 테이블 수준(T-SQL 사용 시), Spark에는 없음 | 기본 제공 RLS 편집기 | 행 수준 보안 |
| 바로 가기를 사용하여 데이터에 액세스 | 예, 세 부분으로 된 이름을 사용하는 레이크하우스를 통해 | 예 | 없음 | 예 |
| 바로 가기의 원본이 될 수 있습니다 | 예(테이블) | 예(파일 및 테이블) | 예 | 예 |
| 항목 간 쿼리 | 예, 레이크하우스 및 웨어하우스 테이블에서 쿼리합니다 | 예, 레이크하우스 및 웨어하우스 테이블에서 쿼리합니다, 레이크하우스 간 쿼리합니다(Spark를 사용하는 바로 가기 포함) | 아니요 | 예, 바로 가기를 사용하여 KQL 데이터베이스, 레이크하우스 및 웨어하우스에서 쿼리 |
시나리오
Fabric에서 데이터 저장소를 선택하는 데 도움이 필요하면 이러한 시나리오를 검토하세요.
시나리오 1
전문 개발자인 Susan은 Microsoft Fabric의 새로운 기능입니다. 데이터 정리, 모델링 및 분석을 시작할 준비가 되었지만 데이터 웨어하우스 또는 레이크하우스를 빌드할지 결정해야 합니다. 이전 테이블의 세부 정보를 검토한 후 기본 의사 결정 지점은 사용 가능한 기술 집합 및 다중 테이블 트랜잭션의 필요성입니다.
Susan은 관계형 데이터베이스 엔진에서 데이터 웨어하우스를 빌드하는 데 수년을 보냈으며 SQL 구문 및 기능에 익숙합니다. 더 큰 팀을 고려할 때 이 데이터의 주요 소비자는 SQL 및 SQL 분석 도구에도 능숙합니다. Susan은 팀이 주로 T-SQL과 상호 작용하면서 동시에 조직의 Spark 사용자가 데이터에 액세스할 수 있는 데이터 웨어하우스를 사용하기로 결정합니다.
Susan은 레이크하우스 SQL 분석 엔드포인트를 사용하여 새 레이크하우스를 만들고 데이터 웨어하우스 기능에 액세스합니다. Fabric 포털을 사용하여 외부 데이터 테이블에 대한 바로 가기를 만들어 /Tables 폴더에 배치합니다. 이제 Susan은 바로 가기를 참조하는 T-SQL 쿼리를 작성하여 레이크하우스에서 Delta Lake 데이터를 쿼리할 수 있습니다. 바로 가기는 SQL 분석 엔드포인트에 테이블로 자동으로 표시되며 세 부분으로 구성된 이름을 사용하여 T-SQL로 쿼리할 수 있습니다.
시나리오 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의 빠른 직접 쿼리 모드를 비롯한 고급 분석 기능으로 인해 이벤트 하우스를 사용하기로 결정했습니다. Power BI 및 KQL로 쿼리를 실행하여 현재 기간과 이전 기간을 비교하거나, 새로운 문제를 신속하게 식별하거나, 육상 및 해상 경로의 지리적 공간 분석을 제공할 수 있습니다.