대표 번역가 : 오치문


개발자는 문제를 해결하는 사람이라고 믿는, 카페모카를 좋아하는 평범한 개발자.

현재 카카오 검색팀에서 일하고 있으며 문제를 깔끔하게 해결하는데 관심이 많다.


원문 링크





고통기반 프로그래밍 Suffering-oriented Programming

전에 누군가 저에게 흥미로운 질문을 던졌습니다. "스타트업을 하면서 Storm(Storm은 실시간 처리 시스템입니다.)을 만들 때 어떻게 엄청난 위험을 무릅쓰고 진행할 수 있었나요?" 외부 투자자 관점에서 볼 때 스타트업에서 이런 거대한 프로젝트는 매우 위험해 보인다는 것을 저는 알고 있습니다. 하지만 제가 볼때, Storm을 만드는 것은 전혀 위험하지 않았습니다. 그것은 도전적이었지만 위험하지는 않았습니다.

저는 Storm과 같은 거대한 프로젝트를 진행할 때 위험을 크게 줄이는 개발 스타일을 따르는데 이 스타일을 "고통기반 프로그래밍"이라고 부릅니다. 고통기반 프로그래밍은 다음과 같이 요약될 수 있습니다.

  • 어떤 기술이 없어서 고통받는 경우가 아니라면, 그 기술을 구축하지 말아라.

이것은 매일 겪는 프로그래밍에서의 사소한 의사결정뿐만 아니라 대규모의 아키텍처를 결정할 때도 적용됩니다. 고통기반 프로그래밍은 항상 중요한 작업을 하고 있음을 보장함으로써 위험을 크게 줄이고 대규모 투자를 시도하기 전에 문제 영역에 정통할 수 있도록 해줍니다.

고통기반 프로그래밍을 위한 나만의 주문이 있습니다.

  • “일단 돌아가게 만든 다음, 아름답게 만들어라. 그런 다음 빠르게 만들어라."

일단 돌아가게 만들어라 First make it possible 

여러분이 익숙하지 않은 도메인을 만났을 때 바로 '보편적인' 혹은 '확장가능한' 솔루션을 구축하려고 시도하는 것은 실수입니다. 왜냐하면 앞으로 무엇이 필요하게 될지 충분히 예상할만큼 문제 도메인을 잘 이해하고 있지 못하기 때문입니다. 쓸데없이 일반적인 것을 만들게 될 것이고, 이것은 복잡도만 높이고 시간을 낭비하는 것입니다.

그것보다는 바로 '부딪히는 것' 그리고 당면한 문제를 바로 해결하는 것이 더 낫습니다. 이것이 해결하고 싶었던 것을 끝내고 낭비되는 작업을 피할 수 있게 해줍니다. 부딪혀가면서 문제영역의 복잡성에 대해 더 많이 배우게 됩니다.

Storm의 경우 "돌아가게 만들기" 단계는 1년이 걸렸고 큐와 워커를 사용하여 스트림 처리 시스템을 만들었습니다. 우리는 'ack' 프로토콜을 사용해서 데이터 처리를 보장하는 방법을 배웠습니다. 또 큐와 워커로 구성된 클러스터를 이용해서 실시간 처리 시스템을 확장하는 방법을 배웠습니다. 때로는 여러 가지 방법으로 메시지 스트림을 분할해야 하는 경우가 있다는 것을 배웠고, 어떤 때는 무작위로 어떤 때는 동일한 엔티티가 항상 동일한 워커에게 전달되도록 hash/mod 기술(역자 주. 나누기 연산 결과로 얻은 나머지를 워커의 ID처럼 이용해서 특정 워커에게 전달하는 것) 을 사용하는 것을 배웠습니다.

