우리는 원격 측정 데이터가있는 크고 넓은 플랫 파일을 가지고 있습니다. 그들은 매일에 도착한다.스타 스키마, 서로 게이트 키
나는이 넓은 파일의 데이터로 채워질 스타 스키마을 ADLA DB에 만들 예정입니다. (ADLA DB 원시 ADLS 반대 기능을 많이 (제공 같은) 같습니다 인덱스, statisctics, 압축, 유통 관리를 ...) :
해시는 어떨까요? 어떤 기능을 구현하기 위해 사용할 수 있습니까? (저는 C#에 대해 생각하고 있습니다)
먼저 대용 키를 사용하려는 이유를 이해하고 싶습니다.
현재 U-SQL 테이블은 예상 쿼리 대부분을 미리 알고있는 배치 쿼리를 지원하기 위해 설계되었습니다. 따라서 배포 키와 스키마 (해시, 직접 해시, 범위) 및 클러스터 된 인덱스를 설계하여 가장 비싼 작업을 최적화하십시오.
예를 들어 데이터 스큐를 관리하기 위해 직접 해시를 사용해야하는 경우 대리 키를 사용하는 것이 좋지만 그렇지 않으면 파티션/배포 제거를 활용하기 위해 복잡성이 추가 될 수 있습니다.
자신의 해시 함수를 구현하는 데 C#에는 해시 함수가 내장되어 있거나 직접 작성할 수도 있습니다. 예 : C# Object.GetHashCode 방법.
우리는 원격 측정 시간대 데이터를 CSV에 저장했습니다. 이러한 CSV는 폭이 넓습니다 (많은 항목). 그들은 커질 것으로 예상되지만, (ADLA 엔진이 기대하는 것처럼) 1-4Gb 이내의 모든 크기를 제어 할 수 있습니다. 파티션, 배포판, 호환 가능한 조인/집계, statisctics 등의 기능을 사용하려면이 데이터를 ADLA DB에 점진적으로로드하고 싶습니다. 또한이 데이터는 매우 중복되고 넓습니다 (많은 열). 모든 주요 쿼리에 대한 호환성으로 조인/그룹을 달성하기 위해 플랫 와이드 테이블에 대해 단일 배포 스키마를 만드는 것은 불가능합니다. 플랫 스키마를 스타 스키마로 분해하려고합니다. – churupaha
이 경우 우리는 몇 가지 Dim 테이블을 공유 할 Fact 테이블을 갖게 될 것입니다. 이 팩트 테이블은 소스 플랫 테이블만큼 넓지는 않을 것이며 모든 구체적인 경우에 적절한 배포 스키마를 선택할 수 있습니다. 또한 데이터 세트의 크기가 감소해야합니다. 또한 이러한 사실 테이블은 큰 문자열 대신 정수에서 거의 모두 구성됩니다 (플랫 스키마 에서처럼). 집계에 이점을 주어야합니다 (적어도 Azure DWH의 경우 사실입니다). 스타 스키마를 구현하려면 DimTables의 서로 게이트 키를 생성하는 방법이 필요합니다. row_number 나 어떤 종류의 해싱을 사용할 수 있습니다. – churupaha
원본 데이터와 함께 comparsion에서 값 분포를 위반해서는 안됩니다. 왜냐하면 우리가 'Biiiiig string 1', 'Biiiiig string 1', 'Biiiiig string 1', 'Biiiiig string 2', 'Biiiiig string 3'값을 가진 열을 소스 플랫 테이블에 가지고 있다면, 그 변수들은 서로 게이트 정수 1, 1, 1, 2, 3 – churupaha
귀하의 질문에 대한 답변이 아닙니다. 그러나 ADL 테이블에서 USQL을 사용하여 현재 UPDATE 또는 DELETE 할 수 없다는 사실을 처리 할 필요가 있다고 제안 할 필요가 있다고 생각해보십시오. 재실행을 원한다면 더 많은 파티션을보아야 할 것입니다. –
예, 이해합니다. FactXXX 테이블에 대해 Date에 의한 파티셔닝을 사용할 것입니다. – churupaha