4주차 과제_크롤링을 통한 데이터 분석(피드백)

Review Analyzer

목적

이 노트는 연구원님이 나의 4주차 과제에 대한 피드백으로 새롭게 혼자 만드신것이다.

나는 연구원님의 github를 보며 나와 다른 방식 또는 관점을 보며 나에게 필요한 부분에 대한 피드백을 할 것이다.

Report

연구원님은 리포트 제일 위의 제목을 리뷰 분석기(Review Analyzer) 개발 프로젝트로 적으시며 이 프로젝트의 전체적인 틀을 제목으로 적어두셨다. 프로젝트명은 서울신라호텔 더 파크뷰의 네이버 리뷰 분석이며 이를 통해 어떠한 데이터를 분석할껀가에 대해 내포하고 있다.

연구원님은 크게 3개로 나누어 그 안에 요소를 집어 넣으셨다.

프로젝트 보고서

프로젝트 명

• 프로젝트 배경
• 프로젝트 목표

프로젝트 과정

1. 데이터 수집
2. 데이터 전처리
3. 데이터 탐색
4. 데이터 분석

결론

• References

• 프로젝트 명

  • 프로젝트 배경 : 배경에는 “내가 이 프로젝트가 필요한 이유”에 대해서 써야한다.

    • 연구원님은 “네이버 리뷰”를 써야하는 이유에 대해서 쓰셨다.

  • 프로젝트 목표 : 목표에는 내가 하고자 하는 분석에 대해서 써야한다.

    • 연구원님은 카테고리에 따른 긍/부정 분석
    • 설정한 카테고리 외에 추가적으로 나타나는 특징들이 있는 분석
    • 데이터를 보지 않아도 알 수 있는 호텔 뷔페에 대한 일반적인 반응 외에 알 수 있는 특징들에 대한 분석
    • 추후 원하는 URL에 맞게 리뷰를 분석할 수 있도록 기능을 확장할 예정
    • 연구원님은 추후에 추가할 기능에 대한 계획도 목표에 적어두셨다