우리는 심지어 "돌아가게 만들기" 단계에 있다는 것조차 모르고 단지 제품을 만드는 데 집중했습니다. 큐와 워커 시스템의 고통은 매우 빠르게 커졌고 시스템을 확장하는 것은 지루한 작업이었으며 내결함성은 우리가 원했던 곳에 없었습니다. 큐와 워커 패러다임은 올바른 추상화 수준에 있지 않았음이 분명했습니다. 대부분의 코드는 우리가 신경썼던 비즈니스 로직보다는 메시지 라우팅과 직렬화와 관련되어 있어야 했습니다.

동시에, 제품 개발을 통해 우리는 '실시간 계산' 문제 영역에서 새로운 유스케이스를 발견했습니다. 우리는 트위터에서 URL의 도달 범위를 계산할 수 있는 기능을 개발했습니다. 도달 범위는 트위터에서 URL에 노출된 고유 사용자 수입니다. 이것은 한 번의 계산을 위해 수 백 번의 데이터베이스 호출과 수 천만 번의 노출을 필요로 하는 어려운 계산 방법입니다. 단일 시스템에서 실행된 초창기 구현은 hard URL들을 처리하는데 1분 정도 걸렸으므로, 계산을 병렬화하여 빠르게 수행할 수 있는 분산 시스템이 필요하다는 것이 명확해졌습니다.

Storm을 촉발시킨 중요한 깨달음 중 하나는 '도달 문제'와 '스트림 처리' 문제가 단순한 추상화로 통일 될 수 있다는 것이 었습니다.

그 다음 아름답게 만들어라 Then make it beautiful

문제를 해결하기 위해 부딪혀가면서 문제 영역의 '지도'를 만들어갑니다. 시간이 지남에 따라 문제 영역 내에서 점점 더 많은 유스케이스들을 습득하고, 이런 시스템을 구축하는 과정에 대해 깊이 이해하게 됩니다. 여기서 얻은 깊은 이해는 기존 시스템을 대체하고, 고통을 덜어 주며, 이전에 구축하기에는 너무 힘들었던 새로운 시스템/기능을 사용한 '아름다운' 기술의 창출을 이끌어낼 수 있습니다.

'아름다운' 솔루션을 개발하는 열쇠는 이미 가지고 있는 구체적인 유스 케이스들을 해결하는 가장 단순한 추상화들의 집합을 찾는 것입니다. 실제로 가지고 있지 않은 유스케이스를 예상하려고 시도하는 것은 실수이며, 솔루션이 오버엔지니어링 될 것입니다. 일반적으로 여러분이 만들려는 것에 투자가 많을수록 문제 영역을 더 깊이 이해해야 하고 사용 사례가 다양해야 합니다. 그렇지 않으면 second-system effect(역자 주. 이전 시스템에서 아쉬웠던 점을 추가하면서 불필요하게 비대한 결과가 만들어지는 것)가 발생할 위험이 있습니다.

'아름답게 만들기'는 디자인과 추상화 기술을 사용하여 문제 영역을 함께 조합될 수 있는 단순한 추상화 집합으로 정제하는 것입니다. 저는 통계적 회귀와 유사한 아름다운 추상화의 진화를 봅니다. 그래프 위의 점들(유스케이스)을 가지고 그 점에 맞는 가장 단순한 곡선(추상화 집합)을 찾고 있습니다.

여러분이 가진 유스케이스가 많을수록 그 점에 맞는 올바른 곡선을 찾을 수 있습니다. 충분한 점을 갖지 못하면, 이상적인 그래프보다 올라가거나(overfit) 내려가기(underfit) 때문에, 헛된 작업과 오버엔지니어링으로 이어지게 됩니다.

아름답게 만드는 단계에서 큰 비중을 차지하는 부분은 문제 영역의 성능 및 리소스 특성을 이해하는 것입니다. 이것은 "돌아가게 만들기" 단계에서 배우는 복잡함 중 하나이며, 아름다운 솔루션을 디자인 할 때 학습한 것을 활용해야만 합니다.

