1.1.3 데이터 엔지니어의 진화
역사는 그대로 반복되지 않지만, 그 흐름은 분명 반복된다
(이거 너무 멋있는거 같아) 호홓
1980 ~ 2000년 까지 : 데이터 웨어 하우징에서 웹으로
데이터 엔지니어의 탄생은 1970년대 까지 거슬러 올라가는 데이터 웨어하우징에 뿌리를 둔다.
비지니스 데이터 웨어하우스 business data warehouse라는 용어는 1980년대에 형성 되었으며,
1989년에 이르러 빌 인먼이 데이터 웨어하우스 라는 용어를 공식적으로 만들었음
데이터 웨어하우징은 시장에 출시되는 대량의 데이터를 처리하고 전례 없는 막대한 양의 데이터를 지원하고자,
다수의 프로세서를 사용하는 새로운 대규모 병렬 처리(MPP[Massively Parallel Computer]) 그리고
데이터베이스로 확장성 있는 분석의 첫 시대를 열었음 데이터 웨어하우스와 BI 엔지니어링은 오늘날의 데이터 엔지니어링의 선구자였고
여전히 이 분야에서 중심적인 역할을 함
2000년대 초 : 현대 데이터 엔지니어링의 탄생
90년대 후반의 닷컴 열풍이 무너지고 작은 무리의 생존자들만 남겨지고 이러한 생존자 중 일부인 야후, 구글, 아마존과 같은 기업들은 강력한 기술 기업으로 성장함 처음에는 이들 기업이 1990년대의 전통적인 모놀리식 관계형 데이터베이스와 웨어하우스에 계속 의존하면서
그 시스템의 한계점 까지 몰아붙였다.하지만
1. 해당 시스템이 불안정해짐에 따라 [한번 시스템을 업그레이드 하거나 유지보수를 하면 모놀리틱이기 때문에 다 뜯어낼 수 밖에 없었음]
2. 데이터 증가를 처리할 [시간이 지남에 따라 데이터의 증가 와 데이터의 유입 경로 속도가 감당이 안되기 시작]
데이터의 폭발적인 증가와 함께 하드웨어가 발전함에 따라 저렴해지고 어디에서도 사용할 수 있게 되었음
그 중 컴퓨터 클러스터에서 분산 실행 및 저장을 실현함에 따라 모놀리틱에서 벗어났고 이른바 빅데이터 시대가 열리기 시작함
빅데이터는 3V
1. 속도 Velocity
2. 다양성 Variety
3. 크기 Volume
2003년 구글은 Google File System 에 관한 논문을 발표했고, 그 직후 야후에서 이 논문에 영감을 받아 Hadoop 을 개발하게 됨
이때 개발된 하둡의 영향력은 데이터 엔지니어링 전체에 영향을 미쳤음
사실상 데이터 엔지니어링 생태계는 하둡 생태계 이고 JVM이 꽉잡고 있다고 무방함
그로 인해 대규모 데이터 문제에 관심이 있는 엔지니어들은 이 새로운 오픈소스 기술 생태계 가능성을 주목함
2000년대와 2010년대 : 빅데이터 엔지니어링
Hadoop ecosystem의 오픈소스 빅데이터 도구는 빠르게 성숙했고, 실리콘벨리에서 전 세계의 최신기술에 정통한 기업들로 빠르게 확산
모든 기업이 처음으로 최고 수준의 기술 업체에서 사용하는 것과 동일한 데이터 도구에 접근할 수 있었음
이 계기가 모든 회사들이 데이터 회사로 전환되는 기점이지 않았나 생각하게 됨
배치 컴퓨팅에서 이벤트 스트리밍으로의 전환과 함께 또 다른 혁명이 발생했고 "실시간 빅데이터"의 새로운 시대를 열었다.
엔지니어는
Hadoop,
Apache pig,
Apache hive,
Aapache HBase,
Apache Storm,
Aapache Spark
Dremel,
Cassandra,
Presto
등등 실제 업무 현장에 등장한 수많은 기타 신기술중에서 가장 뛰어난 최신 기술을 선택할 수 있었다. 기존의 엔터프라이즈 지향적이고 GUI 기반인 데이터 도구는 구식으로 느껴졌고 MapReduce 출현으로 코드 우선 엔지니어링이 유행함 (물론 지금은 추상화가 잘되어있음)
2000년대 후반과 2010년대에 데이터 도구가 폭발적으로 증가하면서 빅데이터 엔지니어가 탄생함
Hadoop, YARN, HDFS(Hadoop Distribute File System), MapReduce를 포함하는 하둡 생태계같은 도구와 기술을 효과적으로 사용하려면 개발 및 저수준 인프라 해킹에 능숙해야했지만 강조점이 바뀌게됨
빅데이터는 성공의 희생양이 되었음
Hadoop의 도입을 기술적으로 지원하는 비즈니스가 성립하게 되었다.
그리고 그 때 사용하게 된 키워드가 바로 '빅데이터'이다.
사실상 판매하는 기업들이 과대포장을 하면서 일이 터져버림
작은 데이터를 처리하는대도 하둡을 사용하는 일 이 발생하기도 함
빅데이터 자체의 인기에도 불구하고 막상 살펴보면 떡락했는데 이 이유는 많은 이유가 있겠지만
한단어로 말하면
simplification
오픈 소스 빅데이터 도구는 강력하고 정교했지만 이를 관리하려면 많은 작업과 지속적인 관심이 필요했다
빅데이터 엔지니어는 복잡한 도구를 유지 관리하는 데 과도한 시간을 할애하고,
비지니스의 통찰력과 가치를 제공하는 데는 많은 시간은 소비하지 않는 경우가 많았다
데이터만 관리하기 바빳다는 거지 비지니스에는 관여가 안됫다는 얘기로 밖에 안들림
오픈소스 개발자와 클라우드 업체, 서드파티 업체들은 높은 관리 오버헤드와 클러스터 관리 비용 그리고 오픈 소스 코드의 설치, 구성, 업그레이드 없이 빅데이터를 추상화하고 단순화하며 사용 가능하게 만드는 방법을 찾았는데 빅데이터라는 용어는 본질적으로 많은 양의 데이터를 처리하는 특정 시간과 접근 방식을 설명하는 유물과 같음
오늘날 데이터는 그 어느 때보다 빠르게 이동하고 점점 커지고 있지만, 빅데이터 처리는 더 이상 별도의 용어를 사용할 가치가 없을 만큼 접근성이 좋아짐 모든 회사는 실제 데이터 크기와 관계없이 데이터 문제를 해결하는 것을 목표로 함 이제 빅데이터 엔지니어는 그저 데이터 엔지니어임
2020년대 : 데이터 수명 주기를 위한 엔지니어링
데이터 엔지니어는 역사적으로 Hadoop, Spark, 또는 인포매티카 와 같은 모놀리식 프레임워크의 저수준의 세부 정보를 사용하는 경향이 있었다 하지만 이제는 그 트렌드가 분산되고, 모듈화되고, 관리되고, 고도로 추상화된 도구로 이동 중이다
데이터 원천과 데이터 형식은 그 다양성과 크기가 계속 증가하고 있고 데이터 엔지니어링은 점차 궁극적인 비지니스 목표를 달성하고자 다양항 기술을 마치 레고 블록 처럼 연결하고 상호 운용하는 분야가 되고 있다
이책에서 논의하고 데이터 엔지니어는 더 정확하게 묘사하면 데이터 수명 주기 엔지니어로 표현할 수 있겠다
데이터 수명 엔지니어는 여전히 저수준의 데잍 ㅓ프로그래밍 기술을 유지하고 필요에 따라 이를 사용한다
하지만 데이터 관리, 데이터 옵스, 데이터 아키텍처, 오케스트레이션 및 일반 데이터 수명 주기관리와 같은 가치 사슬의 상위영역에 자신의 역할이 점점 더 집중되고 있음을 발견함
도구가 고도의 추상화로 단순해짐에 따라 데이터 엔지니어의 태도에도 눈에 띄는 변화가 나타남
누가 "가장 큰 데이터" 를 보유하는지 초점을 맞추는 대신, 오픈 소스 프로젝트와 서비스는 데이터 관리와 통제, 사용 및 발견의 용이성, 그리고 품질 향상에 점점 더 많은 관심을 기울이고 있다
예전에는 단순 데이터만 관리하고 많으면 장땡이라는 의식에서 점점 성숙도가 높아졌다고 생각함
질 좋은 데이터를 위해서 연구하고 발전하는 방향이 얼마나 아름다운가
데이터 엔지니어는 이제 CCPA (캘리포니아 소비자 개인정보 보호법) GDPR (일반 데이터 보호 규정) 같은 약어에 정통함
파이프라인을 설계할때는 개인정보보호, 익명화, 데이터 가비지 수집 및 규정 준수에 관심을 가지고 고민함
오래된 것이 다시 새로운 것이 된다 (데이터 품질과 거버넌스를 포함하는)
우리는 현재를 데이터 수명 주기 관리의 황금기로 본다 (데이터 처리를 할 수 있는 수단이 매우 많아졌기 때문에)
데이터 엔지니어링 수명 주기를 관리하는 데이터 엔지니어는 그 어느 때보다 더 나은 도구와 기술을 보유하고 있음
'책 > 견고한 데이터 엔지니어링' 카테고리의 다른 글
Part 1 - [Chapter 2] . 데이터 엔지니어링 수명 주기 (2) (0) | 2024.01.08 |
---|---|
Part 1 - [Chapter 2] . 데이터 엔지니어링 수명 주기 (1) (0) | 2023.12.20 |
Part 1. 데이터 엔지니어링 기반 구축하기 (3) (0) | 2023.12.18 |
Part 1. 데이터 엔지니어링 기반 구축하기 (1) (0) | 2023.12.15 |