해결된 질문
작성
·
99
·
수정됨
0
안녕하세요. 아래 코드를 작성하고 돌려보니 아래와 같이 결과가 나옵니다.
SELECT trainer_id, pokemon_id, status,
COUNTIF(status = 'Released'),
COUNT(pokemon_id)
FROM basic.trainer_pokemon
WHERE trainer_id = 17
GROUP BY trainer_id, pokemon_id, status
즉 예상되는 COUNTIF() 함수의 결과는 3,
COUNT() 함수의 결과는 12 입니다.
그러나 아래와 같은 코드를 돌려 집계한 결과, 다른 결과가 나옵니다.
SELECT trainer_id,
COUNTIF(status = 'Released'),
COUNT(pokemon_id)
FROM basic.trainer_pokemon
WHERE trainer_id = 17
GROUP BY trainer_id
;
왜 이런 문제가 발생하는지 모르겠습니다 ㅠ
답변 3
0
와; 늦은시간에 빠른답변 감사드립니다.
id 같은 고유값을 같이 넣어주시면 더 좋아요 < 너무 꿀팁인 것 같습니다!
한가지 더 여쭈어보고 싶은게 있습니다.
카일님이 작성해주신 코드와 동일코드로 결과를 돌렸을 때 결과 비교입니다.
(제가 작성한 코드)
SELECT
trainer_id,
COUNTIF(status LIKE 'Released') AS released_cnt,
COUNT(pokemon_id) AS pokemon_cnt,
COUNTIF(status LIKE 'Released') / COUNT(pokemon_id) AS released_ratio
FROM basic.trainer_pokemon
GROUP BY trainer_id
HAVING released_ratio >= 0.2
(카일님이 작성해주신 코드)
아래 사진은 카일님 동영상에 보인 결과입니다.
하지만 제 결과와 카일님 결과와의 차이점은, ORDER BY도 안했는데 행의 순서가 다르다는 것입니다.
첫행의 trainer_id의 9가 하단으로 내려가있고, 나머지 값들의 순서는 88, 8,4, 64, 66.. 로 같다가 뒤에 또 순서가 달라집니다.
(아래 사진은 제 결과입니다.)
전체 행 갯수도 26개로 맞고, 우연히 행 갯수만 맞은 걸까봐 영상속 결과와 제 결과 또한 비교했으나 같았습니다.
ORDER BY도 안했고, 왜 같은 코드를 돌렸는데 테이블 내 행 순서가 다르게 나오는 이유가 궁금합니다!
0
안녕하세요. 작성자 입니다.
SELECT trainer_id, pokemon_id, status
FROM basic.trainer_pokemon
WHERE trainer_id = 17
위 코드로 돌리니 아래와 같이 정상적으로 나오는 것을 확인했습니다.
GROUP BY 로 묶이는 변수들끼리의 중복을 제외해서 발생한 문제 인 것 같은데 맞을까요?
이렇게 groupby 문으로 카운트 검증을 할때, groupby를 제외한 변수들로 결과를 가늠해보는 방법 밖에 없을까요? 질문드립니다!
넵 맞습니다. 보통 PK로 자주 쓰이는 고유값인 id만 추가하셨으면 중복이라고 판단되지 않았을 거에요. id라는 것이 주민등록번호랑 비슷한 느낌이라고 보시면 됩니다
0
안녕하세요.
이런 경우엔 데이터를 확인해보는 것이 필요합니다. 내가 알고 있었던 데이터가 다를 수 있다는 촉이 오게 되는 부분입니다.
SELECT
id,
trainer_id,
pokemon_id,
level,
status
FROM basic.trainer_pokemon
WHERE trainer_id = 17
ORDER BY pokemon_id
위 쿼리를 실행해서 보시면 한 포켓몬 트레이너가 같은 포켓몬을 2마리 가지고 있습니다. 레벨만 다르고, status도 동일합니다.
그래서 아래 쿼리에선 4가 나온 것입니다. 이런 경우에 데이터를 더 잘 확인하는 습관을 가지시면 좋겠다고 생각해서 데이터를 만들 때 의도적으로 넣은 부분인데 이걸 캐치하셨네요!
위 쿼리에선 GROUP BY를 하면서 중복값이 제거되어서 저렇게 보이는거고, 더 정확하게 하고 싶다면 id 같은 고유값을 같이 넣어주시면 더 좋아요
위 쿼리 : trainer_id + pokemon_id + status로 집계(위에서 말씀드린 포켓몬 중복으로 처리되어 삭제됨)
아래 쿼리 : trainer_id로 집계하면서 status가 Released인 값을 COUNT => 4개 있음
빅쿼리의 특징 때문에 그렇습니다.
분산 처리 아키텍처: BigQuery는 대규모 분산 시스템으로, 쿼리가 여러 서버와 슬롯에서 병렬로 처리됩니다. 같은 쿼리라도 실행될 때마다 다른 컴퓨팅 리소스에 할당됩니다
데이터 스토리지 방식: BigQuery의 Colossus 파일 시스템은 데이터를 여러 청크로 나누어 저장합니다. 데이터에 접근하는 순서는 실행 시점의 시스템 상태에 따라 달라집니다
실행 계획 최적화: BigQuery는 쿼리 성능을 최적화하기 위해 실행 계획을 동적으로 조정합니다. 이 과정에서 데이터 처리 순서가 변경될 수 있습니다.
캐싱: 이전에 실행된 쿼리 결과가 캐시되어 있다면, 새로운 쿼리 실행 시 다른 경로로 데이터를 가져올 수 있습니다.
내부 구조까지 알면서 실행할 필요가 없어서 위 내용을 강의에서 전달하진 않았고, BigQuery에선 SELECT 쿼리를 실행할 때 순서를 보장하지 않는다라고만 기억하셔도 될 것 같습니다.
BigQuery에서는 SELECT문에서 자동으로 정렬해서 제공하지 않고, 순서 보장을 하지 않습니다. 순서 보장이 필요할 경우 ORDER BY를 사용하면 됩니다