저는 Storm을 사용하여 실시간 컴퓨팅 문제 영역을 스트림, 스파우트, 볼트 및 토폴로지와 같은 작은 추상화 집합으로 정제 했습니다. 저는 시스템에서 가장 복잡하고 고통스러운 부분인 중간 메시지 브로커가 필요 없으면서도 데이터 처리를 보장할 수 있는 새로운 알고리즘을 고안했습니다. 표면상으로 볼 때 매우 다른 스트림 처리와 도달 문제가 너무 우아하게 매핑되었고 Storm은 제가 대단한 일에 몰두하고 있다는 강력한 지표였습니다.

저는 Storm에 대한 더 많은 유스케이스를 확보하고 디자인을 검증하기 위해 추가 조치를 취했습니다. 다른 엔지니어들이 실시간 문제에서 다루었던 상세한 내용들을 배우기 위해 조사했습니다. 아는 사람들에게 바로 물어보지 않았습니다. 저는 또한 새로운 실시간 시스템을 만들고 있다는 것과 다른 사람들의 유스케이스에 대해 배우고 싶다는 것을 트위터에 올렸습니다. 이로 인해 흥미로운 토론이 많이 이뤄져서 문제 영역에 대해 더 많이 배울 수 있었고 저의 디자인 아이디어들을 검증할 수 있었습니다.

그 다음 빠르게 만들어라 Then make it fast 

아름다운 디자인을 완성한 후에는 프로파일링 및 최적화에 시간을 투자할 수 있습니다. 최적화를 너무 일찍하면 시간을 낭비할 수 있는데 그 이유는 여러분이 여전히 디자인을 변경할 수 있기 때문입니다. 이것을 조숙한 최적화라고 합니다.

"빠르게 만들기"는 시스템에서 높은 수준의 성능 특성에 관한 것이 아닙니다. 이러한 문제들을 이해하는 것은 " 돌아가게 만들기" 단계에서 습득하고 "아름답게 만들기" 단계에서 설계 되어야 합니다. "빠르게 만들기"는 마이크로 최적화에 관한 것이고 코드를 강화하여 리소스를 보다 효율화하는 것입니다. 따라서 당신은 "아름답게 만들기" 단계에서는 점근적 복잡도와 같은 것을 고려하고, "빠르게 만들기" 단계에서는 상수시간 요소들에 대해 집중하게 될 것입니다.

개선 그리고 반복 Rinse and repeat 

고통기반 프로그래밍은 지속적인 프로세스입니다. 당신이 구축한 아름다운 시스템은 문제 공간의 새롭고 깊은 영역에서 "돌아가게 만들기"를 시작할 수 있는 새로운 가능성을 제시합니다. 이것은 기술에 대한 학습을 유도합니다. 여러분은 점점 더 많은 유스케이스를 처리하기 위해 이미 찾아낸 추상화를 조정하거나 추가해야 합니다.

Storm은 이런 식으로 많은 반복 작업을 거쳤습니다. Storm을 처음 사용하기 시작했을 때, 우리는 단일 구성 요소에서 여러 개의 독립적인 스트림을 방출 할 수 있는 기능이 필요하다는 것을 알았습니다. 우리는 'direct stream'이라는 특별한 종류의 스트림을 추가하면 Storm이 튜플의 배치를 개별 단위로 처리수 있음을 발견했습니다. 최근에 저는 Storm의 '최소 한 번 처리 보장'을 뛰어 넘으며 거의 임의의 실시간 계산을 위해 '정확히 한 번 메시징'이 허용되는 '트랜잭션 토폴로지'를 개발했습니다.

본질적으로, 여러분이 잘 이해하지 못하는 문제 영역에서 문제를 헤쳐나가고 계속해서 반복하다보면 코드가 엉성해질 수 있습니다. 고통기반 프로그래머의 가장 중요한 자질은 리팩토링에 끈질기게 주력하는 것입니다. 이것은 코드베이스를 망침으로 인해 발생하는 accidental complexity(역자 주. 엔지니어들에 의해 발생되고 고칠수 있는 문제)을 막기 위해 매우 중요합니다.

