Databricks는 Snowflake와 같이 급부상하고 있는 클라우드 솔루션 중 하나이다. 기존의 Big 3 체제를 넘보는 ( 하지만 해당 Big 3 위에서 구현하긴 해야한다 ) 몇 안되는 대체제이기도 하다.
데이터브릭스는 2013년도에 Apache Spark 개발자들이 모여 설립하였으며, 2017년에 빠르게 MLflow로 MLOps의 개념을 도입하였다. 최근에는 AutoML, Genie등을 통해 SQL과 ML 모두 특정 수준까지 자동화도 가능하다. 2024년 기준 유니콘 기업 중 3위로 평가받는다
| 순위 | 기업 | 산업 | 기업가치 |
| 1위 | ByteDance | 콘텐츠/미디어 | 약 2,000억 달러 |
| 2위 | SpaceX | 항공우주 | 약 1,800억 달러 |
| 3위 | Databricks | AI / 데이터 플랫폼 | 약 430억 달러 |
| 4위 | Stripe | 핀테크 | 약 500억 달러 |
| 5위 | OpenAI | 생성형 AI | 약 290억~900억 달러 (투자자마다 다름) |
개인적으로 사용해봤을 때 크게 장점은 3가지로 볼 수 있다.
1) LakeHouse의 유연함
LakeHouse라는 명칭으로 Warehouse와 Lake를 합친 단어를 쓴다. 따라서 정형+비정형 데이터를 유연하게 저장할 수 있다는게 장점이다. Volume으로 다양한 데이터를 저장할 수 있으며, Table화도 쉽게 가능하다. 또한 기학습한 Model도 자체도 저장이 되며, Vector의 임베딩값 또한 자체적으로 저장을 할 수 있다. 하지만 VectorDB는 아니여서 자체적으로 검색은 불가능하다.
| 구분 | Data Warehouse | Data Lake | Lakehouse (Databricks) |
| 목적 | BI / 정형 데이터 분석 | 원시 데이터 저장 | 분석 + AI/ML + 유연성 통합 |
| 데이터 유형 | 정형 데이터(SQL 기반) | 비정형 데이터 포함 | 정형 + 비정형 모두 |
| 저장 포맷 | 테이블(스키마 필요) | 파일(JSON, Parquet 등) | Delta Lake (ACID 지원 포맷) |
| 스키마 구조 | 스키마 온 라이트(write 전에 정의) | 스키마 온 리드(읽을 때 정의) | 하이브리드 (유연함 + 관리성) |
| 트랜잭션 지원 | O (ACID) | X | O (ACID via Delta Lake) |
| 확장성 | 제한적 (고비용) | 매우 높음 (저비용) | 높음 (유연 + 관리성 조화) |
| ML/AI 적합성 | 약함 (정형에 한정) | 강함 (대량 원시 데이터 활용 가능) | 매우 강함 (MLflow 등 통합) |
| 대표 플랫폼 | Snowflake, Redshift, BigQuery | Hadoop, S3, ADLS | Databricks, AWS Athena (제한적) |
2) ML 특화 솔루션 ( MLflow, AutoML, Genie )
ML은 Vector로 저장되는 모델이 아니면 기존 RDB로 결과값, 로그 등을 관리해도 사실 큰 문제는 없을 때가 많다.
다만 이를 받쳐줄 Compute 자원이나 시각화, alert 시스템 등을 모두 구축하여야 하는데 해당 부분에 대한 일원화가 가능하다.
또한 AutoML로 ML 지식이 적은 부서에서도 쉽게 Baseline RAG을 만들고 EDA를 할 수 있으며, Genie는 Unity Catalog 특유의 Meta로 훨씬 정교한 SQL Agent의 업무 수행이 가능하다. 또한 Spark 기반으로 자체 notebook에서 빠르게 데이터 처리도 가능하며, MLlib 등으로 간단한 ML과도 연동이 가능하다.
3) 직관적인 UI
AWS 등의 다른 클라우드들은 선도기업인만큼 기능들도 많고, 섬세할 때도 많으며, 권한 제한도 상당히 훌륭하다. 그러나 여러 화면을 교차해서 다녀야하며, 가끔 구현하고 싶은 내용에 비해 너무 복잡한 기능을 건드려야할 때가 있다. 특히 각 플랫폼끼리의 연결이 잘 안되거나, 너무 세부적인 권한 등으로 파이프라인이 자주 막히기도 한다. Databricks는 단 하나의 UI에서 움직일 수 있고, 사이드바에서 모든 목록을 확인 가능하다.
그러면 단점은 없을까? 물론 어느정도 존재한다.
1) 다소 비싼 비용
AWS 등이 청구하는 비용이 악명높지만, Databricks도 다른 클라우드 위에서 빌드되는만큼 추가적인 비용이 들어간다. 특히 Compute를 목적별로 쓰지 않고 일반적으로 All-Purpose를 디폴트로 지정한다면 생각보다 많은 비용에 놀랄 수 있다.
2) LLM에 대한 개발 지원이 다소 빈약
LLM이 hype 된지 오래되었고, 상대적으로 발빠르게 움직일 수 있는 databricks의 지원이 가장 느린 것 같다고 생각되기도 한다. AWS 이미 클릭 몇 번으로 효과적인 RAG Agent를 구축할 수 있으며, 섬세한 임베딩과 엔진도 지원한다. Datarbricks는 Playgroud 등에서 LLM에 대한 지원을하고 LLMOps 등을 지원한다고 명목적으로 기재하지만 사실 효과적으로 기업용 LLM을 구축하기는 다소 어려운 환경이다. 서드파티인 LangChain 등을 거의 무조건 사용해야하는 상황이며, 이는 부서별 RAG이나 Agent가 빨리 도입 될 수 있는 속도를 늦춘다.
모델을 1-2개만 돌릴거라면 그냥 사내 서버에서 RDB와 함께하거나 MLflow만 사용하는게 나을지도 모르겠다. 하지만 수십개 이상의 모델을 효과적으로 비교 및 관리해야하는 팀이라면 Databricks도 나쁘지 않은 판단이 될 수 있다. 특히 AutoML의 EDA부분은 DS 업무를 할 때 효과적으로 데이터 파악이 가능하게 해주며, Genie는 Meta와 인스트럭션만 잘 관리한다면 다양한 Table을 Join하여 높은 수준의 SQL 쿼리문을 생성하고 간단한 시각화도 해주기 때문에 DA, 기획, PM 모두에게 꽤 도움이 될 수 있는 기능이라고 생각한다.
'Software Engineering' 카테고리의 다른 글
| 소프트웨어 아키텍처 ( Software Architecture ) 와 커피 (0) | 2025.06.04 |
|---|---|
| SOLID 원칙과 커피머신 (0) | 2025.05.28 |
| OOP ( Object-Oriented Programming )와 커피머신 (0) | 2025.05.27 |
| Github vs GitLab ? 뭐가 다르지 (0) | 2025.05.06 |
| Docker와 Kubernetes(k8s) ? - 오케스트레이션 (0) | 2025.05.06 |