람다 아키텍처를 적용하는 프로젝트를 빌드하는 경우 배치 레이어와 제공 레이어를 분리해야합니까? 즉, 프로그램 A는 배치 레이어의 작업을 수행하고 프로그램 B는 제공 레이어를 처리합니까? 프로그램 A는 A가 사전 계산 작업을 완료 한 후에 B가 작동하도록 알 수 있기 때문에 물리적으로는 독립적이지만 논리적으로 관련이 있습니다.람다 아키텍처 batch_layer 및 serving_layer를 구현하는 가장 좋은 방법은 무엇입니까?
그렇다면 구현 방법을 알려주시겠습니까? 나는 IPC에 대해 생각하고있다. IPC가 도움을 줄 수 있다면 구체적인 방법은 무엇입니까?
그런데 "배치보기"는 정확히 무엇을 의미합니까? 왜 그리고 무엇을 서빙 계층이 그것의 색인을 생성합니까?
람다 아키텍처 batch_layer 및 serving_layer를 구현하는 가장 좋은 방법은 무엇입니까? 그것은 전적으로 특정 요구 사항, 시스템 환경 등에 달려 있습니다. 나는 람다 아키텍쳐 batch_layer와 serving_layer를 디자인하는 방법을 설명 할 수있다.
덧붙여서, 저는 어제 동료와 논의 중이었습니다. 이것은 그 토론을 기반으로합니다. 3 부분으로 설명하고이 토론을 위해 하루 중 가장 읽기 좋은 이야기 (a), 이번주의 (b), 올해의 (c)를 계산하는 시스템을 설계하는 데 관심이 있다고 가정 해 보겠습니다.
먼저 람다 아키텍처에서 해결해야 할 문제를 시간에 대해 먼저 나누고 두 번째를 특징 화하는 것이 중요합니다. 따라서 데이터를 수신 스트림으로 모델링하면 속도 레이어는 스트림의 '헤드'를 처리합니다 (예 : 당일의 데이터; 배치 레이어는 'head'+ 'tail'을 처리합니다.
둘째, 이러한 시간 기반 라인간에 기능을 나누십시오. 예를 들어 일부 기능은 스트림의 '헤드'만 사용하여 수행 할 수 있지만 다른 기능은 '헤드'보다 더 광범위한 데이터를 필요로합니다. masterset. 이 예에서는 하루 동안의 데이터를 계산하기 위해 속도 계층을 정의한다고 가정 해 보겠습니다. 그런 다음 Speed 레이어는 소위 속도보기에서 하루의 대부분의 읽기 기사 (a)를 계산합니다. 일괄 처리 계층은 소위 일괄 처리보기에서 일, 월 및 일의 대부분의 읽기 기사 (a)를 계산합니다. 네, 약간의 중복성이 있지만 그 생각을 견지 할 수 있습니다.
세 번째로 속도보기 및 일괄보기와 관련된 클라이언트의 쿼리에 계층 응답을 제공하고 이에 따라 결과를 병합합니다. 속도보기 및 배치보기의 결과에는 반드시 중복이 있습니다. (1) 버그 공개, (2) 데이터 전달 손상, (3) 장기 실행 배치 프로세스 등과 같은 위험에 대한 노출을 최소화 할 수 있습니다. 속도보기에서 문제가 발견되면 배치보기 재 계산 이전에 수정 사항이 적용됩니다. 그렇다면 모두 좋고 좋다.
요약하면 IPC는 서로 완전히 독립적이기 때문에 사용할 필요가 없습니다. 따라서 프로그램 A는 프로그램 B와 통신 할 필요가 없습니다. 대신 시스템은 처리의 일부 중첩에 의존합니다. 예를 들어 프로그램 B가 일별 기준으로 일괄 뷰를 계산하면 프로그램 A는 일별 속도보기와 처리에 소요되는 추가 시간을 더한 값을 계산해야합니다. 이 추가 시간에는 배치 레이어의 중단 시간이 포함되어야합니다.
희망이 도움이됩니다.
참고 : 배치 층의
배치보기는 마스터 세트에 대한 쿼리를 보유하는 배치 레이어의 하위 집합입니다. 일반 쿼리를 수행 할 때 실제로 수행중인 작업은 해당 배치 뷰 (서빙 계층)를 쿼리하고 속도 계층 뷰 (속도 계층에서 생성)를 쿼리하는 것입니다. 배치 레이어는 사용자가 선언 한 마스터 세트의 일반 형식이며 전체 저장된 데이터를 보유합니다. –