결론

유스케이스는 고통 기반 프로그래밍의 모든 것입니다. 유스케이스들은 마치 황금과 같은 가치가 있습니다. 유스케이스를 얻는 유일한 방법은 부딪혀가면서 경험을 쌓는 것입니다.

대부분의 프로그래머가 겪는 특정한 진화가 있습니다. 당신은 일을 시작하고 처음 코드에서는 구조란걸 찾아볼 수 없습니다. 코드가 엉성하고 복사/붙여넣기가 만연합니다. 마침내 구조화된 프로그래밍과 공유할 수 있는 로직의 이점에 대해 가능한만큼 배우게 됩니다. 그런 다음 포괄적인 추상화를 만들고, 캡슐화를 통해 시스템을 쉽게 추론 할 수 있는 방법에 대해 배웁니다. 그 후에 여러분은 프로그램이 미래에도 경쟁력을 갖출 수 있게 확장가능하도록 만드는 것과 코드를 일반화시키는 것에 사로잡히게 됩니다.

고통기반 프로그래밍은 여러분이 현재 가지고 있지 않은 요구를 효과적으로 예상할 수 있다는 것을 부인합니다. 이것은 문제 영역에 대한 깊은 이해없이 일을 일반화하려는 시도는 복잡성과 낭비로 이어질 것이라는 점을 깨닫게 해줍니다. 디자인은 항상 실질적이고 실제적인 유스케이스에 의해 주도되어야 합니다.


설정

트랙백

댓글








대표 번역가 : 백재영


실리콘밸리를 꿈꾸는 개발자.
현재 LF 플랫폼 개발팀에서 있으며 요즘은 번역의 어려움과 재미를 한창 느끼는 중이다. 


원문 링크





스프링 빈이 진짜 뭘까?


오늘 Spring Boot Application 내부에서 무슨 일이 벌어지고 있는지 이해하려고 하는 중 멘붕이 왔다.


스프링을 처음 접하면서 꽤 많은 시간을 구글링과 문서 읽기에 쏟아부었지만 ‘빈'과 같은 기본적인 개념에 관해서는 사전지식을 전제로 한다고 알고 있었다.


Pivotal의 스프링 팀에 있는 내 친구이자 동료인 Mark Fisher가 내게 찾아와 설명해주는 대신 나는 이것에 대해 글을 쓰기로 약속했다.


그 결과는 지금 보고 있는 이 블로그와 여기에 있다. https://github.com/markfisher/spring-boot-hello-world


태초에 XML이 있었다

스프링은 자바 애플리케이션이 종속된 메인 클래스를 구성하는 데에 J2EE보다 더 간단한 XML 기반의 방식을 제공한다.


단순히 모든 것을 자바의 new를 이용하여 인스턴스화하는 것은 이상적인 것이 아니었다. 이는 모든 종속성을 코드에 기술해야하므로 로컬 테스트를 위한 데이터베이스와 CI 또는 프로덕션을 위한 다른 데이터베이스를 쉽게 사용할 수 없었기 때문이다.


데이터베이스 커넥션같은 것들을 추상화한 자신만의 팩토리를 만드는 대신, 스프링은 이 모든 것들을 XML 하나로 제공한다.


스프링은 구동시 환경에 특정한 XML을 읽어들이고 XML에 있는 것들을 기반으로 해당 클래스의 인스턴스를 생성한다.

 

그리고 이런 인스턴스들은... 이런 식의 (beans)이다.

 

ApplicationContext.getBean()

 

지금은 @Annotation이다

세월이 흘러 XML은 @Configuration @ConfigurationProperties 같은 주석이 달린 자바 코드로 대체되었다.

 

Screen Shot 2017-10-11 at 10.11.48 PM.png


