개발 이야기 거의 하는 방

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년이 훌쩍 지났지만 데이터 수집 과정의 파이프라인을 구축할 때마다 너무 '개발적인'부분에 시간을 할애한게 아닌가 라는 생각이 번뜩 들게 되었다.