IT 칼럼 - 데이터 품질(Naver D2)/Wanna Be 컴잘알

- 요약 -

 

데이터 비지니스 팀원의 룰 분류를 대략 5가지로 했을 경우

 

• Infrastructure Developer: 빅데이터 인프라 개발/운영
• Data Engineer: 데이터 파이프라인 개발/운영
• Data Scientist
  • Data Analyst: 인사이트 발굴
  • Statistician: 통계적 검증
  • Applied Machine Learning Engineer: 머신 러닝 응용 개발/운영

 AI 시대, 데이터 품질을 높이고 데이터 비즈니스 팀워크를 높이기 위한 체크포인트 몇 가지가 있습니다.

 

체크포인트 1: 가독성과 확장성 강화

 

널리 쓰일 데이터는 가독성과 확장성을 높여야 한다. 앱 간에 공유되는 데이터는 모두 널리 쓰일 가능성이 있다고 보아야 하므로, 데이터가 너무 크거나 복잡하지 않은 경우를 제외하고는 전부 가독성과 확장성에 신경을 써야한다는 결론이다.

 

성능, 확장성, 자기설명력(self-explanatory) 측면을 모두 만족하는 포맷(예: JSON)을 사용하는 것이 좋고 데이터의 내용이 데이터의 형식을 결정해야한다!!

 

체크포인트 2: 가능한 경우 테이블 형식으로 가공

 

'테이블 데이터(Table Data)'란 행/열로 구분하여 정리된 데이터를 말한다. 다차원 테이블도 가능하지만 여기서는 2차원만 취급한다. Data Scientist가 Dataset이라고 부르는 것들은 대부분 테이블 데이터이기 때문에, 모든 가능한 경우 데이터는 테이블 형태로 가공하는 것이 바람직하다.

 

Primitive 타입에는 담을 수 있는 정보의 양에 차이가 있다. Boolean < Integer < Double < String 순서로 담을 수 있는 정보가 커진다. 각 데이터의 열(column)에 담기는 데이터에 맞는 가장 작은 타입을 사용하는 것이 성능과 분석에 모두 이롭다.

 

체크포인트 3: 가능한 경우 통계적으로 깔끔(tidy)해지도록 가공

 

테이블 데이터가 깔끔하다는 것은 다음과 같은 특성을 가지고 있음을 의미한다.

 

• 각 행이 한 개의 관측치(observation)이다.
• 각 열 제목이 한 개의 변수(variable)이다.
• 변수는 더 쪼개거나 묶기 어려운 하나의 의미를 가진다.

 

 

위의 열을 보면 "m014= 남자이고 나이는 0~14살" 으로 표현하였는데, 두개의 기준이 묶여있는 것을 볼 수 있다. 또 전체적으로 m014, m1524등 관측치 기준으로 열이 구성되어있다.

이를 위에서 말한 세가지 특성을 기준으로 재구성시켜야 Tidy Data가 된다.

 

체크포인트 4: 데이터 문서를 '충분히' 작성

 

데이터가 가독성/확장성을 가지고, 테이블이며, 깔끔(tidy)하기까지 하다면 이미 그 데이터 자체에 대해서는 이미 상당 부분 설명되어 있다. 그러나 데이터 자체에 나타나는 것 외에도 문서화해야 할 것이 있다.

 

데이터 문서에는 다음과 같은 것이 포함되어야 한다.

• 데이터 내용: 변수의 의미 등
• 데이터 위치: HDFS path, HBase Zookeeper Quorum 등
• 데이터 생산자/관리자
• 데이터 사용자

여기에 더하여 다음과 같은 정보가 주어지면 더 좋다.

• 데이터 가용성: 생성 주기, 이력
• 데이터 통계: 크기, 개수 등
• 데이터 샘플

체크포인트 5: 데이터 문서화/공유 도구 활용

 

앞서 언급된 다양한 체크포인트를 데이터 팀 내에서 100% 지키기는 쉽지 않다. 특히 문서화의 경우는 처음에 그것들을 다 작성하는 것도, 변화에 따라 계속 유지보수하는 것도 어렵다. 데이터 문서화 및 공유 도구가 필요한 이유가 여기에 있다.

상용/오픈 소스로 데이터 관리 기능을 제공하는 소프트웨어는 Data Governance 툴이나 Metadata Registry 툴을 검색하면 찾을 수 있다. 네이버에서도 여러 가지 툴을 사용하는데, 그 중 Metadata Registry 용도로 자체 개발한 Meta-Pub이라는 툴을 소개하고자 한다.

 

 

- 후기 -

 

프로젝트를 진행할 때, 공공데이터 혹은 수집된 데이터를 사용하는 경우가 있을 텐데 데이터베이스 설계도 중요하지만 원래 본 데이터의 Structual가 매우 중요하다고 생각한다.

 

질 낮은 데이터를 가지고 질 높은 결과물을 만들 수 있을까? 그러기 매우매우 힘들다고 생각한다.

정보로서 가치가 있지만 정리가 되어있지 않는 데이터라면 질 높은 결과물을 만들 수 있겠지만 전처리 과정에서 개발기간의 지연이 생길 것 이다.

 

그럴 때마다 처음부터 Tidy한 데이터 SET을 만들었다면 얼마나 좋았을까? 쓰는 사람입장에서도 편하고 유지보수 하는 사람의 입장에서 편할텐데 말이다.

 

나중에 데이터를 생성하거나 생성된 데이터를 저장 시킬 일이 있다면 위의 체크포인트 5가지를 유의하여 Tidy한 데이터 SET생성과 형상관리를 신경써봐야겠다. 

 

 

출처 : https://d2.naver.com/helloworld/1179024