Microsoft Fabric 의사 결정 가이드: 데이터 저장소 선택
이 참조 가이드와 예제 시나리오를 사용하여 Microsoft Fabric 워크로드에 대한 데이터 저장소를 선택할 수 있습니다.
데이터 저장소 속성
이 표에서는 데이터 볼륨, 형식, 개발자 페르소나, 기술 집합, 작업을 기반으로 웨어하우스, 레이크하우스, Power BI 데이터마트 및 이벤트하우스와 같은 데이터 저장소를 비교합니다. 및 기타 기능
| 창고 | Lakehouse | Power BI Datamart | 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 데이터베이스, 레이크하우스 및 웨어하우스에서 쿼리 |
시나리오
패브릭에서 데이터 저장소를 선택하는 데 도움이 필요하면 이러한 시나리오를 검토하세요.
시나리오 1
전문 개발자인 Susan은 Microsoft Fabric의 새로운 기능입니다. 데이터 정리, 모델링 및 분석을 시작할 준비가 되었지만 데이터 웨어하우스 또는 레이크하우스를 빌드해야 합니다. 이전 테이블의 세부 정보를 검토한 후 기본 의사 결정 지점은 사용 가능한 기술 집합 및 다중 테이블 트랜잭션의 필요성입니다.
Susan은 관계형 데이터베이스 엔진에서 데이터 웨어하우스를 빌드하는 데 수년을 보냈으며 SQL 구문 및 기능에 익숙합니다. 더 큰 팀을 고려할 때 이 데이터의 기본 소비자는 SQL 및 SQL 분석 도구에도 능숙합니다. Susan은 팀이 주로 T-SQL과 상호 작용할 수 있는 데이터 웨어하우스를 사용하기로 결정하고 조직의 Spark 사용자가 데이터에 액세스할 수 있도록 허용합니다.
Susan은 레이크하우스 SQL 분석 엔드포인트를 사용하여 새 레이크하우스를 만들고 데이터 웨어하우스 기능에 액세스합니다. Fabric 포털을 사용하여 외부 데이터 테이블에 대한 바로 가기를 만들어 폴더에 /Tables 배치합니다. 이제 Susan은 바로 가기를 참조하는 T-SQL 쿼리를 작성하여 Lakehouse에서 Delta Lake 데이터를 쿼리할 수 있습니다. 바로 가기는 SQL 분석 엔드포인트에 테이블로 자동으로 표시되며 세 부분으로 구성된 이름을 사용하여 T-SQL로 쿼리할 수 있습니다.
시나리오 2
데이터 엔지니어인 Rob은 패브릭에 몇 테라바이트 단위의 데이터를 저장하고 모델링해야 합니다. 팀에는 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을 사용하여 쿼리를 실행하여 현재 기간과 이전 기간을 비교하거나, 새로운 문제를 신속하게 식별하거나, 육상 및 해상 경로의 지리적 공간 분석을 제공할 수 있습니다.