팩토리 메소드에 @Bean이 달린 것에 주목하라.


설정 클래스가 META-INF/spring.factories에 포함되어 있으면, 스프링 부트 애플리케이션은 시작시 자동으로 팩토리 메소드를 호출하여 해당 클래스의 싱글턴 인스턴스를 생성한다.


이건 마법이다

그리고 이런 인스턴스는 여전히 이라 불린다


Spring Initializr와 모든 starter들은 다 뭐냐고?

이제 configuration scanning이 뭔지 알았으니 스프링 부트 스타터의 역할은 더 이해하기 쉬울 것이다.


스프링 부트 애플리케이션의 종속성에 스타터를 포함시킴으로써 스프링은 스타터 내부의 설정 클래스를 검색하여 해당 스타터에 대한 을 자동으로 생성하게 된다.

 

Initializr injection

짠!



설정

트랙백

댓글









대표 번역가 : 오치문


개발자는 문제를 해결하는 사람이라고 믿는, 카페모카를 좋아하는 평범한 개발자.

현재 카카오 검색팀에서 일하고 있으며 문제를 깔끔하게 해결하는데 관심이 많다.


원문 링크





데이터 레이크


데이터 레이크(Data Lake)는 빅데이터(Big Data) 세계에서 데이터 분석 파이프 라인의 중요한 구성 요소 중 하나를 설명하기 위해 최근 10년간 등장한 용어입니다. 이것은 조직에서 누구나 분석할 때 필요한 모든 원시 데이터를 저장하는 단일 저장소를 갖는 것을 의미합니다. 일반적으로 사람들은 레이크(단일 저장소)의 데이터를 처리하기 위해서 하둡을 사용하지만, 데이터 레이크의 개념은 하둡보다 광범위합니다.

 

조직에서 분석하고자 하는 모든 데이터를 한 곳에 모은다고 들었을 때, 저는 바로 데이터 웨어하우스(그리고 데이터 마트[1])의 개념이 생각났습니다. 그러나 데이터 레이크와 데이터 웨어하우스 간에는 중요한 차이점이 있습니다. 데이터 레이크는 그것이 어떤 형태든, 데이터 소스가 제공하는 그대로의 원시 데이터를 저장합니다. 데이터 스키마에 대한 가정은 없으며 각 데이터 소스는 원하는 스키마를 사용할 수 있습니다. 따라서, 자신의 목적에 맞게 데이터를 이해하는 것은 데이터 소비자에게 달려있습니다.

Screen Shot 2017-06-29 at 11.08.09 AM.png

 

이것은 기존에 비해 진일보 한 것인데, 많은 데이터 웨어하우스들은 스키마 문제로 인해 멀리 가지 못했습니다. 데이터 웨어하우스는 모든 분석 요구에 대해 하나의 스키마 개념을 사용하는 경향이 있습니다. 저의 견해는 이런 단일 통합 데이터 모델은 아주 작은 조직을 제외하면 비현실적이라는 것입니다. 조금이라도 복잡한 도메인을 모델링하려면 각각의 데이터 모델과 함께 여러 개의 BoundedContext가 필요합니다. 분석 측면에서 보면, 자신이 수행 중인 분석에 적합한 모델을 사용하는 여러 분석가들이 필요합니다. 원시 데이터만 저장하도록 전환하면 데이터 분석가가 이 책임(각 컨텍스트에 맞게 이해하고 모델링 하는 것)을 지게 됩니다.

 

