Emerging Architectures for Modern Data Infrastructure (1/2)
Andressen Horowitz (a16z)는 공신력 있는 VC 회사입니다.
이 회사에서 최신 데이터 인프라 아키텍처에 대해 정리한 글이 있어 소개드립니다.
2020년 10월에 소개된 글로 본문은 여기를 참고해주세요~
Why Data?
왜 하필 데이터 중심의 Architecture가 나타났을까요? 간단합니다. 산업의 흐름입니다.
산업의 흐름이라는 것은 회사와 개인을 발전 시키는 기술 및 결정의 집합입니다.
이 흐름에 집중하지 않으면 아무리 큰 회사라도 경쟁에서 도태되기 마련입니다.
최근 네이버 스마트 스토어 광고는 비즈니스에서 데이터의 역할을 직접적으로 설명해주고 있습니다.
a16z에 의하면 오늘날의 가장 빠르게 성장하는 스타트업들은
데이터를 관리하기 위한 인프라를 구축한다고 합니다.
이러한 시스템은 데이터 기반의 결정이 가능하게 하고
데이터 기반의 제품 강화가 가능하게 합니다.
그러니까, 데이터 인프라의 목적, 제품에서 데이터를 수집하는 목적이 이 두가지라는 겁니다.
Data-driven Decision Making
C-level이라고 하는 CEO, CTO, CIO, CFO 등의 회사 최고 결정권자들이 직관으로 일하는 시대는 끝났습니다.
데이터를 철저히 분석하게 하고 더욱 다양한 관점의 데이터들을 종합하도록 지시하고 결정합니다.
난 데이터 엔지니어인데 보고서 작성용 인프라만 구축하고 있다구요?
그 게 첫 번 째 목적이거든요...
Data-driven Decision Making을 위한 시스템을 "분석 시스템 (Analytic System)" 이라고 합니다.
Data-powered Products
인프라 구축의 두 번 째 목적입니다.
데이터를 확보하고 확보된 데이터로 Machine Learning Model을 학습합니다.
학습된 Model은 제품에 탑재가 되어 제품의 질을 향상시킵니다.
즉 AI를 제품에 탑재하는 것입니다.
Data-powered Products를 위한 시스템을 "운영 시스템 (Operational Systems)" 이라고 합니다.
이 두 가지 시스템을 제공하기 위한 인프라를 데이터 인프라 (Data Infrastructure)라고 합니다.
계속해서 보게 될테지만, 데이터 인프라에는 데이터를 옮기기 위한 Pipe,
저장하기 위한 Storage, 분석하기 위한 Query, 시각화를 위한 Dashboard 기술들이 있고
나아가서는 Data science, ML 라이브러리, 자동화된 Data Pipeline, Data Catalog 등
Data에 대한 모든 기술들이 포함되어 있습니다.
이 기사에서 다루는 용어는 정말 중요합니다!
기사의 목적
이 기사의 목적이 흥미롭습니다. 현업에서도 항상 느꼈던 건데 이 분야는 Buzz Word가 정말 많습니다.
누구도 정확한 정의를 내려주지 않은 채 본인만의 상상의 나래로 사용하는 용어가 많습니다.
Data Lake는 뭐고 Data Warehouse는 뭔가요? Data Mart요?
어느 정도 의사 소통은 되지만 정확한 의사 소통을 위해서는 시간이 계속 길어질 수 밖에 없었습니다.
a16z는 2년 동안 수 백명의 전문가들과 이야기하며 최신 데이터 인프라 사례집을 구축했습니다.
무엇보다 훌륭한 점은 데이터 인프라에 등장하는 공통된 용어를 사용했다는 것입니다.
최신 데이터 인프라의 Best Practice를 정리했다는 것보다
개인적으로는 용어 통일에 대한 시도가 가뭄에 단 비 같았습니다.
그래서 이 기사에서 다루는 용어들은 다시 한 번 정말 중요합니다.
기사 초반부에는 데이터 분야가 얼마나 중요해지고 있는지 다룹니다.
시장 규모, 데이터 관련 직업의 성장 등에 대해 다루고 있는데 넘어가겠습니다.
통합 데이터 인프라 아키텍쳐 (A Unified Data Infrastructure Architecture)
데이터 인프라를 위한 도구들과 Best Practice들이 빠른 속도로 발전하고 있습니다.
이 모든 것을 하나의 View에 담기가 어려울 정도로 기술이 교체되고 변화하고 있는데요.
이 기사는 2020년 10월에 작성되었으니 현재의 주목받는 기술들을 하나의 View에 잘 정리했다고 볼 수 있습니다.
Unified Architecture는 데이터 처리 단계를 총 6가지로 나누었습니다.
각 처리 단계의 의미를 살펴보도록 하겠습니다.
Source는 비즈니스 데이터와 운영 데이터가 생성되는 단계입니다.
Ingestion and Transformation은 흔히 ETL이라고 말하는 데이터 추출/변형/적재하는 단계입니다.
Storage는 쿼리와 프로세싱이 가능한 형태로 데이터를 저장하는 단계입니다.
Historical과 Predictive는 데이터 분석가나 데이터 과학자들이 데이터를 쿼리 또는 처리하는 단계입니다.
Output는 데이터 분석 결과를 보여주는 단계입니다. 제품에 탑재하는 단계도 포함합니다.
분석, AI/ML이 한 자리에
앞서, 데이터 인프라의 목적은 두 가지가 있다고 말씀드렸습니다.
데이터 기반 분석과 데이터 기반 운영입니다.
사실 두 가지 목적은 다르게 발전해 왔습니다.
Uber의 미켈란젤로와 데이터 플랫폼이 나뉘어져 있는 것처럼요.
(* Uber Michelangelo eng.uber.com/michelangelo-machine-learning-platform/)
(* Uber Big Data Platform eng.uber.com/uber-big-data-platform/)
Big Data Platform이 Storage 단계 앞 부분,
어떻게 다양한 데이터를 다양한 소스에서 수집하는가
ML 플랫폼이 Storage 단계 뒷 부분,
어떻게 데이터로 모델을 학습하고 배포하는가
이런 관점에서 본다면 Storage 단계는
두 영역에서 모두 중요한 단계라서
광범위한 유스케이스로 성장해온 단계라고 볼 수 있습니다.
데이터 분석을 위해 고안된 Storage가 Data Warehouse입니다.
대부분의 Data Warehouse는 Business Metric을 빠르고 쉽게 쿼리하기 위해
구조화된 형태로 데이터를 저장합니다.
따라서 이 Storage는 대개 SQL을 지원하고 간혹 Python까지 지원합니다.
반면 데이터 기반의 운영을 위해서
모델에 따라 다른 모양으로 정제되기 때문에
Stroage는 유연해야 합니다.
이 Storage가 Data Lake입니다.
Data Lake는 데이터를 구조화하지 않고
Raw 형태로 저장합니다.
하지만 Data Lake로부터 데이터를 꺼내 쓰기 위해서는
다소 복잡한 Data Processing 과정이 필요할 수 있습니다.
따라서 Java, Scala, Python, R, SQL 등 다양한 언어를 지원합니다.
Data Warehouse와 Data Lake를 나누는 기준은
지원하는 언어의 수 (적음 vs. 많음),
사용 목적 (분석 vs. 후처리),
Storage 저장 형태 (Structured vs Raw)
정도가 될 수 있겠습니다.
재밌는 점은 최신 Data Warehouse와 Data Lake가
점점 더 닮아가고 있습니다.
그래서 일부 전문가들은 두 가지 기술이 하나의 Storage 형태로 수렴할 것이라고
예측하고 있습니다.
둘 모두 분산 스토리지 기반, 수평 확장성 제공, Semi-structured 데이터 타입 사용,
ACID 트랜잭션 제공, 실시간 SQL Query 지원등 유사한 기능을 제공하고 있거든요.
아마 현업에서 Data Lake와 Data Warehouse 용어가 혼용되었던
가장 큰 이유가 이것이 아닌가 싶습니다.
아키텍처의 변화
데이터 인프라가 빠르게 변화하고 있따고 말씀드렸습니다.
좀 더 High-level에서 아키텍처 레벨에서 그 변화를 정리해보겠습니다.
On Prem 에서 Public Cloud로
데이터는 회사의 자산이기 때문에 많은 회사들이
데이터만큼은 자체적으로 구축한 데이터 센터에 데이터를 저장해왔습니다.
그러나 자체적으로 구축한 데이터 센터는
확장성과 접근성에서 문제가 있습니다.
데이터의 규모가 빠르게 커지면서
데이터 센터를 확장해야하는데
서버 비용도 만만치 않을 뿐더러
서버를 추가하기 위한 작업 자체가 복잡합니다.
기존 데이터들에 영향을 주지 않으면서
서버를 추가하기 위해서는
다양한 분야의 많은 엔지니어가 필요하거든요.
Public Cloud에서는 몇 번의 클릭만으로
언제든지 확장 가능하고 쿼리 가능한
Data Warehouse를 구축할 수 있습니다.
Hadoop 에서 차세대 Data Lake로
Data Lake는 성능과 안정성 측면에사 빠르게 발전하고 있습니다.
최근에는 ACID Transaction 및 SQL Query를 지원하는
Data Lake가 주목받고 있습니다.
기존 Hadoop 시스템의 경우
POSIX Filesystem과 유사한
Primitive 인터페이스만 제공해서
아무래도 사용 상의 불편함이 있었죠.
Hive, Presto와 같은 새로운 인터페이스가
Data Lake에 등장하였고
자체적인 Data Lake를 제공하는
Detabricks의 Delta Lake가 등장하였습니다.
ETL 에서 ELT로
작년부터 주목했던 Pipeline의 변화입니다.
ETL 프로세스로 한 번 정제되고 필터링되어
적재된 데이터는 추 후 재가공하는 데 어려움이 있습니다.
또한 중간에 Source가 변경되면 Transformation 파이프라인을
수정해야하기 때문에 자동화가 어렵다는 문제도 있습니다.
이 문제를 해결하기 위해
먼저 적재하고 이 후 필요에 따라
Transformation Pipeline을 추가하는 형태로
Pipeline이 변화하고 있습니다.
Workflow Manager 가 Dataflow 자동화 솔루션으로
데이터 인프라는 데이터의 흐름을 관리하기 위한 인프라입니다.
복잡한 Pipeline이 포함되고
데이터 흐름에 다양한 분기가 추가되면
수 많은 Pipeline을 관리하고 실행할 자동화 시스템이 필요합니다.
기존 Workflow Manager가 Dataflow 솔루션으로
훌륭히 자리매김하였습니다.
DAG 기반의 추상화를 제공하는
Workflow Manager들은
데이터 Pipeline을 시각화하고
분기를 관리하는데 훌륭한 역할을 수행합니다.
분석팀만의 업무에서 비기술직 사용자의 업무로
Dashboard 기술들과 같은 시각화 툴들은
자동화된 분석 툴에 힘입어
분석가가 아니더라도
데이터를 분석하고 Insight를 얻게 합니다.
더 많은 사용자가 Data를 사용하여
업무를 처리하게 되었습니다.
데이터 가버넌스의 복잡성 향상
보안성 데이터와 개인정보 데이터들에 대한 중요성이 강조되고 있습니다.
따라서 데이터 플랫폼에 대한 Endpoint 관리 뿐만 아니라
각 데이터에 대해 세부적인 Access Control이 필요해졌습니다.
데이터 인프라는 이를 중앙화하여 더욱 세부적으로
데이터에 대한 규제를 자동화할 수 있는 시스템이 중요해졌습니다.
다음 포스팅에서는 이러한 통합 뷰를 기반으로
최신 데이터 인프라를 구축하기 위한 Use-case별
Best Practice 세 가지를 소개하도록 하겠습니다.
'Big Data' 카테고리의 다른 글
| Apache Beam 시작하기 (0) | 2022.04.03 |
|---|---|
| An overview of end-to-end entity resolution for big data (0) | 2020.12.16 |
