일반적인 문제

  • 아티클

파워 쿼리

정렬 유지

데이터를 정렬하는 경우 모든 다운스트림 작업은 정렬 순서를 유지한다고 가정할 수 있습니다.

예를 들어 각 매장의 가장 큰 판매가 먼저 표시되도록 판매 테이블을 정렬하는 경우 "중복 제거" 작업을 수행하면 각 매장의 상위 판매만 반환될 수 있습니다. 그리고 이 작업은 실제로 작동하는 것처럼 보일 수 있습니다. 그러나 이 동작은 보장되지 않습니다.

파워 쿼리가 데이터 원본을 건너뛰거나 데이터 원본에 오프로드하는 등 특정 작업을 최적화하는 방식 때문에(고유한 순서 지정 동작이 있을 수 있음) 정렬 순서는 집계(예: Table.Group병합) 또는 중복 제거( Table.NestedJoin예: Table.Distinct중복 제거)를 통해 유지되지 않습니다.

이 작업을 해결하는 방법에는 여러 가지가 있습니다. 다음은 몇 가지 제안입니다.

  • 다운스트림 작업을 적용한 후 정렬을 수행합니다. 예를 들어 행을 그룹화할 때 추가 단계를 적용하기 전에 각 그룹에서 중첩 테이블을 정렬합니다. 다음은 이 방법을 보여 주는 몇 가지 샘플 M 코드입니다. Table.Group(Sales_SalesPerson, {"TerritoryID"}, {{"SortedRows", each Table.Sort(_, {"SalesYTD", Order.Descending})}})
  • 다운스트림 작업을 적용하기 전에 데이터를 버퍼링합니다(사용 Table.Buffer). 경우에 따라 이 작업을 수행하면 다운스트림 작업이 버퍼링된 정렬 순서를 유지합니다.
  • 순위를 사용합니다. 예를 들어 사용하는 대신 Table.Distinct중복 값이 포함된 열을 기준으로 정렬하고, 타이 브레이커 열(예: modified_date)을 기준으로 순위를 지정한 다음, 필터링하여 순위 1 행만 유지할 수 있습니다.

데이터 형식 유추

경우에 따라 파워 쿼리에서 열의 데이터 형식을 잘못 검색할 수 있습니다. 이는 파워 쿼리가 처음 200개 행의 데이터만 사용하여 데이터 형식을 유추하기 때문입니다. 처음 200개 행의 데이터가 행 200 이후의 데이터와 어떻게든 다른 경우 파워 쿼리에서 잘못된 형식을 선택할 수 있습니다. (잘못된 형식이 항상 오류를 생성하는 것은 아닙니다. 경우에 따라 결과 값이 단순히 잘못되어 문제를 감지하기가 더 어려워집니다.)

예를 들어 처음 200개 행(예: 모든 0)에 정수가 포함되어 있지만 행 200 이후의 소수 자릿수를 포함하는 열을 생각해 보십시오. 이 경우 파워 쿼리는 열의 데이터 형식을 정수(Int64.Type)로 유추합니다. 이 유추로 인해 정수가 아닌 숫자의 소수 부분이 잘립니다.

또는 처음 200개 행의 텍스트 날짜 값과 행 200 이후의 다른 종류의 텍스트 값이 포함된 열을 상상해 보십시오. 이 경우 파워 쿼리는 열의 데이터 형식을 Date로 유추합니다. 이 유추를 통해 날짜가 아닌 텍스트 값이 형식 변환 오류로 처리됩니다.

형식 검색은 처음 200개 행에서 작동하지만 데이터 프로파일링은 전체 데이터 집합에서 작동할 수 있으므로 데이터 프로파일링 기능을 사용하여 상위 N개 행을 넘어 오류(형식 검색 또는 기타 여러 가지 이유)에 대한 쿼리 편집기 초기 표시를 가져오는 것이 좋습니다.

원격 호스트에 의해 강제로 닫힌 연결

다양한 API에 연결할 때 다음 경고가 표시될 수 있습니다.

Data source error: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host

이 오류가 발생하면 네트워킹 문제일 가능성이 높습니다. 일반적으로 가장 먼저 확인해야 하는 사람은 연결하려는 데이터 원본의 소유자입니다. 연결을 닫는 사람이라고 생각하지 않는 경우 프록시 서버, 중간 라우터/게이트웨이 등과 같은 문제가 발생할 수 있습니다.

