데이터 엔지니어를 위한 97가지 조언

13 계약으로 기능하는 컬럼 이름

 

에밀리 리더러(Emily Riederer)

소프트웨어 제품은 단위 테스트와 서비스 수준 규약을 통해 성능을 보장합니다. 인터페이스는 공통 기호와 레이블이 있지만, 데이터 테이블은 서비스처럼 엔지니어링되는 것도 아니고 애플리케이션처럼 디자인되는 것도 아닌, 그 사이 어딘가에 존재합니다. 생산자와 소비자 간에 대화도 없고 규약을 맺지도 않는 상황 때문에 엔지니어들은 사용자가 만족하지 못하는(아니면 애매하게 데이터 품질이 별로라고 불평하는) 이유를 몰라서 혼란스럽고, 소비자는 데이터가 그 정도로 올바르지 않은 이유를 몰라서 어리둥절합니다.

제한된 어휘만 사용해서 공개된 데이터셋의 필드에 이름을 붙이면 대단한 기술 없이도 이 딜레마를 부드럽게 해결할 수 있습니다. 공통된 언어를 개발하면 데이터셋 필드가 각기 동작하는 방식을 관계자가 모두 이해할 수 있으므로 데이터 유효성 검사와 문서화, 랭글링 작업에서 생산자가 갖는 부담을 줄일 수 있습니다.

엔지니어와 분석가는 원자적이고 의미를 잘 정의한 계층화된 스텁stub을 미리 정의할 수 있습니다. 이러한 스텁을 서로 결합시켜 복잡한 메트릭과 동작을 설명할 수 있습니다.

여러분이 승차 공유 서비스 회사 직원이고, 승차 횟수만큼 레코드가 있는 데이터 테이블을 만든다고 가정해보세요. ...