데이터 엔지니어를 위한 97가지 조언
크고 작은 데이터를 관리하기 위한 강력한 실제 모법 사례와 다양한 핵심 원칙을 담은 책
목차
차례 | 조언 | 차례 | 조언 |
1 | 서점 재고관리 시스템으로 알아보는 최종 일관성 | 51 | 상당수의 데이터 문제는 빅데이터 없이 풀 수 있다 |
2 | A/B 테스트, 어떻게 해야 할까? | 52 | 소프트웨어 엔지니어링에서 데이터 엔지니어링으로 전환하기 |
3 | 스토리지 계층에 대하여 | 53 | 데이터 엔지니어를 위한 관측 가능성 |
4 | 분석: 마이크로서비스 아키텍처의 숨겨집 접착제 | 54 | 완벽함은 적절함의 적이다 |
5 | 인프라스트럭처를 자동화하라 | 55 | 파이프의 꿈 |
6 | 파이프라인 테스트를 자동화하라 | 56 | 데이터 레이크의 지옥이 되지 않으려면 |
7 | 데이터 파이프라인의 배치 모델을 신중히 검토하라 | 57 | 메시징 시스템에서 사용자 경험의 우선순위 높이기 |
8 | 은탄환 신드롬을 경계하라 | 58 | 개인 정보 보호 문제는 남의 일이 아니다 |
9 | 데이터 엔지니어 경력 쌓기 | 59 | QA의 대한 흥미로운 사실 |
10 | 데이터 파이프라인을 보여주는 비즈니스 대시보드 | 60 | 데이터 엔지니어가 머신 러닝 프로젝트에 관여할 때 주의할 7가지 사항 |
11 | 주의: 데이터 과학 프로젝트가 벌거벗은 임금님 이야기가 되지 않으려면 | 61 | 분석용 데이터 웨어하우스 선택을 보는 6가지 관점 |
12 | 변경 데이터 캡쳐 | 62 | 빅데이터 세상의 작은 파일 |
13 | 계약으로 기능하는 컬럼 이름 | 63 | 스트리밍은 배치와 다르다 |
14 | 합의된 개인 정보 보호 데이터 수집 | 64 | 늦게 도달하는 데이터 |
15 | 데이터 소비자의 원활한 업무 관계를 구축하라 | 65 | 데이터 프로젝트를 성공시키려면 기술이 뒤로 물러서야 한다 |
16 | 데이터 엔지니어링은 스파크와 같지 않다 | 66 | 데이터 엔지니어링 프로젝트에서 필수적으로 확인해야 하는 10가지 |
17 | 자율성 및 신속한 혁신을 돕는 데이터 엔지니어링 | 67 | 데이터 파이프라인의 관건은 속도가 아니다 |
18 | 데이터 과학자 관점에서 보는 데이터 엔지니어링 | 68 | 데이터 엔지니어링의 할 일과 하면 안 되는 일 |
19 | 재사용 및 확장 가능한 코드를 만드는 데이터 파이프라인 디자인 패턴 | 69 | 모두가 아는 ETL의 종말 |
20 | 데이터 엔지니어를 위한 데이터 품질 | 70 | 시조 작정 방식으로 소프트웨어 작성하기 |
21 | 데이터 엔지니어를 위한 데이터 보안 | 71 | 데이터 입출력에 숨어 있는 비용 |
22 | 요약 통계 이상의 데이터 유효성 검증 | 72 | 독점 소프트웨어와 오픈 소스가 전쟁 중이라는 거짓말 |
23 | 과거에도 현재에도 미래에도 존재하는 데이터 웨어하우스 | 73 | CAP 정리의 영향 |
24 | 로그 중심 아키텍처에서의 메세지 정의 및 관리 방식 | 74 | 데이터 계보의 중요성 |
25 | 데이터 생성 과정 정보를 파악해서 파이프라인을 이해하기 쉽게 하라 | 75 | 데이터 누락이 갖는 여러 가지 의미 |
26 | 코드뿐만 아니라 커뮤니티를 개발하라 | 76 | 경력을 망치는 한 문장 |
27 | 클라우드 세상의 효율적인 데이터 엔지니어링 | 77 | 데이터 품질 테스트에 오픈 소스를 사용하여 얻은 3가지 이점 |
28 | 데이터 레이크 아키텍처를 받아들여라 | 78 | 데이터 엔지니어링에서 중요한 3R |
29 | 데이터 사일로를 받아들여라 | 79 | 두 부류의 데이터 엔지니어링과 데이터 엔지니어 |
30 | 재현 가능한 데이터 과학 프로젝트 엔지니어링 | 80 | 빅데이터 확장성의 음양 |
31 | 안정적인 데이터 처리를 위한 5가지 모범 사례 | 81 | 데이터 프로세싱에서의 스레드 사용 및 동시성 |
32 | 유지 보수에 집중하고 ETL 작업을 분리하라 | 82 | 분산 프로그래밍에서 중요한 개념 3가지 |
33 | 동료에게 이중 기록을 권하지마라 | 83 | 의미론적인 시간은 기다려주지 않는다 |
34 | 기본 지식 | 84 | 도구가 아니라 패턴과 관행이 중요하다 |
35 | 구조화를 SQL로 되돌리기 | 85 | 총 소유 기회비용 |
36 | 데이터 프로덕트에 잠재적인 문서를 포함한 프런트엔드를 제공하라 | 86 | 가지각색의 데이터 도메인에서 문제를 해결하는 방법 |
37 | 데이터 파이프라인의 진화 | 87 | 데이터 엔지니어란 어떤 직종인가? 힌트: 데이터 과학의 조력자 |
38 | 제품처럼 데이터 플랫폼을 구축하는 방법 | 88 | 데이터 메시와 메시를 망치지 않을 방법 |
39 | 데이터 반란을 방지하는 방법 | 89 | 빅데이터란 무엇인가? |
40 | 관리하는 데이터의 바이트당 가격을 파악하라 | 90 | 인정받지 못할 때 해야 할 일 |
41 | 처리 지연 속도를 의식하라 | 91 | 데이터 과학 팀이 가치를 창출하지 못했다면 |
42 | RDBMS와 다른 NoSQL 데이터베이스 사용법을 배워라 | 92 | 잘 모르면서 대충 접근하지 말아야 하는 경우 |
43 | 로봇을 이용해서 규칙을 강제하라 | 93 | 데이터 공유에 주의해야 하는 경우 |
44 | 사용자 의견을 듣되 지나치게 따르지 마라 | 94 | 발언할 때와 경청할 때 |
45 | 저가형 센서와 데이터 품질 | 95 | 데이터 과학 팀에 전문가 대신 재너럴리스트가 필요한 이유 |
46 | 기계 동작 방식에 대한 공감력을 유지하라 | 96 | 엄청난 데이터에 따르는 엄청난 책임 |
47 | 데이터 그 이상의 메타데이터 | 97 | 데이터 검증 실패! 그 다음은? |
48 | 데이터 플랫폼의 핵심 요소인 메타데이터 서비스 | ||
49 | 데이터 레이크는 ACID를 제공하지 않으므로 조심하라 | ||
50 | 모던 데이터 스택을 위한 모던 메타데이터 |
위의 목차와 같이 총 97가지의 조언으로 구성되어있다.
보통 책들이 장문의 내용으로 길게 나열되지만, 이 책은 책의 제목과 동일하게 조언으로 이루어져있다.
조언이라서 길어야지 한 장 정도를 차지하기에 저자가 전하고자 하는 의미를 바로 알 수 있다.
소설책과 같이 이어지는 내용이 아니라서, 중간에 쉬면서 틈틈이 읽을 수 있는 책이다.
08. 은탄환 신드롬을 경계하라 - 토마스 닐드(Thomas Nield)
📙 내용
- 데이터 엔지니어링 및 분석 분야에서 열정적인 사람은 강력하게 특정 플랫폼을 지지하곤 합니다.
- 그러나 대부분은 단순히 도구에 대한 열정 때문에, 혹은 도구를 중심으로 직업적 정체성을 구축했기 때문에 해당 도구를 열렬히 지지하는 경우가 많았습니다.
- 도구와 애플리케이션은 나왔다가도 금세 사라지며, 오늘 인기 있던 것이 내일은 사용되지 않을 수도 있습니다.
- 직업적 정체성을 잠깐의 기술과 도구가 아니라 스스로의 기량, 문제 해결, 적응력에 두세요.
👩💻 이 부분이 와닿았던 이유는 데이터 엔지니어로 이직을 준비하면서 아파치, 하둡 등의 여러 플랫폼에 대해서 생각이 많았기 때문이다. 아직 이러한 도구들을 애플리케이션을 다 사용해보지 못했는데 뒤떨어지는게 아닐까라는 생각이 들었지만, 저자의 말과 같이 잠깐의 기술과 도구가 아닌 여태까지 내가 쌓아온 문제 해결 능력과 적응력 등의 나의 능력에 더 집중할 수 있는 좋은 조언이 되었다.
31. 안정적인 데이터 처리를 위한 5가지 모범 사례 - 크리스티안 라우어(Christian Lauer)
📙 내용
1️⃣ 오류를 방지하라
- 작업이 오류로 중단되면 모든 변경 사항을 되돌려야 한다 = SQL 롤백
2️⃣ 타당한 처리 시간을 설정하라
- N개의 데이터 행을 처리하는데 걸리는 시간에 대해서 알고 있어야, 실행 시간 오류 등에서 시간을 설정할 수 있다.
3️⃣ 데이터 품질 측정 작업을 사용하라
- 데이터 품질을 측정하고 신속하게 오류를 감지해야 소비자의 신뢰를 받는다.
4️⃣ 트랜잭션 보안을 보장하라
- 모니터링을 추가하거나 프로세스에 속하는 구성 요소가 너무 많으면 분배하는 편이 좋다.
5️⃣ 다른 시스템에서 갖는 의존성을 고려하라
- 가용성, 높은 데이터 부하, 다른 시스템의 반갑지 않은 동작들을 고려해야 한다.
👩💻 프로젝트를 진행하다보면, 데이터와 무조건 직면하게 된다. 데이터가 없이는 프로젝트를 진행할 수 없으니 말이다. 가져온 데이터를 어떻게 잘 처리하는 것이 프로젝트의 품질을 좌우하는 것이 사실이다. 데이터 처리를 위한 5가지의 모범 사례들은 정말 프로젝트에서도 무조건 생각하고 넘어가야하는 당연하고 중요한 부분들을 설명하고 있어서 와닿았다.
52. 소프트웨어 엔지니어링에서 데이터 엔지니어링으로 전환하기 - 존 살리나스(John Salinas)
📙 내용
데이터 엔지니어링에서 중요한 점은 소프트웨어 엔지니어링과 같습니다.
추상화를 이용하거나, 단순함을 추구하거나, 확장 및 유지 보수가 쉽도록 애플리케이션을 구축해야 하는 등 소프트웨어 엔지니어링과 동일한 원칙이 적용된다.
데이터 엔지니어링을 사용하면 소프트웨어 엔지니어링과 유사한 문제를 더 큰 규모로 해결할 수 있습니다.
👩💻 데이터 엔지니어링으로 전환해보고 싶어서 공부를 하는 나에게 해주는 조언이었다. 막상 눈앞에 직면하니 배울 것들도 더 많아보이고 처리할 문제들도 더 큰 규모다 보니 작아지는 기분이 들었다. 하지만, 현재 해왔던 일들과 동일한 일처리에 내용만 변경된 것이라고 생각하니 조금 더 생각하기 쉬워졌다. 데이터 엔지니어링을 시작하고자 하는 이들이 참고할 만한 좋은 조언이다.
71. 데이터 입출력에 숨어 있는 비용 - 로힛 비치야레누(Lohit VijayRenu)
📙 내용
1️⃣ 데이터 압축
- 압축 알고리즘을 고를 때는 항상 압축 속도 대 압축 비율을 고려해야 한다.
- 데이터의 양이 많다면 압축 해제가 빠른 알고리즘을 선택하고, 그 대신 더 많은 리소스를 사용하는 것을 감수하는 편이 효과적이다.
2️⃣ 데이터 형식
- 효율적인 데이터 쓰기와 데이터 검색 작업을 위해서는 필드를 여러 수준으로 중첩되게 만들 것인지, 아니면 모두 컬럼으로 바꿀 것인지를 고려애햐 합니다.
3️⃣ 데이터 직렬화
- 다양한 데이터 형식을 따르는 구조화된 데이터는 쓰는 중에는 직렬화되어야 하고, 다시 읽는 시점에서는 매번 역직렬화되어여 합니다.
- 데이터 엔지니어는 시간을 들여 데이터를 이해하고 애플리케이션을 프로파일링하여 숨겨진 입출력 비용을 분석애햐 합니다.
👩💻 업무에서 직접적으로 클라우드를 사용하는 일이 많다. GPU가 들어간 VM을 사용하니, 비용이 만만치 않게 나가서 비용에 대해서 예민해졌다. 빅데이터들을 운영하는 회사에서는 데이터 압축, 데이터 형식, 데이터 직렬화에 따라서 많은 비용의 차이가 발생하게 된다. 조그맣다고 생각할 수도 있지만, 빅데이터 안에서는 커다란 영향력을 행사할 수 있다. 때로는 그냥 넘어갈 데이터안에서도 숨겨진 비용들을 생각해볼 수 있는 계기가 되었다.
총평 🌻
이 책은 데이터 엔지니어 직무로 재직중인 사람, 데이터 엔지니어를 준비중인 사람 모두에게 추천한다.
실무에서 생각해보아야 하는 조언과 꿀팁들이 들어가있어서 일을 하면서 다시 되돌아볼 수 있게 해주며, 데이터 엔지니어링의 일상을 공유하여 데이터 엔지니어를 준비하는 사람에게는 데이터 엔지니어의 업무를 살짝 맛볼 수 있게 해준다.
또한 면접을 준비하고 있다면, 이 책에서 실무진들이 데이터 엔지니어링에서 중요하게 생각하는 부분들을 볼 수 있어서 준비하는데 훨씬 도움이 될 것이라고 생각한다.
데이터 엔지니어링과 연관되어 있는 모든 사람들이 읽어보면 데이터 엔지니어라는 직무를 이해할 수 있는 책이라고 생각한다.
※ 서평단 이벤트에 당첨되어 출판사로부터 책을 제공받아 작성한 글입니다.
'챱챱' 카테고리의 다른 글
[Ora2Pg] Ora2Pg 설치 및 실행하기 (0) | 2025.02.16 |
---|---|
[Airflow] Kubernetes에서 Airflow 설치하기 (0) | 2025.02.02 |
[챱챱] ML엔지니어 -> 데이터 엔지니어로 Change (0) | 2024.11.24 |
[Kubeflow] 나야 Kubeflow 2탄 (feat. Kubeflow 알아보기2) (3) | 2024.11.08 |
[글또] 글또 10기를 바라보며 다짐하는 것들 (1) | 2024.10.10 |