* 데이터 엔지니어 기술 면접 질문들에 대해 정리
* 자신의 이력서 기반된 질문이나, 데이터 엔지니어링&CS 에 관해 공통되는 질문들이 많기 때문에 회사별로 정리하진 않음
1. 자기 소개(or 커리어 패스)
게임 회사에서 총 7~8년 정도 경력
게임 서버를 하면서 웹서버나 디비같은 백엔드 전반적인 역량을 쌓았고,
레디스, 엘라스틱서치같은 nosql 경험
이후 데이터 엔지니어로 전향 및 다른 데이터 도메인에 적응
대용량, 비정형 데이터들을 다루기 위해
병렬, 분산, 배치 처리와 같은 개발이나 솔루션을 많이 사용
팀 작업의 히스토리 파악하는걸 중요시
그걸 기반으로 조직에 필요한 새로운 프로그램 개발이나
중요한 업무인데 우선순위가 높지 않아서 매번 밀리는 업무의
자동화 등 팀 전반적인 생산성에 도움이 되는 업무도 함
개발자, 비개발자, 타회사 등
다양한 사람들과 협업했던 경험들을 바탕으로
업무에서 크게 당황하지 않고
끌고 나갈 수 있는 성향, 역량을 가진
데이터 엔지니어라고 어필
=> 대체로 1분 내외로 자기 소개 분량. but, 자기소개에 주요 경력 사항을 포함하여 5분정도 말하라고 하는 경우도 있었음
면접의 시작이므로 크고 또박또박 말하는 것이 중요..
스크립트는 샘플이지만, 자신의 경력 요약 및 업무 방식이나 강점을 중심으로 한 워딩을 사용하였음
2. 나의 강점 or 나를 뽑아야 하는 이유?
=> 경력직이라 대비하지 않아서 초반 면접에 당황했었음. 은근히 물어보는 곳이 많음
=> 나열식으로 어필하였으나 좋은 답변은 아닌듯함
개발쪽에 강점이 있는 데이터 엔지니어.
데이터 파이프라인 밑바닥에서부터 구축한 경험,
웹서버나 로그 수집 시스템과 같은 다양한 시스템 개발 경험
ETL, 데이터웨어하우스, 마트와 같은 구축 경험
RDB, Nosql 경험, 클라우드 경험 등
대부분 직무 역량에 부합
3. 왜 이 회사로 이직하려는가?
=> 그 회사 정보 + 내 경력과 장점을 엮어서 어필함
------ 여기부터 기술 질문 ------
*Nosql?
-> 비관계형 데이터베이스.
-> 스키마가 없고, 키밸류 스토어, 도큐먼트, 그래프등 다양한 데이터 모델을 사용
-> 일반적으로 더 빠르다는데, 머신을 붙이기 더 쉬운편이라서 그런 말이 나오는거 같고,
일반적으론 특수한 기능 구현이라든가, 단순한 읽기/쓰기 작업을 통해
디비 앞 캐싱 용도로 쓰는거라고 생각한다.
스키마가 없어서 구조 변경이 쉬운편.
단점
조인같이 복잡한 쿼리 사용하기 어려움
스키마가 유연해서 구조상 데이터 밸류 관리가 어려움
*nosql rdb 비교
RDB 는 스키마, 테이블 구조 기반
Nosql 은 구조가 동적일 수 있음
ACID 비교.
확장성
RDB 는 머신 성능 업
Nosql 은 일반적으로 수평 확장(클러스터링)
RDB 에서 수평 확장하려면 수평 샤딩을 통해 로직적으로도 구현필요
일관성
RDB 는 ACID 지원
Nosql 은 ACID 를 완벽 지원 못한다고합니다.
쿼리
RDB 는 SQL 을 사용하므로 복잡한 쿼리 및 조인 연산 가능
Nosql 은 표준 쿼리가 없고, 복잡한 연산이 제한적일 수 있음
RDB는 테이블에 저장, 테이블 간에 관계 형성
Nosql 은 다양한 데이터 모델을 지원
RDB 는 복잡한 트랜잭션을 지원
RDB는 복잡한 쿼리, 트랜잭션이 필요한 경우에 적합
Nosql 은 대용량 데이터? 실시간 처리. 빠른 읽기 쓰기에 적합
*ACID?
데이터베이스 트랜잭션 관리의 주요 속성들
아토믹(원자성)
-> all or nothing
일관성(consistency)
-> 트랜잭션 전과 후에 데이터베이스가 일관된 상태 유지. 규칙에 대한 것. (스키마)
고립성(isolation)
-> 트랜잭션 사이에 독립적. 서로 영향을 주면 안됨
지속성(durability)
-> 트랜잭션이 성공적으로 된 후엔, 영구적으로 반영
*배포 방식 설명 (롤링, 블루그린, 카나리 AB, 등)
롤링
새 버전을 점진적으로 배포. 무중단 배포 가능하고, 배포 시점에 모든 서버가 동일한 버전이 아니며, 롤백이 복잡할 수 있음
블루그린
두개의 동일한 프로덕션 환경
새로운 버전은 그린 환경에 배포, 테스트후 트래픽을 그린으로 전환
즉각적인 롤백이 가능하고, 미리 전체 시스템을 테스트 가능
대신 인프라가 두배 필요함
카나리
새 버전을 일부 사용자에게만 먼저 제공
새 버전의 성능과 문제점을 평가 가능할 수 있고, 모든 사용자에게 영향을 주지 않고 대응 가능
대신 일부 사용자가 분안정한 버전을 경험할 수 있고, 모니터/로깅이 복잡할수 있음
AB
두개의 버전을 동시에 배포하여 어느게 더 효과적일지 테스트
* 배포 어떤식으로 했냐
하던 방식 설명함
=> 카피스트라노, 깃헙액션, 수동(서버가 많지 않은 경우)
* 실시간 스트리밍 로그를 받는다고 쳤을때 어떻게 구성할건지
기존에 구성했던 시스템 기반으로 설명하였음.
=> 각 컴포넌트별 채택 이유, 히스토리 설명, 성능 측정에 대한 내용
고민했던 부분들. 한계점, 개선 방안 등에 대한 추가 질문들이 있어서 대답하였음
* 클라우드의 장점 or 클라우드랑 온프레미스랑 뭘 더 선호하냐
클라우드
초기 비용이 싸고, 스케일링이 편함
유지보수가 상대적으로 쉬움
대신, 데이터가 외부에 있다는 보안 이슈
대규모 사용시 비용 많아짐.
어쩄든 커스터마이징이 필요할 경우 제약이 있을수 있음
온프레미스
내 맘대로 시스템 컨트롤 가능
대신, 초기 비용이 좀 들고, 유연성이 떨어지고, 유지보수도 전적으로해야함
=> 재미/학습 용도로는 온프레미스로 사용중이고, 엄청 많은 데이터를 다루는 기업들은 온프레미스가 유리하고,
그 외엔 클라우드가 좋다고 말함. 본인이 개인프로젝트로 서비스를 오픈한다고 가정했을때도 클라우드 쓸거라고함
*시니어 프로그래머로서의 경험이 있는지
내가 생각하는 시니어프로그래머의 기준은 전반적인 업무를 혼자 도맡아서 할 수 있는가. 이거다.
다른 프로그래머들과 설계를 논의하고 결론도 도출하는 경험.
대신, 시니어프로그래머는 모든걸 다 아는 프로그래라기보단.. 모르는걸 잘 알아내가는 역량이 좋아야한다고 생각.
추가로, 외부팀들과 커뮤니케이션 창구 역할도 해야하고,
주니어들 리딩도 가능한한 하였다.
* udf에 대해 아는지, 경험이 있는지
SQL 같은 쿼리 언어 안에는 UDF 를 사용하여 복잡한 쿼리 로직을 단순화 하거나 재사용할 수 있음
스파크나 하둡같은 데이터 처리 프레임웍에서도 UDF 를 통해 데이터 변환 작업을 사용자 정의로 수행 가능
거의 모든 프로그래밍 언어에서도 지원
장점은. 재사용이 가능하고,
복잡한 로직을 캡슐화해서 가독성을 높이고 유지보수를 쉽게 할 수 있음. 코드의 모듈화
단점은. 내장 함수보다 느릴 수 있고
디버깅을 빡세게 해야함. 최적화 및 안정화 이슈
=> 어플리케이션 레벨에서 간단한 udf 사용 경험뿐이라서 너무 국한된 대답을 하였음
SQL이나 라이브러리 단에서의 udf 처리 경험이나 상세 내용을 알면 좋을듯함
* 맵리듀스란?
대용량 데이터를 효율적으로 처리하기 위한 프로그래밍 모델,
하둡등 분산 컴퓨팅 시스템에서 널리 사용.
MAP + REDUCE 두가지 단계
맵단계
분산 파일 시스템에서 대용량 파일을 읽음
각 레코드 별로 연산 수행
연산 결과를 키값으로 출력
이 출력들을 모아서 키에 따라 정렬, 분류
리듀스 단계
위에 정렬된 키값을 입력으로 받음
동일한 키를 가진 값을 모아서 연산 수행
연산의 결과를 분산 파일 시스템에 저장
-> 데이터를 여러 노드에서 병렬로 처리해서 빠르다.
대신, 복잡해지고, 디버깅이 어려워진다.
*분산 파일 시스템에선 맵리듀스가 끝나면 파일이 써지고,
맵리듀스 시작땐 파일을 읽음
=> 대규모 데이터 분산 처리 솔루션들이 기반하는 방식인데 설명을 하려니 매끄럽게 설명할만큼 이해도가 높지 않았었음
* 클라우드에서 많이 써본 제품들? 어떤식으로 썼는지?
많이 썼던거 위주로 설명.
GCP 빅쿼리, 스토리지 등
AWS 아테나, S3 등
* 관심있거나 보고 있는 기술이 있는지?
경험상 외국계 회사에서 높은 빈도로 물어봄
=> 꼭 최신 기술이 아니더라도 조금이라도 관심 있던 내용을 말함
러스트가 좋다더라. 러스트에 대한 설명, 어떤 상황에서 러스트를 써봤다 정도
* 오픈 소스 컨트리뷰터 경험?
=> 아쉽게도 큰 프로젝트는 없었다. 작은 프로젝트만 있는데, 개발에 강점이 있다고 해서 물어본거 같은데 아쉬웠다
* 모니터링 경험? 했다면 어떤식으로 했는지, 모니터링에 관한 재밌는 에피소드?
=> 그라파나에 시스템 리소스, 클라우드 사용량등 패널을 관리하였다. 데이터 수집은 collecd, statsd 등을 이용하였고,
필요한 경우 알람이 오도록 하였다.
모니터링을 통해 "추세, 경향" 을 더 잘 볼 수 있었는데, 처리 시간이 점점 늘어가는 주요 프로그램을 개선하는 근거로 삼거나
클라우드 사용량(비용)을 절감하는 방향 모색, 외부에 보여주기 좋은 자료 등으로 사용했다
* 조인 설명
=> 관계형 디비에서 여러 테이블간의 관계를 맺는 방식이라고 함. inner, left, outter 등에 대한 설명
* 하둡?
=> 대규머 데이터 분산 처리 프레임워크
HDFS + 맵리듀스