데이터만 재현하든 더 큰 데이터 크기로만 재현하든 경로 어딘가에 네트워크 시간 제한이 있을 수 있습니다. 더 큰 데이터만 있는 경우 고객은 데이터 원본 소유자와 상의하여 API가 페이징을 지원하는지 확인하여 요청을 더 작은 청크로 분할할 수 있도록 해야 합니다. 실패하면 API에서 데이터를 추출하는 다른 방법(다음 데이터 원본 모범 사례)을 따라야 합니다.

TLS RSA 암호 제품군은 더 이상 사용되지 않습니다.

2020년 10월 30일부터 다음 암호 제품군은 서버에서 사용되지 않습니다.

  • "TLS_RSA_WITH_AES_256_GCM_SHA384"
  • "TLS_RSA_WITH_AES_128_GCM_SHA256"
  • "TLS_RSA_WITH_AES_256_CBC_SHA256"
  • "TLS_RSA_WITH_AES_128_CBC_SHA256"

다음 목록은 지원되는 암호 그룹입니다.

  • "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
  • "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"
  • "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  • "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
  • "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"
  • "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384"
  • "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
  • "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"

암호 제품군은 메시지를 암호화하여 클라이언트/서버 및 기타 서버 간에 네트워크 연결을 보호하는 데 사용됩니다. 현재 보안 프로토콜을 준수하기 위해 위의 암호 그룹 목록을 제거합니다. 2021년 3월 1일부터 고객은 표준 암호 제품군만 사용할 수 있습니다.

다음은 연결하는 서버가 파워 쿼리 온라인 또는 Power BI에서 연결하기 위해 지원해야 하는 암호 그룹입니다.

파워 쿼리 데스크톱(Power BI, Excel)에서는 암호 그룹을 제어하지 않습니다. Power Platform(예: Power Platform 데이터 흐름) 또는 Power BI 서비스에 연결하려는 경우 OS에서 이러한 암호 그룹 중 하나를 사용하도록 설정해야 합니다. Windows 버전을 업그레이드하거나 Windows TLS 레지스트리를 업데이트하여 서버 엔드포인트가 이러한 암호 중 하나를 지원하는지 확인해 볼 수 있습니다.

서버가 보안 프로토콜을 준수하는지 확인하려면 TLS 암호 및 스캐너 도구를 사용하여 테스트를 수행할 수 있습니다. 한 가지 예는 SSLLABS일 수 있습니다.

고객은 2021년 3월 1일 이전에 서버를 업그레이드해야 합니다. TLS 암호 제품군 순서 구성에 대한 자세한 내용은 TLS 전송 계층 보안 관리(TLS)를 참조하십시오.

인증서 해지

예정된 버전의 Power BI Desktop은 SSL 체인의 인증서에 인증서 해지 상태가 누락된 경우 Desktop에서 SSL 연결이 실패합니다. 이는 해지 시 인증서가 명시적으로 해지된 경우에만 연결 오류가 발생하는 현재 상태의 변경 내용입니다. 다른 인증서 문제에는 잘못된 서명 및 인증서 만료가 포함될 수 있습니다.

회사 프록시 서버와 같이 해지 상태가 제거될 수 있는 구성이 있으므로 해지 정보가 없는 인증서를 무시하는 다른 옵션을 제공합니다. 이 옵션을 사용하면 특정 경우에 해지 정보가 제거되지만 보안을 완전히 낮추지 않으려는 경우 작업을 계속할 수 있습니다.

권장되지는 않지만 사용자는 해지 검사를 완전히 끌 수 있습니다.

오류: 평가가 취소되었습니다.

파워 쿼리는 백그라운드 분석을 사용하지 않도록 설정하면 "평가가 취소되었습니다"라는 메시지를 반환하고 쿼리를 새로 고치는 동안 사용자가 쿼리 간에 전환하거나 쿼리 편집기 닫습니다.

오류: 키가 테이블의 행과 일치하지 않음

파워 쿼리에서 키가 테이블의 행과 일치하지 않는 오류를 반환하는 데는 여러 가지 이유가 있습니다. 이 오류가 발생하면 매시업 엔진에서 검색할 테이블 이름을 찾을 수 없습니다. 이 오류가 발생할 수 있는 이유는 다음과 같습니다.

  • 테이블 이름이 변경되었습니다(예: 데이터 원본 자체).
  • 테이블에 액세스하는 데 사용되는 계정에는 테이블을 읽을 수 있는 충분한 권한이 없습니다.
  • 개인 클라우드 연결을 사용하는 경우 Power BI 서비스에서 지원되지 않는 단일 데이터 원본 에 대해 여러 자격 증명이 있을 수 있습니다. 예를 들어 데이터 원본이 클라우드 데이터 원본이고 여러 계정을 사용하여 서로 다른 자격 증명을 사용하여 동시에 데이터 원본에 액세스하는 경우 이 오류가 발생할 수 있습니다. 데이터 원본이 온-프레미스인 경우 온-프레미스 데이터 게이트웨이를 사용해야 합니다.

