개발 이야기 거의 하는 방

AI 학습데이터에 활용할 데이터셋을 불러오는 중에 아래와 같은 에러가 발생했습니다.

Error opening file

Unexpected UTF-8 BOM (decode using utf-8-sig): line 1 column 1 (char 0)

Make sure /Users/kaflix_wanya/Desktop/current/카스캐닝 데이터셋/parts_labeling/0831_1996개_jpg+json/100210979526_576120.json is a valid label file.'

문제는 annotating, labeling 데이터를 저장하고 있는 json 파일을 불러오면서 발생한 에러인데요.

이 많은 json파일의 인코딩을 어떻게 바꿀까 고민하다가 파이썬 코드로 해결하였습니다.

데이터셋 경로를 불러와서 -> 데이터셋 경로 내의 모든 json 파일을 읽어온 후 -> UTF-8로 다시 인코딩 -> 변경된 인코딩형식으로 json파일 저장

위 순서대로 작업한 후 다시 labelme에서 'open dir'을 통해 학습데이터 경로를 불러오니 오류없이 잘 작동합니다.

아래는 코드입니다.

import os
import json

def convert_json_encoding(folder_path):
    # 주어진 폴더 내의 모든 파일에 대해 반복
    for filename in os.listdir(folder_path):
        filepath = os.path.join(folder_path, filename)
        
        # 파일이 JSON 파일인지 확인
        if filename.endswith('.json'):
            # JSON 파일을 UTF-8 인코딩으로 읽어들임
            with open(filepath, 'r', encoding='utf-8-sig') as file:
                data = json.load(file)
            
            # 같은 파일을 UTF-8 인코딩으로 다시 저장
            with open(filepath, 'w', encoding='utf-8') as file:
                json.dump(data, file, ensure_ascii=False, indent=4)

# 변경할 폴더 경로를 지정
folder_path = '/User/Dataset'

# 함수 호출
convert_json_encoding(folder_path)

oracle, bigquery만 주로 활용하다가 postgres를 사용할 일이 생겼습니다.

매우 반갑죠.

설치부터 시작하고 postgres에 대해 알아가야겠습니다.

설치

macOS환경에서 Docker로 설치합니다.

(Docker가 설치되어있다는 가정하에) 매우 간단해요.

docker pull postgress
docker run --name my-postgres-container -e POSTGRES_PASSWORD=1234 -p 5432:5432 -d postgres
docker exec -it my-postgres-container psql -U postgres

* POSTGRES_PASSWORD와 포트는 사용환경에 맞게 설정하시면 됩니다.

저는 테스트용이기에 1234로 작성했습니다

DB 접속

DBeaver를 실행하여 설치한 postgress DB에 접속이 잘 되는지 확인해보겠습니다.

접속이 잘 됩니다.

Bigquery Table → CSV file download-> Python Dataframe Read 과정에서 발생한 문제

파이썬으로 데이터 분석을 위해 빅쿼리 테이블을 csv로 받았습니다. (google.bigquery packages는 사용하지 않음)

연, 월, 일만을 갖고있는 Datetime을 나타내는 컬럼의 포맷을 변경하면서 발생한 문제입니다.

1. bigquery 테이블을 가져온 csv 파일 Read

위 컬럼을 yyyy-mm-dd 형태로 포맷을 변경할거죠

2. dt.strtime() 메소드 사용 → 에러 발생

dataframe_of_csv = pd.read_csv('bigquery_table.csv')
dataframe_of_csv["SEARCH_DATE"] =  dataframe_of_csv['SEARCH_DATE'].dt.strftime('%Y-%m-%d')

"AttributeError: Can only use .dt accessor with datetimelike values" 에러가 발생합니다

Can only use .dt accessor with datetimelike values는 .dt 접근자는 datetimelike 값에만 사용할 수 있다는 의미입니다. 즉, 해당 컬럼이 datetimelike 데이터 형식이 아니라서 발생한 오류입니다.

3. pd.to_datetime(dataframe['컬럼명']) 메소드 사용 → 해결

코드를 아래와 같이 수정하여 원하는 형태로 formmating을 할 수 있습니다.