데이터 웨어하우스의 또 다른 문제점은 데이터 품질을 보장하는 것입니다. 데이터에 대해서 신뢰할 수 있는 하나의 소스를 얻으려면, 다른 시스템에서 어떻게 데이터를 수집하고 사용하는지에 대해 많은 분석이 필요합니다. 어떤 데이터에는 시스템 A가 좋고, 다른 데이터에는 시스템 B가 좋을 수 있습니다. 예를 들면, 시스템 A는 더 최근의 주문에 대해 좋을 수 있지만, 반품이 포함되지 않은 조건에서 한 달 또는 그 전의 주문에 대해서는 시스템 B가 더 좋을 수 있습니다. 무엇보다도, 데이터 품질은 종종 주관적인 문제이며, 각 분석마다 데이터 품질 문제에 대해 서로 다른 허용 오차를 가집니다. 심지어 무엇이 좋은 품질이냐에 대한 개념도 다릅니다.

 

이것은 데이터 레이크에 대한 흔한 비평을 야기합니다. 단지 광범위한, 다양한 품질의 데이터 쓰레기장이라는 것, 좋게 말해 데이터의 늪이라는 비평입니다. 비평은 타당하면서도 부적절합니다. 새로운 분석론에서 화제가 되고 있는 명칭이 ‘Data Scientist’입니다. 비록 이것이 남용되고 있는 명칭이지만, 여기에 속한 많은 사람들이 과학 분야에서 견고한 배경을 가지고 있습니다. 그리고 어떤 훌륭한 데이터 과학자는 데이터 품질 문제에 대해 모든 것을 알고 있습니다. 시간이 지남에 따라 온도 판독 값을 분석하는 간단한 문제를 생각해 봅시다. 측정치에 미묘하게 영향을 미치거나, 장비의 문제로 인한 이상, 센서가 작동하지 않는 기간 등의 이유로 일부 기상 관측소의 이전을 고려해야만 합니다. 하지만 많은 정교한 통계 기술이 데이터 품질 문제를 해결하기 위해 만들어졌기 때문에 이런 문제를 해결할 수 있습니다(즉, 어느 정도 오차가 있어도 관측소를 이전하지 않아도 됩니다). 데이터 과학자들은 항상 데이터 품질에 회의적이며, 의심스러운 데이터를 다루는 데 익숙합니다. 그래서 그들에게 데이터 레이크는 중요합니다. 왜냐하면 그들은 원시 데이터로 작업을 하고, 불명료한 데이터를 정제하는 메커니즘보다는, 데이터를 이해하기 위해서 더 나은 분석기술을 적용하는 것을 신중하게 고려해볼 수 있기 때문입니다.

(역자 주. 간단히 정리하면, 저자는 데이터 쓰레기장이라는 비평에 대해서, 데이터 레이크에 다양한 품질의 데이터가 섞여있는 것은 인정하지만 데이터 분석 기술로 커버할 수 있다는 것을 이야기 하고싶은 것같습니다.)

 

일반적으로 데이터 웨어하우스는 단순히 데이터를 정제하는 것뿐만 아니라 분석하기 용이한 형태로 모읍니다. 그러나 이 과정에서 데이터의 일부가 버려질 수 있기 때문에 데이터 과학자들은 이점에 대해서도 반대하는 경향이 있습니다. 데이터 레이크는 반드시 모든 데이터를 저장하고 있어야 하는데, 그 이유는 어떤 사람이 오늘 혹은 2년 내의 데이터에서 가치를 찾아낼지 모르기 때문입니다.

 

저의 동료 중 한 명이 최근의 한 사례를 들어 이 점에 대해 설명했습니다.

“우리는 우리의 자동 예측 모델과 회사의 계약 관리자들이 작성한 수동 예측을 비교하려고 했습니다. 그러기 위해서 우리의 모델을 당시의 데이터로 학습시키고, 우리의 예측 결과와 그 당시 관리자들의 예측 결과를 비교하려고 했습니다. 우리는 지금 정답을 알고 있기 때문에, 이 방법은 정확도 시험에 적합했습니다. 이 시험을 시작했을 때, 관리자들의 예측은 끔찍했고 불과 2주 만에 만들어진 우리의 단순한 모델 조차도 그들의 예측보다 나았습니다. 우리는 이 엄청난 성과를 사실로 받아 들이기에는 의심스럽다고 생각했습니다.