제한 사항: Windows 인증 사용하는 경우 게이트웨이 머신에 대한 도메인 가입 요구 사항

온-프레미스 게이트웨이에서 Windows 인증 사용하려면 게이트웨이 머신을 도메인에 가입해야 합니다. 이는 "게이트웨이를 통한 Windows 인증*로 설정된 모든 연결에 적용됩니다. 데이터 원본에 액세스하는 데 사용되는 Windows 계정은 Windows 디렉터리 및 게이트웨이 설치의 공유 구성 요소에 대한 읽기 액세스 권한이 필요할 수 있습니다.

제한 사항: 테넌트 간 OAuth2 새로 고침은 Power BI 서비스 지원되지 않습니다.

OAuth2를 사용하여 Power BI 서비스 데이터 원본에 연결하려면 데이터 원본이 Power BI 서비스 동일한 테넌트에 있어야 합니다. 현재 OAuth2에서는 다중 테넌트 연결 시나리오가 지원되지 않습니다.

제한 사항: 사용자 지정 AD FS 인증 엔드포인트는 Power BI 서비스 지원되지 않습니다.

사용자 지정 AD FS(Active Directory Federation Services) 인증 엔드포인트를 사용하는 기능은 Power BI 서비스 지원되지 않습니다. 사용자에게 다음 오류가 발생할 수 있습니다. 리소스에서 보고한 토큰 서비스를 신뢰할 수 없습니다.

제한 사항: 게스트 계정은 지원되지 않습니다.

테넌트의 게스트 계정을 사용하여 파워 쿼리 커넥터를 사용하여 데이터에 연결하는 것은 현재 지원되지 않습니다.

Expression.Error: 평가로 인해 스택 오버플로가 발생했으며 계속할 수 없습니다.

M 코드의 버그로 인해 스택 오버플로 오류가 발생할 수 있습니다. 예를 들어 다음 함수는 끝 조건 없이 반복적으로 다시 호출하기 때문에 스택 오버플로를 생성합니다. 이와 같이 자신을 호출하는 함수를 "재귀" 함수라고 합니다.

let f = (x) => @f(x + 1) in f(0)

M 코드에서 스택 오버플로를 해결하는 몇 가지 일반적인 방법은 다음과 같습니다.

  • 예상된 종료 조건에 도달하면 재귀 함수가 실제로 종료되는지 확인합니다.
  • 재귀를 반복으로 바꿉니다(예: List.Transform, List.Generate 또는 List.Accumulate와 같은 함수 사용).

Expression.Error: 평가에 메모리가 부족하여 계속할 수 없습니다.

"메모리 부족" 오류(또는 OOM)는 매우 큰 테이블에 대해 너무 많은 메모리 집약적 작업을 수행하여 발생할 수 있습니다. 예를 들어 다음 M 코드는 한 번에 10억 개의 행을 메모리에 로드하려고 하기 때문에 OOM을 생성합니다.

Table.Buffer(Table.FromList({1..1000000000}, Splitter.SplitByNothing()))

메모리 부족 오류를 해결하려면 정렬, 조인, 그룹화 및 고유 항목과 같은 메모리 집약적 작업을 원본으로 접도록 하거나 가능한 경우 모두 제거하여 최적화합니다. 예를 들어 정렬은 종종 필요하지 않습니다.

데이터 흐름

데이터 흐름 새로 고침 취소

데이터 흐름 새로 고침을 시작하는 경우도 있지만, 데이터 흐름 새로 고침을 시작한 후에는 데이터를 새로 고치기 전에 한 가지를 더 변경하고 싶다는 것을 알게 됩니다. 이 경우 새로 고침이 완료될 때까지 기다려야 합니다. 프로세스가 이미 데이터를 가져오고 작업 영역 또는 환경의 테이블 업데이트가 현재 지원되지 않으므로 중간에 새로 고침을 중지합니다.

향후 데이터 흐름 새로 고침 취소에 대한 지원을 추가할 계획입니다.