dataframe_of_csv = pd.read_csv('bigquery_table.csv')
dataframe_of_csv['SEARCH_DATE'] = pd.to_datetime(dataframe_of_csv['SEARCH_DATE'])

결론

bigqeury, csv(file), python pandas(dataframe) 등 테이블 형태를 여러 방법으로 다루다보면 column의 데이터 형으로 인한 문제는 흔하게 발생합니다.

특히 Datetime의 경우 ETL과정에서 형식의 일치가 무엇보다 중요하죠

외부서비스에서 제공하는 데이터를 관리용 웹사이트를 이용중인 상황.

하지만 일괄적으로 입력할 데이터 양도 많고 input tag에 값을 일일이 넣을 경우 사이트가 느려지거나 여러 값들을 일일이 넣어줘야하는 번거로운 상황이 있었다.

1. Python requests와 BeautifulSoup4 package 이용

 데이터를 입력하고 submit할 때 호출하는 api와 payload(parameters)값들을 추출하였고 웹브라우저 상에서 테스트 시 정상적으로 작동하였지만 requests 패키지를 활용하여 api를 다루다보니 '세션'관련 문제가 발생하였다.

 form-data에 id와 pw를 입력하여 post로 전송하였으나 이 역시 마찬가지 였으며, headers의 세팅 또한 웹브라우저 환경과 동일하게 하였으나 마찬가지 였다.

2. python selenium 활용

입력할 값들을 미리 변수에 넣어서 selenium으로 자동화를 하려하였으나, 관리하는 데이터의 값들과 사이트 폼이 달라서 사실상 의미없는 작업이었다.

3. 세션유지를 위한 문제해결 방법!

결론적으로 requests를 활용하여 api를 호출하는 방법이 가장 효과적이었기에, 세션 유지를 하고자 1 + 2 방법을 혼용하였다.

최초엔 selenium으로 해당사이트에 로그인을 한 뒤, session 값을 가져와서 requests로 제어하니 원하던 작업을 진행할 수 있었다.

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.chrome.service import Service
from webdriver_manager.chrome import ChromeDriverManager
import time

driver = webdriver.Chrome(service= Service(ChromeDriverManager().install()))

url = "https://test.com"
driver.get(url)
time.sleep(5)


import requests
# 여기에서 로그인 작업을 수행
# 사용자명과 비밀번호 입력
username_element = driver.find_element(By.XPATH, '//*[@id="UserId"]')  # 사용자명 입력 필드
password_element = driver.find_element(By.XPATH, '//*[@id="UserPassword"]')  # 비밀번호 입력 필드

username_element.send_keys("id")
password_element.send_keys("password")

# 로그인 버튼 클릭
login_button = driver.find_element(By.XPATH, '//*[@id="myForm"]/button')  # 로그인 버튼 선택
login_button.click()



# Selenium을 사용하여 페이지 이동 및 추가 작업 수행

# 이제 requests를 사용하여 세션을 유지하면서 추가 요청을 보낼 수 있음
session = requests.Session()
# 필요한 추가 요청 설정, 세션에 쿠키 등을 추가
# 예를 들어, session.cookies.update(driver.get_cookies())를 사용하여 브라우저 쿠키를 세션에 추가

# requests를 사용하여 추가 요청을 보내거나 데이터를 추출
response = session.get("https://test.com/example/list")
response.text



# Selenium에서 세션 쿠키 가져오기
selenium_cookies = driver.get_cookies()

# requests 세션 초기화
session = requests.Session()

# Selenium에서 가져온 세션 쿠키를 requests 세션에 추가
for cookie in selenium_cookies:
    session.cookies.set(cookie['name'], cookie['value'])

# requests를 사용하여 추가 요청을 보냄
response = session.get("https://test.com/example/list")




# 요청을 보낼 URL
url = "https://test.com/api/sample"

# POST 요청에 사용할 데이터
data = {
    .........
}

response = session.post(url, data=data)

핵심은 마지막 줄 처럼 'requests.post()'가 아닌 'session.post()'로 호출한다는 점! 

url 호출에서 시작되는 일반적인 데이터 수집