많은 테스트와 분석 후에 우리는 관리자의 예측들과 관련된 타임 스탬프가 잘못되었다는 것을 알게 되었습니다. 이 값들은 월 말 처리 보고서에 의해 수정되었던 것입니다. 간단히 말해서, 데이터 웨어하우스에 저장된 예측 값들은 쓸모가 없었습니다. 우리는 예측 비교를 수행할 방법이 없을 것이라고 우려했습니다. 더 많은 분석 후에 우리는 이 보고서가 저장되어 있는 것을 발견했고, 그 당시의 실제 예측을 추출할 수 있었습니다. (우리는 다시 관리자들의 예측보다 나은 결과를 얻었지만, 여기에 많은 시간이 필요했습니다).”

 

원시 데이터의 복잡성은 데이터를 보다 관리하기 쉬운 구조로 조정할 수 있는 여지가 있음을 의미합니다(또한 상당한 양의 데이터를 줄일 수 있습니다). 데이터 레이크에는 직접 접근하도록 해서는 안됩니다. 데이터 레이크에 저장된 가공되지 않은 데이터(원시 데이터)를 이해하기 위해서는 많은 기술이 필요합니다. 데이터 레이크를 이용해서 일하는 비교적 적은 사람들이 레이크에 있는 데이터로 일반적으로 유용한 뷰를 발견합니다. 또한 그들은 많은 양의 데이터 마트들을 만들어내는데, 각각의 데이터 마트는 하나의 bounded context에 맞는 특정한 모델을 갖습니다. 그렇게 되면 많은 다운스트림 사용자들이 이런 레이크쇼어 마트들을 각 컨텍스트에 맞는 신뢰성 있는 데이터 소스로 취급할 수 있습니다.

Screen Shot 2017-06-29 at 11.08.39 AM.png

지금까지 저는 데이터 레이크를 기업 전체의 데이터를 통합하는 단일 지점으로 설명했지만, 이것이 원래 의도 된 것은 아니라는 점을 이야기 해야겠습니다. 데이터 레이크는 James Dixon이 2010년에 처음으로 쓴 표현인데, 그의 의도는 데이터 레이크가 하나의 데이터 소스로 사용되는 것이고, 여러 개의 데이터 소스가 ‘water garden’으로 형성되는 것이었습니다. 이런 기원에도 불구하고, 지금은 일반적으로 데이터 레이크가 많은 데이터 소스들을 통합하는 것으로 사용되고 있습니다. [2]

 

데이터 레이크를 분석 목적으로만 사용하고 운영 시스템들 간의 연동을 위해 사용해서는 안됩니다. 운영 시스템과의 연동은 이 목적으로 설계된 RESTful HTTP 호출이나, 비동기 메시징 같은 서비스들을 이용해야 합니다. 데이터 레이크는 운영용 통신망으로 사용 하기에는 너무 복잡합니다. 데이터 레이크의 분석으로 인해 새로운 운영 통신 경로가 만들어질 수 있지만, 이런 것들은 데이터 레이크를 통해서 하기보다는 직접 구축해야 합니다.

 

데이터 레이크로 유입되는 모든 데이터가 장소와 시간에 대해 명확한 출처를 가져야 한다는 것은 매우 중요합니다. 모든 데이터에는 데이터가 어떤 시스템으로부터 유입되었는지, 그리고 언제 데이터가 생성 되었는지에 대한 명확한 흔적이 있어야 합니다. 그러므로 데이터 레이크는 역사적인 기록을 포함합니다. 이런 기록들은 아마도 Event Sourced 시스템과 자연스럽게 어울리는 도메인 이벤트들을 데이터 레이크에 저장할 때 발생할 것입니다. 하지만, 현재의 상태를 데이터 레이크로 정기적으로 덤핑하는 시스템에서도 역시 발생할 수 있습니다(소스 시스템에 시간과 관련된 것은 없지만, 시간에 따른 데이터 분석이 필요할 때 유용한 접근방식). 이에 따른 결과로, 데이터 레이크에 입력된 데이터는 변경되지 않고, 한 번 기술된 기록은 삭제될 수 없으며(나중에 잘못된 것으로 판별될 수는 있지만), Contradictory Observations(모순된 관찰)를 예상해야만 합니다(예를 들어, 같은 id로 처음에 들어온 값과 나중에 들어온 값이 달라질 수 있는 문제).

 

