위키원
람다 아키텍처
람다 아키텍처(Lambda Architecture)는 실시간 분석을 지원하는 빅데이터(Big Data) 아키텍처이다. 대량의 데이터를 실시간으로 분석하기 어려워서 배치(batch)로 미리 만든 데이터와 실시간 데이터를 혼합해서 사용하는 방식이다.
개요
람다 아키텍처는 아파치 스톰 개발자인 나단 마즈(Nathan Marz)가 제안한 개념으로, 실시간 레이어와 배치 레이어를 결합하여 빅데이터의 실시간 분석을 지원하는 아키텍처를 의미한다. 예를 들면, 배치 분석을 통해 일자별로 통계를 생성하고, 당일 데이터는 별도의 실시간 통계를 유지한 다음, 이를 합쳐서 실시간 분석을 제공한다. 하둡(Hadoop) 기반으로 람다 아키텍처를 구현할 때에는 일반적으로 하둡 분산 파일 시스템(Hadoop Distributed File System)에 적재된 데이터를 맵리듀스(Map Reduce)나 하이브(Hive)로 배치 분석하고, 스톰이나 스파크 같은 스트리밍 솔루션으로 실시간 집계를 수행한 뒤, 이를 에이치베이스(HBase)나 관계형 데이터베이스 관리 시스템(RDMS)에서 통합하여 실시간에 가까운 분석을 유지한다. 이와 같은 구성은 의도한 대로 실시간 빅데이터 분석을 지원하기는 하지만, 이티엘(Extraction, Transformation, Loading) 작업부터 시각화 단계에 이르기까지 독립적인 다수의 구성요소를 통합하여 개발해야 하므로 구축 및 운영에 있어서 많은 어려움이 있다.
인터넷에 연결되는 수십만 대의 사물인터넷(IOT) 센서 데이터를 실시간으로 분석할 때에는 더욱 어려움이 따른다. 실무에서는 센서 데이터에 포함된 식별자를 기준으로 원본 데이터에 다양한 메타데이터를 추가하여 분석을 수행하는 사례를 흔히 볼 수 있다. 예를 들면, 셋톱박스의 식별자를 연령, 지역, 상품명 등으로 맵핑하여 다양한 분석을 수행하게 된다. 가장 흔한 설계 오류는 아래와 같이 스트리밍 솔루션에서 로그가 수신될 때마다 관계형 데이터베이스 관리 시스템을 대상으로 매번 쿼리하는 구성이다. 아키텍처에서는 데이터베이스에 대한 메타데이터 쿼리가 네트워크 스택의 레이턴시를 포함하여 1밀리초 이내에 응답한다고 하더라도 1000TPS를 내기 어려운 구성이 된다. 일반적으로는 실시간 스트리밍 처리와 배치 분석이 별개의 솔루션으로 구성되는데, 이렇게 다수의 컴포넌트로 구성된 아키텍처에서 가장 큰 성능의 병목은 메모리에 있는 데이터를 바이너리로 직렬화하고 네트워크 I/O를 수행하는 연동 구간에 존재한다.[1]
등장배경
2002년 하둡의 아버지 더그커팅(Doug Cutting)이 루씬(lucene) 기반의 오픈소스 검색엔진인 너치(Nutch)를 위해 일하기 시작하면서 하둡의 역사가 시작됐다. 이후 2003년 검색엔진의 최적화에 주력했던 구글에서는 구글 파일 시스템(GFS)에 대한 백서를 발표하고 2004년에는 맵리듀스에 대한 백서를 발표한다. 2006년 더그커팅이 참여한 너치에서 파생된 하둡이 서브 프로젝트가 되고 2년 후 하둡은 아파치의 톱-레벨 프로젝트가 된다. 2008년 빅데이터 분석의 3대 업체 중 하나인 클라우데라(Cloudera)가 설립되고 더그커팅이 합류하고 2009년 상업목적의 하둡이 배포되게 된다. 이후에 하이브, 임팔라(Impala) 등 하둡을 기반으로 한 오픈소스 생태계가 확장되게 된다. 그러면서 하둡을 적용하는 사례가 늘어나고 빅데이터 처리 플랫폼에서의 디팩토(Defacto) 표준으로 자리 잡았다. 하둡이 빅데이터를 처리하는 분산처리 플랫폼으로서 적용되는 사례가 늘어나면서 하둡은 잘 작동하였지만, 실시간성의 처리구조는 아니었다. 오히려 배치 성의 성격을 갖는 프로세싱 구조라고 할 수 있다. 이러한 준 실시간성을 보완하여 실시간 처리를 하기 위한 하둡 오픈소스 생태계들도 발전하기 시작한다.
실시간성의 데이터를 처리하기 위해 스톰과 스파크의 실시간 처리를 위한 스파크 스트리밍(Spark Streaming), 삼자(Samza), 플링크(Flink)등의 처리 인프라와 실시간성의 데이터 수집을 위한 플룸(Flume)과 카프카(Kafka) 등의 다양한 처리 에코시스템이 발전한다. 하둡의 배치성/준 실시간성을 극복하기 위해 위의 여러 오픈소스 생태계를 조합하여 실시간 처리를 할 수 있는 개념들이 나타난다. 람다 아키텍처는 나단 마즈가 트위터에서의 분산프로세싱 경험을 바탕으로 스피드 레이어(Speed Layer), 배치 레이어(Batch Layer), 서빙 레이어(Serving Layer)로 3계층 구성된 실시간 처리 아키텍처이다. 람다 아키텍처는 배치처리와 실시간처리시의 개발언어나 오픈소스 인프라의 컨셉자체가 틀려 고려할 사항이 많고 이에 따라 기능이 중복되고 관리 및 유지보수에 많은 공수가 투입되며 복잡하지만, 3계층의 람다 아키텍처는 데이터의 정확성 및 일관성을 제공함과 동시에 최소의 지연으로 실시간적인 결과를 사용자에게 제공한다.[2]
특징
레이어
람다 아키텍처의 대용량 데이터는 일반적으로 쿼리에 많은 시간이 소요된다. 데이터양에 따라 조회에 몇 시간이 걸릴 수 있다. 람다 아키텍처는 스피드 레이어와 배치 레이어의 조합으로 대용량 데이터에도 어느 정도의 실시간 분석을 지원해줄 수 있다. 데이터가 생성되면 데이터 저장소에 저장한다. 이 데이터는 배치로 일정 주기마다 배치 뷰를 만들어 낸다. 그리고 동일한 데이터를 실시간 데이터 처리를 통해 실시간 뷰를 만들다. 그리고 이 두 개를 혼합해 빠르고 실시간 데이터가 반영된 분석을 할 수 있다. 스피드 레이어와 배치 레이어가 모두 똑같은 처리를 구현하고 있으므로, 중복된 비지니스 로직 및 두 경로의 아키텍처 관리에 따른 복잡성이 발생한다. 이 때문에 람다 아키텍처를 단순화한 카파 아키텍처(Kappa architercutre)를 선택하기도 한다.[3]
람다 아키텍처는 데이터가 저장되어있고, 배치 처리하여 배치 뷰를 생성하는 배치 레이어와 배치로 분석된 데이터가 정장되어 있어 배치 외에는 쓰기가 안되는 서빙 레이어 및 실시간 데이터를 집계하는 스피드 레이어로 구성된다. 배치 레이어에서 만든 배치 뷰 데이터와 스피드 레이어에서 만든 실시간 뷰의 데이터가 중복되지 않게 관리하는 것이 중요하다. 이 부분은 타임스탬프(timestamp)로 해결이 가능하다. 또한, 배치로 데이터가 만들어진 후에 실시간 뷰의 데이터를 주기적으로 지워주어야한다. 각 레이어에서 사용되는 솔루션을 예를 들면, 배치 레이어인 하둡과 하둡 분산 파일 시스템, 하둡 및 맵리듀스는 데이터를 저장하고 맵리듀스로 데이터를 분석한다. 그리고, 서빙 레이어는 에이치베이스로 맵리듀스로 분석한 데이터를 저장하는 노에스큐엘(NoSQL)이다. 스피드 레이어는 스트리밍 데이터를 처리하는 스톰을 사용하고, 빠른 데이터 처리가 필요하다는 뜻이다. 또한, 메모리 기반의 레디스(redis)를 사용한다. 즉 빠른 속도가 필요한 솔루션을 사용했다.[4]
- 배치 레이어
- 기존에 데이터처리를 위한 배치 프로세스이다. 데이터를 처리하는 단위로 데이터가 입력되면 해당 단위로 데이터 처리를 하게 된다. 입력되는 데이터는 마스터 데이터 세트라고 해서 저장되거나 읽기만 가능하고 변경은 안 되는 성질을 갖는다. 대용량 데이터를 집계할 때는 시간이 오래 걸리는데 조회를 요청할 때마다 데이터를 제공해주는 데 매번 몇 시간이 걸리는 서비스를 사용할 유저는 없을 것이다. 그래서 특정 시간마다 주기적으로 계산을 수행하는 배치를 이용하여 데이터를 미리 계산해 놓는 것이다. 배치 레이어의 저장소에서는 로우(raw) 데이터를 보관해놓는다. 이로 인해 배치 뷰의 데이터가 부정확할 때 복구가 가능해지고, 새로운 뷰를 제공하고자 할 때, 기존의 원본 데이터를 가지고 있어서 새로운 뷰의 통계 분석이 가능해진다. 특정 단위의 배치 프로세스이기 때문에 데이터의 정합성이나 충돌, 동시성, 이상 현상, 장애 등에 대해서 비교적 자유로운 특성을 갖는다. 일반적으로 사용하는 솔루션으로는 아파치 하둡이 있다.[3]
- 스피드 레이어
- 배치 레이어를 사용하여 대용량 데이터 조회 속도의 문제를 해결했지만, 배치가 도는 간격 사이에 있는 데이터는 조회할 수 없다. 예를 들어서 배치가 매일 자정마다 동작한다면 당일 오후에는 해당 일자의 데이터를 확인할 수 없는 것처럼, 이런 문제를 해결하기 위해서 당일 데이터를 실시간으로 집계해서 별도의 테이블에 집계한다. 즉, 스피드 레이어의 역할은 배치 레이어에서 생기는 차이를 채우는 것이다. 배치 레이어가 특정 단위작업 이후에 들어오는 실시간 데이터를 처리하고 응답시간을 빠르게 유지하는 역할을 하는 레이어이다. 스트림으로 들어온 데이터를 처리하기 위한 큐나 버퍼 같은 구조를 사용하고 효율적 스트림 처리를 위한 증분 처리 방식을 사용한다. 배치프로세스가 완료된 시점에는 처리된 실시간 뷰는 삭제되게 된다. 사용하는 솔루션으로 아파치 스톰, 에스큐엘(SQL) 스트림, 아파치 스파크 등이 있다.[3]
- 서빙 레이어
- 배치 레이어 및 스피드 레이어의 출력을 저장한다. 클라이언트에서는 이 서빙 레이어에 미리 계산된 데이터를 조회하기 때문에 빠른 응답이 가능해진다.[3]
- 레이어별 적용 시스템 리스트
람다 아키텍처는 데이터를 처리하는 구조를 설명하기 때문에 레이어별 사용 시스템에 대한 정답이 없다. 다음은 사용 가능한 솔루션 리스트이다.[4]
배치 레이어 컴포넌트 이름 사용언어 플랫폼 비고 하둡 맵리듀스
(Hadoop MapReduce)자바 하둡 Very low-level, not re-usable[^1] 스파크
(Spark)스칼라, 자바, 파이썬 스파크 인-메모리 하이브
(Hive)하이브큐엘, 자바 하둡 - 스파크 에스큐엘
(Spark SQL)에스큐엘, 스칼라, 자바, 파이썬 스파크 - 피그
(Pig)피그 라틴, 자바 하둡 - 스파크
(Sprok)피그 라틴, 자바 스파크 - 캐스케이딩(Cascading),
스콜딩(Scalding)자바, 스칼라 하둡 - 캐스칼로그
(Cascalog)클로저 하둡 - 크런치(Crunch),
에스크런치(Scrunch)자바, 스칼라 하둡 - 판굴
(Pangool)자바 하둡 -
서빙 레이어 컴포넌트 이름 사용언어 엘리펀트 데이터베이스
(Elephant DB)클로저 스플아웃 에스큐엘
(Splout SQL)자바 볼드모트
(Voldemort)자바 에이치베이스
(HBase)자바 드루이드
(Druid)자바
스피드 레이어 컴포넌트 이름 사용언어 비고 아파치 스톰
(Apache Storm)클로저 트위터 아파치 스파크 스트리밍
(Apache Spark Streaming)스칼라, 자바, 파이썬 AMPLab 아차피 삼자
(Apache Samza)스칼라, 자바 링크드인 아파치 S4
(Apache S4)자바 야후! 스프링 XD
(Spring XD)자바 피버탈
- 아키텍처 구성 시 고려사항
- 데이터의 정합성 및 유실 : 배치레이어나 스피드 레이어에서의 처리 시 데이터의 정합성을 보장하고 모니터링할 수 있는 수단이 필요하며 비즈니스적으로 중요한 데이터이고 스트리밍 처리 시 데이터가 유실되지 않도록 일정 기간 데이터의 롤링, 백업될 수 있도록 설정이 필요하다.
- 처리현황 모니터링 : 실시간 처리 시스템 구성 후에는 처리현황 및 인프라에 대한 이상 유무 및 특정 시점 데이터처리의 누락 여부를 모니터링할 수 있는 모니터링 체계가 중요하며 유용하다.
- 대시보드 및 자동화 : 현황을 모니터링하고 제어할 수 있는 기능을 따로 모아서 대시보드를 구성하고 사용자 레벨 별로 권한 관리할 경우 효율적으로 관리가 가능하다. 또한 관리가 필요한 부분은 자동화하는 방안도 고려가 필요하다.
- 빅데이터의 사용자 관점 시각화 : 처리된 데이터가 사용자에게 트랜드 상에 직관적으로 인지되도록 텍스트나 수치보다는 그래프나 표, 색깔 등으로 시각화될 경우 데이터 사용성이 증가한다.
- 용량 산정 및 처리 인프라의 프로비저닝 : 빅데이터 처리 시의 필요 인프라의 용량 산정 및 그에 따른 인프라가 자동으로 투입되도록 오토 스케일링 고려도 필요하다. 처리 서버의 중앙처리장치, 메모리, 네트워크 사용, 액티브 스레드 등에 따른 오토 스케일링 등이 있다.
- 오픈소스 버전 업그레이드 시 : 변경사항의 이력 관리로, 시스템을 구성하는 오픈소스의 버전에 따라 관련 인프라 간의 영향도 파악 및 반영에 따른 이력 및 문서화가 필요하다.
- 사용자 데이터 보안 및 백업 : 인프라의 액세스 권한에서부터 처리데이터의 개인정보 보호 및 기밀성에 대한 고려가 필요할 수 있다.[2]
비교
- 빅데이터 아키텍처
빅데이터 아키텍처(Big Data Architecture)는 기존의 데이터베이스 시스템보다 너무 크거나 복잡한 데이터의 수집, 처리 및 분석을 수행하도록 디자인되었다. 조직이 빅데이터 영역으로 전환하게 되는 시점은 사용자의 역량과 사용하는 도구에 따라 다르다. 수백 기가바이트의 데이터일 수도 있고, 수백 테라바이트의 데이터일 수도 있다. 빅데이터 집합으로 작업하기 위한 도구가 발전하면서 빅데이터의 의미도 달라지고 있다. 이 용어는 엄격히 데이터 크기만을 고려하지 않고, 고급 분석을 통해 데이터 집합에서 추출할 수 있는 가치와 점점 더 밀접한 관련을 갖는다. 데이터 크기만 고려한다면 빅데이터는 훨씬 더 큰 데이터이다.
데이터 환경이 변경되어 왔으며, 데이터로 수행할 수 있는 작업이나 수행하려는 작업이 변경되었다. 데이터가 수집되는 방법이 점점 더 다양해지면서, 스토리지 비용은 크게 감소했다. 빠른 속도로 도착하며 지속해서 수집 및 관찰해야 하는 데이터가 있다. 느리게 도착하지만, 대량의 정크로 구성된 수십 년간의 기록 데이터도 있다. 고급 분석 문제나 기계 학습이 필요한 경우에 직면할 수도 있다. 이러한 점이 바로 빅데이터 아키텍처가 해결하려고 하는 문제점이다. 빅데이터 아키텍처는 빅데이터 솔루션으로 미사용 빅데이터 원본의 일괄 처리, 사용 중인 빅데이터의 실시간 처리, 빅데이터의 대화형 탐색, 예측 분석 및 기계 학습이 있으며, 빅데이터 아키텍처 고려 사항으로는 기존 데이터베이스보다 너무 큰 볼륨의 데이터 저장 및 처리할 때, 분석 및 보고를 위해 구조화되지 않은 데이터를 변환할 때, 제한되지 않은 데이터 스트림을 실시간으로 또는 짧은 대기 시간으로 수집, 처리 및 분석할 때가 있다.[5]
- 카파 아키텍처
- 중복성과 복잡성을 제거한 카파 아키텍처는 람다 아키텍처의 배치 레이어와 스피드 레이어의 기능적 중복성과 복잡성을 제거하기 위해 제안된 것이다. 링크드인(Linkedin)의 제이 크랩스(Jay Kreps)가 제안한 카파 아키텍처는 배치 레이어를 제거하고 스피드 레이어에서 모든 데이터를 스트림 처리하여 서빙 레이어로 전달하는 구조로 되어있다. 스피드 레이어를 통해 스트림 처리를 하므로 재작업은 버전이 변경된 경우 버전별로 처리 후 별도의 테이블로 저장되고 이전 버전의 스트림 처리가 종료되면 재작업이 완료되게 된다. 람다 아키텍처와는 달리 배치 레이어가 제거되면서 하나의 레이어에 대한 관리 포인트만을 갖고 단일 프레임 워크 하에 동작하기 때문에 운영 및 유지보수의 장점이 있고 이상 현상 또는 장애 발생 시의 디버깅과 테스트에 대한 장점도 갖게 된다. 하지만, 스피드 레이어의 이상이나 장애 발생 시의 실시간 서비스 제공에 대한 부분과 데이터의 유실 등에 대한 보완 등도 고려해야 한다.[2]
람다/카파 아키텍처의 비교[6] 비교 항목 람다 아키텍처 카파 아키텍처 레이어 구조 3개 레이어(배치, 스피드, 서빙) 2개 레이어(스피드, 서빙) 아키텍처 목적 전송 지연 최소화, 일관성과 정확성 제공 레이어간 코드 공유 복잡성 제거 프로세싱 패러다임 배치+스트림 조합 스트림 재작업 패러다임 배치 사이클 마다 코드 변경 시 자원 소비 많음 적음 신뢰성 배치는 신뢰, 스트림은 근사치 제공 일관성 있는 스트림 제공으로 신뢰성 높음 사용자 트위터, 라이브퍼슨(Liveperson) 등 링크드인, 야후 등
- 제타 아키텍처
- 제타 아키텍처(Zeta Architecture)는 비즈니스에 데이터를 통합할 수 있는 확장 가능한 방법을 제공하는 엔터프라이즈 아키텍처이다. 아키텍처의 다양한 구성요소는 적절히 배치될 때 시스템의 복잡성을 줄이고 데이터를 보다 효율적으로 배포하는 데 도움이 된다. 제타 아키텍처의 구성 요소에는 분산 파일 시스템, 실시간 데이터 스토리지 및 플러그형 컴퓨팅 모델/실행 엔진과 데이터 컨테이너, 엔터프라이즈 애플리케이션 및 리소스 관리 도구가 포함된다. 이 모든 것들은 기업 목표를 실현하는 정교한 데이터 처리 시스템으로 만들어진다. 제타 건축은 "z"가 그리스 알파벳의 여섯 번째 글자인데, 이 건축의 시각화 개념은 육각형 모양을 가지고 있기 때문에 그렇게 이름이 붙여졌다. 이 아키텍처는 데이터 트래픽 볼륨으로 작업하고 관리자가 더 많은 작업을 수행하여 데이터 전달의 효율성을 높일 수 있도록 지원함으로써 도움이 될 수 있다. 예를 들어, 제타 아키텍처 애플리케이션은 로그 전달이나 로그 데이터의 복잡한 라우팅에 도움을 줄 수 있다. 일부 정보기술 분석가들은 제타 아키텍처를 이동 부품으로 특징짓고 이러한 유형의 시스템이 자원의 동적 할당에 도움이 된다.[7]
활용
- 새로운 분석 모델 개발
분석 통계 데이터를 제공하다 보면, 저장소에 저장된 원본 데이터를 재분석함으로써 추가적인 의미를 찾아낼 수 있는데, 이 영역은 데이터 과학자의 영역으로, 저장소에 있는 데이터를 통해서 새로운 데이터 모델을 추출하는 방식이다. 예를 들어, 글 읽기 이벤트와 글쓰기 이벤트 간의 상관관계를 파악해내거나, 요일별 이벤트 변화량 등을 분석해낼 수 있는데, 이 저장소에 알(R)이나 매트랩(Matlab)과 같은 데이터 분석 도구를 이용하여, 샘플 데이터를 추출해서 데이터의 상관관계를 파악해보고, 이러한 분석을 통해서 새로운 통계 모델을 설계하고 검증해볼 수 있다. 만약 이러한 모델이 적절하다면 알고리즘을 구현하고 이를 빅데이터 엔지니어에게 넘겨준다. 빅데이터 엔지니어는 데이터 과학자에게서 받은 알고리즘을 람다 아키텍처의 각 레이어에 배치된 솔루션에 알맞은 형태로 구현한다.[8]
- 차세대 람다 아키텍처
기존의 람다 아키텍처 구현은 배치 및 스피드 레이어 이중 데이터 공급으로 대역폭을 2배 사용하고, 디스크 기록 후 배치 쿼리 시 다시 읽기 때문에 낮은 성능을 보여주고, 배치와 스피드 레이어 통합 개발 공수 및 정합성이 있고, 여러 곳에 분산된 데이터의 액세스 컨트롤 어렵고, 다수의 솔루션 통합으로 장애 대응이 어렵다. 차세대 람다 아키텍처는 고성능 스트림과 배치 분석을 지원하는 솔루션을 이용하여 기존 람다 아키텍처 구현의 문제를 해결한다. 스트림, 배치, 리포팅 및 시각화의 모든 단계를 쿼리로 구성이 가능하고, 단일 솔루션에서 스트림 및 배치 분석을 통합하여 네트워크 대역폭 사용을 최소화한다. 원본 데이터 수집 시 인메모리 써머리 수행 후 디스크 기록하여 고성능을 발휘하며, 권한제어 및 데이터 관리 포인트 일원화한다.[1]
- 유연성 증대 방안
람다 아키텍처는 대용량 데이터 처리와 실시간 정보 제공을 위한 장점이 있음에도 불구하고 대부분 하둡이나 노에스큐엘 등의 솔루션을 조합해서 구현하는 경우가 대부분이기 때문에, 유연성 측면에서 문제점을 가지고 있다. 예를 들어 배치 뷰를 에이치베이스를 사용하고, 실시간 뷰를 레디스를 사용할 경우, 상호 솔루션 간 데이터 조인이 불가능할뿐더러, 인덱스나 조인, 그룹핑, 소팅 등이 어렵다. 이러한 기능이 필요하다면 각각 배치 처리와 실시간 처리 단계에 추가로 로직을 추가해서 새로운 뷰를 만들어야 한다. 쉽게 설명하면, 일반적인 노에스큐엘은 키-밸류 스토어의 개념을 가지고 있다. 그래서 테이블이 생성되었다 하더라도, 특정 칼럼 별로 데이터를 소팅해서 보여줄 수 없다. 만약 소팅된 데이터를 표현하고자 한다면, 소팅된 테이블 뷰를 별도로 생성해야 한다. 그래서 이런 문제점을 보강하기 위해서는 위에서도 잠깐 언급하였듯이 실시간 뷰와 배치 뷰 부분을 관계형 데이터베이스 관리 시스템을 사용하는 것을 고려해볼 수 있다. 쿼리에 특화된 OLAP(On-Line Analytical Processing) 데이터베이스를 활용하는 방법도 있고, 또는 휴렛 팩커드(Hewlett-Packard) 버티카 등을 활용할 수 있다. 휴렛 팩커드 버티카는 에스큐엘을 지원하지만, 전통적인 관계형 데이터베이스 관리 시스템이 데이터를 행 단위로 처리하는 데 반하여, 버티카는 데이터를 열 단위로 처리해서 통계나 쿼리에 성능이 더욱 뛰어나다.
업데이트
- 2013년 12월 11일 : 나단 비낸스(Nathan Bihnens)의 하둡 및 스톰을 사용한 실시간 아키텍처
- 2013년 12월 24일 : 다중 언어 지속성이 마이클 하우젠블라스의 람다 아키텍처를 충족하는 경우
- 2013년 12월 25일 : 마이클 하우젠블라스의 정적 및 동적 데이터 통합 관리 문제
- 2013년 12월 25일 : 마이클 하우젠블라스가 만든 램둡(Lamb doop)
- 2013년 12월 25일 : 마이클 하우젠블라스가 만든 트위터 서밍 버드
- 2014년 01월 19일 : 페레 페레라(Pere Ferrera)의 Trident, 하둡 및 스플아웃 에스큐엘을 사용한 해시 태그의 실시간 분석을 위한 람다 아키텍처 예
- 2014년 01월 20일 : 람다 아키텍처 - 페레 페레라의 최첨단 제품
- 2014년 06월 22일 : 빌딩 숲 - 하비 로만(Javi Roman)이 지은 람다 건축 환경 구축 업체
- 2014년 06월 30일 : 마이클 하우젠블라스의 배치 구성 요소
- 2014년 06월 30일 : 마이클 하우젠블라스의 서비스 구성 요소
- 2014년 06월 30일 : 마이클 하우젠블라스의 속도 구성 요소
- 2014년 07월 01일 : 마이클 하우젠블라스가 쓴 나탄 마르쿠스의 빅데이터 책
- 2014년 07월 24일 : 뎁루프(Deploop) : 하비 로만의 람다 아키텍처 프로비저닝 도구
- 2014년 08월 27일 : 급속도 애플리케이션 개발 스택(rad stack) - 드루이드 커미터스(Druid Committers)의 카프카, 스톰, 하둡, 드루이드(Druid)
- 2016년 07월 16일 : 아킴 니에르백(Achim Nierbeck)의 스파크, 카사안드라, 카프카 및 아카(Akka)와 함께 사물인터넷 데이터를 분석하기 위한 람다 아키텍처 예시
- 2017년 03월 25일 : 블라디미르 도로코프(Vladimir Dorokhov)가 마이크로소프트 애저(Azure) 클라우드에 람다 아키텍처를 적용했다.
- 2017년 04월 15일 : 나라얀 쿠마(Narayan Kuma)가 스파크, 스파크-스트리밍, 카산드라, 카프카, 트위터4j, 아카 및 아카-http를 사용하여 트위터의 트윗(tweet)을 분석하는 람다 아키텍처의 예를 보여줬다.[9]
각주
- ↑ 1.0 1.1 〈차세대 람다 아키텍처〉, 《로그프레소》
- ↑ 2.0 2.1 2.2 Saint Binary, 〈빅데이터의 실시간 처리와 람다/카파 아키텍처〉, 《티스토리》, 2018-10-10
- ↑ 3.0 3.1 3.2 3.3 James Lee, 〈람다 아키텍쳐(Lambda Architecture) 정리〉, 《티스토리》, 2018-11-25
- ↑ 4.0 4.1 Gyrfalcon, 〈람다 아키텍처 (Lambda Architecture)〉, 《티스토리》, 2017-03-21
- ↑ 〈빅 데이터 아키텍처〉, 《마이크로소프트》, 2018-02-12
- ↑ AsIsToBe, 〈(주간기술동향 - 20106년 하반기) 빅데이터 프로세싱 아키텍처 기술 및 도구 현황〉, 《네이버 블로그》, 2017-01-10
- ↑ 솔루션 헌터, 〈♥♥ 제타 아키텍처 (Zeta Architecture)〉, 《네이버 블로그》, 2020-05-08
- ↑ 조대협, 〈빅데이타 분석을 위한 람다 아키텍쳐 소개와 이해〉, 《티스토리》, 2015-01-06
- ↑ 〈Lambda Architecture〉, 《람다아키텍처》
참고자료
- 〈차세대 람다 아키텍처〉, 《로그프레소》
- Saint Binary, 〈빅데이터의 실시간 처리와 람다/카파 아키텍처〉, 《티스토리》, 2018-10-10
- Gyrfalcon, 〈람다 아키텍쳐(Lambda Architecture) 정리〉, 《티스토리》, 2017-03-21
- James Lee, 〈람다 아키텍쳐(Lambda Architecture) 정리〉, 《티스토리》, 2018-11-25
- 〈빅 데이터 아키텍처〉, 《마이크로소프트》, 2018-02-12
- 〈Lambda Architecture〉, 《람다아키텍처》
- 조대협, 〈빅데이타 분석을 위한 람다 아키텍쳐 소개와 이해〉, 《티스토리》, 2015-01-06
- 솔루션 헌터, 〈♥♥ 제타 아키텍처 (Zeta Architecture)〉, 《네이버 블로그》, 2020-05-08
- AsIsToBe, 〈(주간기술동향 - 20106년 하반기) 빅데이터 프로세싱 아키텍처 기술 및 도구 현황〉, 《네이버 블로그》, 2017-01-10
같이 보기
- 빅데이터
- 배치
- 아파치
- 레이어
- 데이터베이스
- 사물인터넷
- 카파 아키텍처
- 하둡
- 에이치베이스
- 관계형 데이터베이스 관리 시스템
- OLAP
- 알
- 제타 아키텍처
- 애플리케이션
- 맵리듀스
- 하이브
- 아키텍처
- 루씬
- 스트리밍
- 스톰
- 스파크
- 레디스