• 프로젝트 과정

  1. 데이터 수집
     • 데이터 수집하신것에 대한 이미지 자료를 첨부하여 어떤 방식으로 수집했는지에 대한 것을 보여주고 있다.
     • 또한 네이버 리뷰 크롤링 모듈 개발(파일 이름) : 네이버 리뷰 URL, 목표 수집량을 입력하면 리뷰 데이터를 수집한다.와 같이 파일 이름과 그 파일의 작동 방식에 대한 설명을 통해 이해하기 쉽게 하고 있다.
     • 마지막으로 총 몇개의 데이터를 수집했는지도 적는다.
  2. 데이터 전처리
     • 데이터 탐색
       • 쓰지 않는 정보에 대한 코멘트와 이유를 달아주었다.
     • 전처리 과정
       • 내가 하지 않은 전처리 과정에 대해서만 쓰도록 하겠다.
       • 중복 제거
       • date열을 date와 weekday로 분리 (ex. 2024년 6월 7일 → 2024-06-07, 금요일)
     • 리뷰 형태소 분석
       • 어떠한 분석기를 사용하는지 이름과 이유를 적는다.
       • 제공하는 기능을 통해 분석한 것을 적는다. (ex.Kiwi에서 제공하는 stopwords 이용해서 불용어 제거)
       • 어떠한 품사를 분석에 사용했는지에 대한 언급을 하였다.(ex.`의미가 있다고 생각하는 체언(N), 용언(V)만 분석에 사용)
  3. 데이터 탐색
     • 분기별 리뷰 수 막대그래프 시각 자료를 통해 시기별 패턴 분석
     • 연도별 리뷰 수 막대그래프 시각 자료를 통해 특징을 적었다.(ex.2022년까지 계속 리뷰 수가 증가하다가 2023년에 다소 줄어듦)
     • 데이터 탐색을 통해 시각 자료들을 붙이고 막대 그래프의 색상을 변경하며 시각화가 더 잘되도록 하였다.
  4. 데이터 분석

연구원님의 주피터 노트북 파일을 보며 내가 추가하는 부분/필요한 부분을 기입하도록 하겠다.

1. Collect Data

연구원님은 처음에 Setting을 넣어 패키지들과 url(데이터 분석할 링크)을 다 적어 둔다.

연구원님은 순차적 개발, 최종 코드 정리 마지막으로 결과를 출력해본다.

1. 순차적 개발

• 페이지 접근
• 최신순으로 정렬
  • 이유: 추천순은 좋은 반응으로 편향될 가능성이 있다고 판단하여 최신순으로 정렬하는 과정 추가함
  • 리뷰글에 대해 봤을 때 정렬하는 방식에 대해서 고민을 하는 것도 좋은 방법이다.
• 댓글 더보기
  • 이유: “더보기 버튼을 눌러야 다음 댓글 생성됨”
  • 에러 발생시 에러에 대한 설명도 써놓는다.
• 코드 리팩토링
  • 코드 리팩토링에 대한 노트
  • 비효율적이라 판단되는 것에 대한 해결책 제시
  • 예시

- 계속 늘어나는 review를 for loop마다 불러와서 길이를 재는 것은 비효율적이라고 판단
- 처음 10개의 리뷰가 나타나고 [더 보기] 버튼을 누를 때마다 10개씩 늘어나는 것을 확인
- 반복 수를 계산한 후 그만큼 for loop를 돌리고자 함 rep = (target // 10) - 1
- 로딩 시간으로 인해 실제 [더 보기] 버튼이 눌러진 횟수가 달라질 수 있다.
- 이는 `_add_crawling()` 함수를 통해 추가 수집을 자동화해서 진행하려고 한다.

• 리뷰 추출하기
  • 연구원님은 리뷰 텍스트가 없으면 수집하지 않는 if문을 만들어 없는 텍스트들을 미리 걸러줬다.
  • 전처리하기 전 데이터를 수집하는 과정에서도 나에게 필요 없는 정보는 수집하지 않는 것이 좋다고 생각한다.
  • 데이터가 잘 받아졌는지 데이터 몇개만 출력해서 확인해보는 방법도 좋다.
    • 내가 원하는 데이터가 수집이 되었는지 확인이 필요하다.
• 데이터 프레임 만들기
• 저장

2. 최종 코드 정리

• 함수 모음
  • 만든 함수를 클래스에 집어 넣어 코드의 구조를 개선한다.
  • 클래스/함수를 만들고 Docstring을 통해 설명하는 것을 잊지 말아야 한다.
• 실행
  • 파일을 저장할 때 JSON형식으로 저장되어 있는 파일을 데이터프레임으로 만들어 csv파일에 저장했다면
    • JSON파일로도 저장을 해둔다. → 여러 형식으로 데이터를 나타낼 수 있다면 좋을 것이다.
  • 연구원님이 만드신 ReviewCrawler 클래스를 클래스 만들 때 한번씩 참고하면 좋을 거 같다.
  • 연구원님의 01_Collect_Data.ipynb
• 결과
  • 코드 실행 결과를 보여주고 이를 데이터프레임으로 만든 결과물까지 보여줬다.

2. Preprocessing

• Setting
  • 패키지받아주고 수집한 데이터를 가지고 온다.
  • 중복되는 데이터 제거 - drop_duplicates() Pandas 공식문서
    • 연구원님이 데이터프레임의 데이터들을 오름차순으로 하니 중복되는 것이 많아 추가하셨다고 하셨다.
    • 출력 확인용의 중요성

연구원님이 수집한 데이터 항목

• reviewer: 리뷰 작성자
• review: 리뷰 텍스트
• additional_info: “예약 후 이용”, “대기시간 바로 입장”, “데이트”, “연인/배우자”
• date: 방문 날짜
• n_visit: 방문 횟수
• auth_method: 결제 방식
• weekday: 방문 요일

1. additional_info

연구원님은 info()함수를 통해 결측치 값을 확인하셨다.

• 그 개수가 10분의 1이 되지 않았기에 분석에서 제외시켰다.

2. date

date는 날짜이기에 data type을 object에서 datetime으로 바꿔줘야 한다.

• 이때 편의를 위해 날짜와 요일을 두개의 열로 분리시켰다.

3. n_visit

재방문수이기 때문에 object에서 int로 변환

• 연구원님은 똑같은 날짜에 방문했는데도 n_visit만 다르고 내용이 똑같다는 것을 확인하셨다.
  • n_visit 변수를 지우고 중복 제거를 다시 실행

항목별로 데이터를 확인하며 데이터에 중복되는 점 또는 오류인 점을 찾아 고쳐야한다. - 난 항목별로 데이터를 확인을 안했다.

4. auth_method

전부 거의 같은 value값이라면 분석에서 제외하는 것도 방법이다.

• 대부분이 영수증이어서 분석에서 제외시키셨다.

5. review

연구원님은 데이터 전처리 과정을 이러한 순서로 하셨다.

1. 필요 없는 문자 제거
2. 맞춤법 검사기
3. 띄어쓰기 교정
4. 길이 탐색

1. 필요없는 문자 제거

• 정규 표현식을 이용하여 문자 제거
  • r"\r\n" : 개행문자, 줄바꿈 제거
  • r"[^가-힣a-zA-Z0-9 ]": 한글, 영어, 숫자를 제외한 나머지
• 제거된 문자들 속에서 아무것도 남지 않은 리뷰글은 삭제

2. Pyhaspell - 맞춤법 검사기

연구원님은 리뷰의 경우에 맞춤법 파괴가 일어나는 경우가 많이 없다는 것을 확인하셨다.

• 맞춤법 검사기의 필요성에 대해 이유
  • 외래어 표기 차이(ex. “뷔페”, “부페”)
  • 띄어쓰기 오류
• Pyhanspell 사용 후기
  • 띄어쓰기 잘함
  • 신조어의 경우 의미를 잃어버림(존맛 → 존 만)
• 결론
  • 신조어의 의미를 잃어버린다는 것이 큰 오류라고 생각해서 사용을 안하셨다.

Pyhaspell을 사용하여 문장들의 맞춤법을 교정하는 예제를 만들어 놓아 사용을 안하는 이유를 잘보여주셨다.

전처리방법을 사용하지 않는다면 사용하지 않는 이유에 대한 예시등을 보여주는 것도 좋은 방법이라 생각한다.

프로젝트를 평가할 때 쥬피터 노트북과 같은 세세한 과정을 많이 보시는 분은 없다. 하지만 맞춤법 검사기를 왜 사용하지 않았냐는 질문을 받게 된다면 이를 설명할 방법도 마련해놔야 한다.

3. Spacing - 띄어쓰기 교정

연구원님은 띄어쓰기 교정 라이브러리가 두 가지가 있어 비교하시고 사용하셨다. 두가지 라이브러리를 비교하는 과정을 보여주셔서 이 라이브러리를 쓸 이유와 쓰지 못할 이유를 보여주셨다.

• 띄어쓰기 교정에는 Pykospacing,soyspacing 라이브러리들이 있다.
• 비교 결과
  • 실행 시간 효율성: pykospacing(11.45 sec) < soyspacing(0.32 sec), 데이터셋 기준
  • 띄어쓰기 효과: pykospacing < soyspacing → Pykospacing이 어미부분에서 약하다는 결점
• 결론
  • 실행 시간이 빠르고 띄어쓰기 효과도 비교적 좋은 soyspacing을 선택

두가지 라이브러리 비교 데이터프레임을 만들어 위의 맞춤법 교정기와 같은 이유로 쓰고, 안쓰고 의 이유를 보여주셨다.

4. 길이 탐색 - 이상치 제거

• describe()함수를 통해 최소, 평균, 최대 문자열 길이 확인
• Box Plot과 Histogram을 통해 분포도를 시각화

연구원님은 댓글의 다양성을 확인하셨다.

• 문자열의 길이에 따라 언제부터 다양한 의견이 생기기 시작했는지 확인하셨다.
  • 여기선 6이다.

연구원님께서 댓글의 다양성을 확인하신 이유

• IQR방식을 통해 최소값을 구하셨는데 음수가 나오게 되어 직접 확인하시기로 하셨다.
• 원래 “굿”과 같은 리뷰글을 제외시키시려는 계획을 가지고 계셨다.
• 최소한의 리뷰 길이를 정하시는 기준을 댓글의 다양성으로 하신것이다.

전처리 데이터 저장

지금까지 전처리 해온 과정을 종합하여 분석에 이용되지 않는 열 제거 후 데이터 저장

데이터를 csv파일로 저장할 때, index=False라고 해야 Unnamed:를 없앨 수 있다. 그리고 index가 전처리 과정을 겪으며 순서가 띄엄띄엄 있게 되었으니 reset_index를 통해 인데스를 0부터 시작하게 한다.

결론

• 리포트에 쓸 내용을 여기서 작성하시고 옮기신거 같다.
• 결론에서 전처리 과정을 쓰며 라이브러리를 사용하지 않은 이유에 대해 간략히 쓰며 요약하신 느낌이다.

3. Tokenizing

토큰화는 형태소 분석을 하는 것이다.

1. 형태소 분석

연구원님은 불용어, 신조어, 가중치 등 여러 기능들이 포함되어 있는 Kiwi형태소 분석기를 선택하여 분석하셨다.

연구원님은 의미가 있다고 생각하는 체언(N), 용언(V)만 사용하실려고 한다.

• 체언(N): 문장에서 주어 따위의 기능을 하는 명사, 대명사, 수사를 통틀어 이르는 말
• 용언(V): 문장에서 서술어의 기능을 하는 동사, 형용사를 통틀어 이르는 말

이를 review, N,V로 나누어 데이터 프레임을 만들어 확인하기 쉽게 해놓으셨다.

전처리 데이터 저장

N과V를 pd.merge()를 통해 기존의 데이터프레임과 합쳐서 저장한다.

4. EDA, Exploratory Data Analysis

EDA설명 블로그

• EDA(탐색적 데이터 분석)
  • 요약 및 시각화 등을 통해 데이터를 이해하는 과정
  • 데이터를 분석하기 전에 그래프나 통계적인 방법으로 자료를 직관적으로 바라보는 과정
  • 필요한 이유
    • 데이터의 분포 및 값을 검토함으로써 데이터가 표현하는 현상을 다 이해하고, 데이터에 대한 잠재적인 문제를 발견할 수 있다.
    • 다양한 각도에서 살펴보는 과정을 통해 문제 정의단계에서 미쳐 발생하지 못했을 다양한 패턴을 발견하고 이를 바탕으로 기존의 가설을 수정하거나 새로운 가설을 세운다.

EDA같은 경우 통계에서는 필요한 과정이지만 지금과 같은 텍스트 데이터 분석에는 그렇게 필요한 과정은 아니다. 하지만 이러한 것이 있다, EDA라는 것이 무엇인지 알고만 있도록 한다.

1. 재방문에 대한 분석

• 의견이 크게 반전으로 달라지는 의견이 없다는 것을 확인하셨다.
• 재방문을 한 사람이 많지 않아서 일반화 하기에는 어려움이 있다.

2. 시기별 리뷰 분석

2019년부터 2024년까지의 리뷰를 모아 확인 하셨다.

• 색깔별로 막대그래프를 해두셔서 자료를 보는데 편하다.

월별 리뷰 수 / 분기별 리뷰 수 / 연도별 리뷰 수를 각각 막대그래프로 만들어 확인하셨다. 이를 통해 22년에 리뷰 활동이 가장 활발했으며 23년에 줄어들었다는 것을 확인하셨다.

3. 요일별 리뷰 분석

요일 항목을 value_counts()로 어떤 요일이 제일 방문율이 높은지 확인한다.

4. 워드 클라우드

연구원님은 워드 클라우드를 눈에 띄는 키워드를 찾는 목적으로 사용하셨다.

• 제외하신 내용
  • 가게 이름이나 리뷰 분석에 도움이 되지 않는 일반적인 단어들 제외
  • 빈도수가 1개인 경우 제외

빈도수가 1개인 경우를 제외하는 건 좋은 방법인거 같다. 이를 통해 워드 클라우드가 좀 더 보기 쉬워질거 같다.

1. 전체

전체 용언과 체언의 워드 클라우드를 만드셨다.

• 용언에서 크게 3가지로 나누셨다. (음식, 서비스, 환경(주차, 분위기 등))
  • 아마 음식에 디저트도 포함일거 같다.
• 체언에서는 대부분 긍정이나 소수의 의견이 보였다.(“달다”,“식다”,“비싸다)

워드 클라우드를 통해 보인 키워드를 실제 리뷰에서 검색해서 어떤 내용인지 확인한다.

2. 연도별

연도별로 비교하여 키워드를 통해 의견 비교를 하셨다.

• 22년과 23년의 의견은 대부분 동일한 것으로 보셨다.
• 하지만 겹치는게 많아서 차이를 확인하기 어려웠다.

3. 키워드 차이 비교

시기별 리뷰 분석에서 2022년도와 2023년도의 겹치는 키워드들을 빼고 겹치지 않은 키워드들로 비교하셨다.

• 시기별 리뷰 분석에서 22년에 가장 리뷰가 활발한 것으로 보였지만, 표현은 23년이 더 구체적인 것으로 보인다.
• 리뷰 반응 또한 22년보다 23년이 더 좋은 것 같다.

워드 클라우드를 통해 보인 키워드를 실제 리뷰에서 검색해서 어떤 내용인지 확인한다.

결론

EDA의 결론 부분에서는 EDA를 통해 알 수 있던 점에 대해 서술하시고 또한 아쉬웠던 점에 대해서도 서술 하셨다.

연구원님이 쓰신 EDA 결론

알 수 있는 정보

• 시기별 리뷰 수를 “리뷰 활동량”이라고 정의할 때, 리뷰 활동량은 22년까지 계속 증가하다가 23년에 줄어든 것으로 나타남.
• 평일보다는 주말에 리뷰 수가 더 많았으며, 주로 기념일, 생일과 같이 특별한 날에 방문한 것으로 보인다.
• 워드클라우드 분석 결과, 특정 음식에 대한 긍부정이 있었을 것으로 파악되며, 맛있었지만 비싼 가격에 대해 만족도가 떨어지는 것으로 보인다.
• 각 연도의 차집합 키워드들만 추출해봤을 때, 22년에는 주로 가족과 함께했지만, 23년에는 더 다양한 유형의 방문객이었을 걸로 예상된다.

아쉬운 점

• 용언과 체언을 분리해서 확인하다보니 용언에 대한 긍/부정을 정확하게 판단하기 어려웠다.
• 워드 클라우드만으로는 정확한 긍/부정에 대한 분석이 어려웠다.