데이터 레이크는 스키마가 없으므로, 어떤 스키마를 사용할지는 소스 시스템에 달려 있고, 스키마가 없음으로 인해 발생하는 혼란을 처리하는 방법은 데이터 소비자가 결정해야 합니다. 게다가 소스 시스템은 자신이 유입시키는 데이터 스키마를 자유롭게 변경할 수 있으며, 소비자는 이에 대처해야 합니다. 당연히 우리는 가능한 한 최소한의 영향을 미치는 변화를 선호하지만, 데이터 과학자들은 데이터를 잃어버리는 것보다는 차라리 지저분한 데이터를 선호합니다.

 

데이터 레이크는 매우 커질 것이고, 저장소의 대부분은 스키마 없는 큰 규모의 구조를 지향합니다. 이것이 일반적으로 사람들이 데이터 레이크를 구현하는 기술로 하둡과 HDFS를 사용하는 이유입니다. 레이크쇼어  마트들의 중요한 작업 중 하나는 처리해야 하는 데이터의 양을 줄이는 것입니다. 그렇게 함으로써 대용량 데이터 분석에서는 많은 양의 데이터를 처리할 필요가 없게 됩니다.

 

원시 데이터의 범람에 대한 데이터 레이크의 욕망은 개인정보와 보안에 관해 난처한 질문을 야기합니다. Datensparsamkeit(독일어. 데이터를 캡처하고 저장하는 방법에 대한 자세로서 우리가 실제로 필요한 데이터만 처리해야 한다는 내용)의 원칙은 모든 데이터를 캡처하려는 데이터 과학자들의 욕구와 대치됩니다. 데이터 레이크는 공개된 바다를 선택하는 것을 좋아하는 크래커들에게 유혹의 대상이 됩니다. 소규모 데이터 과학 그룹에 한해서 데이터 레이크에 직접 접근하도록 제한하면 이 위협이 줄어들지만, 이 그룹이 항해 중인 데이터의 개인 정보 보호에 대해 어떻게 책임을 질 수 있는지에 대한 질문을 피할 수 없습니다.

 

 

Note

1 : 데이터 마트는 조직에서 단일 부서를 위한 것인 반면, 데이터 웨어하우스는 전 부서를 아우르는 통합을 위한 것이 일반적인 구분입니다. 데이터 웨어하우스가 모든 데이터 마트의 조합이 되어야 하는지, 아니면 데이터 마트를 데이터 웨어하우스에 존재하는 데이터의 논리적 하위 집합(뷰)으로 볼 것인지에 대해서는 서로 다른 의견들이 존재합니다.

 

2 : 이후의 블로그 포스트에서 Dixon은 데이터 레이크와 ‘water garden’의 구별을 강조하지만, (주석에서) 그것은 사소한 변화라고 말합니다. 제가 생각할 때 핵심은 데이터 레이크가 많은 양의 데이터를 가공되지 않은 상태로 저장한다는 것이고, 피더 스트림의 수는 별로 중요하지 않다는 것입니다.

 

감사 인사

Danielo Sato, David Johnston, Derek Hammer, Duncan Cragg, Jonny Leroy, Ken Collier, Shripad Agashe 및 Steven Lowe에게 내부 메일링 리스트에서 이 게시물의 초안을 논의한 것에 대해 감사의 말을 전합니다.

 

 

설정

트랙백

댓글