실시간으로 변경되는 데이터이며, backfill 처리가 불가능한 수집 형태일 때.

1. url 호출 ➡️ 응답값(보통 json) ➡️ 전처리/가공 ➡️ Storage (DB, file ...)

 하나의 실행파일 안에서 자주 구축하던 형태였으나, 예외가 발생할 수 있는 좋지 않은 방식이다.

바로 '전처리' 단계에서 에러가 빈번하게 발생하게 된다.

 - (url의 host나 parameter들의 변경이 없다는 가정하에) respose 값이나 형태가 변경되는 경우

 - 전처리, 가공 후 storage에 저장하는 과정에서 발생하는 type 관련된 이슈

  위와 같은 상황은 꽤 흔하게 발생한다.

 문제는 바로 에러가 생길 때마다 강제로 형 변환(casting)을 해주거나 전처리나 가공하는 과정에서 변경된 'key:value'만 업데이트 해주었을 뿐 'raw data' 수준에서 생각하지 못하였던 것이었다.

 코드를 수정하는 과정에서 시간이 지체되면 수집 주기가 짧은 데이터의 경우 데이터를 수집하지 못하는 공백이 발생하게 되어 결국 데이터 손실이라는 치명적인 결과를 야기할 수 있다.

2. raw data를 저장하고 읽어와서 처리하는 파이프라인을 나눈다

파이프 라인이 늘어났다고 볼 수 있으나 안정성은 훨씬 좋아진 결과를 낳았다.

 응답값을 저장하기 전에 별도로 처리하지 않고 바로 저장하게 됨으로써 안정성과 더불어 '데이터 공백'이라는 결정적인 문제가 해결되었다.

기존의 전처리/가공 후에 데이터를 저장하는 과정에서 가장 흔하게 발생하였던 데이터 형 변환 관련된 이슈를 해결하기 위한 시간을 여유롭게 확보할 수가 있으며, 이러한 시간동안에 채우지 못한 데이터 backfill이 가능한 환경을 만든 것이라 할 수 있다.

3. 왜 '전처리/가공 ➡️ Storage (DB, file ...)'에서 형 변환 관련된 이슈가 빈번하다고 하는가?

 Storage라 묶었지만, DB(Oracle, Mssql, mysql 등)과 NAS나 서버의 저장공간, 클라우드 서버의 storage 등에 데이터를 파일 형태로 저장하면서 데이터 형식에 관한 이슈가 자주 발생하게 된다.

가장 대표적인 것은 'str, object, datetime 🔁 int(int64, float....)'로 변환하는 과정이다.

 dataframe으로 가공한 데이터를 DB Table에 insert, update 할 때 'Attribute'의 type에 맞지 않는 문제, bigquery도 마찬가지이며 dataframe을 parquet로 변환하는 과정에서도 자주 발생한다. 이럴 때에는 parquet보다 csv로 저장하면 '일다 저장'하는데 문제가 발생하지 않는다.

 저장하려는 공간마다 형태가 제각각이기 때문이다.

URL을 호출하여 수집하는 데이터 파이프라인 구축에 대한 결론은

• 먼저 Raw data를 '일단 수집'한다
• 가공/데이터 처리 단계를 수집단계와 별도로 분리한다
• Raw data는 가급적 txt나 json 형태 그대로 파일로 바로 저장하는 것이 좋으나, 수집주기가 짧고 많은 양의 데이터라면 Raw data를 바로 parquet, csv 등의 파일 형태로 변환하여 저장해준다.
• 양에 따라 데이터가 많으면 parquet, 적을 경우 json, csv 파일로 저장하는 것이 좋다.

json이나 txt 형태의 raw data를 바로 parquet로 변환할 때 가끔 에러가 발생하게 된다.

parquet 압축방식에서 발생하는 문제로 이 이슈는 다음에 자세히 다뤄볼 것이다.

데이터 엔지니어링 업무를 맡은지 1년이 훌쩍 지났지만 데이터 수집 과정의 파이프라인을 구축할 때마다 너무 '개발적인'부분에 시간을 할애한게 아닌가 라는 생각이 번뜩 들게 되었다.