아래 그림과 같이 처음에 우리는 전형적인 대형 인터넷 데이터 플랫폼 아키텍처를 보면 :
갈색 밖으로 사용자의 온라인 비즈니스 처리 구성 요소에 표시이 아키텍처 다이어그램, 빅 데이터 플랫폼,이 부분은 빅 데이터 관련 구성 요소의 파란색 부분의 다른 부분에 속하는 온라인 애플리케이션에 대한 인터넷의 일부, 오픈 소스 빅 데이터 제품의 사용 또는 자신의 큰 데이터 관련 구성 요소를 개발한다.
데이터 수집, 데이터 처리, 출력, 표시 데이터 : 볼 수있는 바와 같이, 위에서 아래로 큰 인터넷 데이터는 세 부분으로 나눌 수있다.
데이터 수집
애플리케이션은 데이터를 생성하고, 대규모 시스템에 등시성 데이터를 로그 데이터 동기화 시스템이 실제로 관련 시스템의 복수의 조합의 다른 데이터 소스 때문이다. 데이터베이스 동기화 후 메시지 큐 카프카 등을 통해 송신되는 데이터 포맷으로 변환 로깅 플룸을 선택 동기 로그 Sqoop을 보통이다.
널리 다를 수 있습니다 다른 데이터 소스에 의해 생성 된 데이터의 품질은, 데이터베이스의 데이터를 직접 사용할 준비가 큰 데이터 시스템을 가져올 수 있으며, 로그 및 파충류 생성 된 데이터가 청소를 많이 필요로 변환 처리를 효율적으로 사용할 수 있습니다.
데이터 처리
이것은 데이터 저장 시스템 리드 HDFS 큰 데이터 저장 및 계산, 데이터 동기화의 핵심이다. MapReduce의 하이브가 계산된다 HDFS의 데이터를 판독하기 위해 다른 컴퓨팅 작업을 점화하고 HDFS에 결과를 기록한다.
MapReduce의 하이브 스파크 연산 처리 등이 같은 오프라인 계산 칭한다는 데이터 저장을 HDFS 오프라인 데이터라고한다. 오프 - 라인 계산이 일반적으로 모든 주문 상품 연관 마이닝 과거 모든 데이터 (의 일 개 측면)에 대한 대규모 데이터 시스템에서 수행되는 데이터가 매우 큰 이번에는 이러한 계산을 실행하는 시간이 오래 걸리는 오프라인 컴퓨팅이다.
오프라인 컴퓨팅 외에도 몇 가지 시나리오가있는 데이터의 크기는 상대적으로 크지 만, 처리 시간이 비교적 짧은 요구한다. 이러한 모니터링은 Taobao로지지 초당 생성 명령의 수를 카운트한다. 이 시나리오는 대규모 데이터 스트림은 일반적 폭풍, 엔진이 초 또는 밀리 초 단위의 계산 된 시간 내에 완료 할 수 있습니다 완료 김이 다른 대형 데이터 스트림 스파크, 계산이라고합니다.
데이터 출력 및 디스플레이
결과 데이터를 계산하기위한 대형 데이터 또는 HDFS로 작성하지만, 응용 프로그램은 HDFS의 데이터베이스로 데이터를 내보내려면 HDFS에 데이터를 읽고, 그렇게해야 없습니다. 데이터 동기화를 내보내기 더 표준화 된 데이터베이스와 약간의 처리 진행 Sqoop을 좋아하는 시스템으로 내보낼 수 있습니다 계산 된 데이터를 생성하기가 비교적 쉽다.
이 때, 응용 프로그램이 권장 제품과 관련된 사용자에게 표시 등, 사용자에게 데이터베이스, 실시간 디스플레이에 직접 데이터에 액세스 할 수 있습니다.
사용자 액세스 데이터를 제공 할뿐만 아니라, 대용량 데이터도 적절한 백엔드 시스템을 액세스하고 운영 및 의사 결정 통계 보고서를, 데이터는 또한 데이터베이스에 기록됩니다의 다양한 제공해야합니다. 많은 사업자 및 관리 인원, 작업 매일, 정상 사업 여부를 확인하기 위해, 전날의 데이터 보고서를 보려면 로그인 백 엔드 데이터 시스템이다. 데이터가 정상 또는 증가하는 경우, 당신은 약간의 휴식을 취할 수 있으며, 데이터가 떨어질 경우, 불안하고 바쁜 하루가 시작됩니다.
다른 데이터 동기화, 맵리 듀스의 다양한 시작할 때 위의 세 부분은 일정 관리 시스템을 통합하는 것입니다, 자원, 시간의 가장 합리적인 사용을하고, 너무 오래 기다리지 일시적 동안하지 않습니다 어떻게 합리적인 작업 스케줄링 불꽃 또한 중요한 작업을 완료하는 작업 일정 관리 시스템을 필요로하는, 가능한 한 빨리 실행할 수 있습니다.
또한 람다 아키텍처라고도 대용량 데이터 플랫폼 아키텍처 위에서 언급 한, 그것은 종래의 아키텍처 프로토 프로그램 큰 데이터 플랫폼을 구성한다. 람다 아키텍처 프로토 타입은 다음과 같은 차트를 봐.
람다 구조
람다 아키텍처 (람다 아키텍처)는 트위터 엔지니어 난센 매트 (나단 년 3) 빅 데이터 처리 아키텍처 제안한다. 이 경험과 마츠 트위터 BackType 분산 데이터 처리 시스템 아키텍처를 기반으로했다.
람다 아키텍처는 개발자들이 대규모 분산 데이터 처리 시스템을 구축 할 수 있습니다. 그것은 좋은 유연성과 확장 성을 가지고뿐만 아니라 하드웨어 오류와 실수에 대한 좋은 내결함성을 가지고있다.
세 가지 시스템의 총의 람다 아키텍처 : 일괄 층 (일괄 층), 쿼리에 대한 응답에서뿐만 아니라 서비스 계층 (서빙 계층)에 대한 처리 계층 (속도 레이어)의 속도입니다.
람다 아키텍처에서, 각 계층은 자신의 작업을 어깨 있습니다.
배치 마스터 데이터 스토리지 관리 계층 (불변의 데이터 세트)와 미리 계산 된 배치 뷰를 설정.
批处理层使用可处理大量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的，能够修复任何错误，然后更新现有的数据视图。输出通常存储在只读数据库中，更新则完全取代现有的预先计算好的视图。
速度处理层会实时处理新来的大数据。
速度层通过提供最新数据的实时视图来最小化延迟。速度层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整，但它们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后，在速度层的数据就可以被替代掉了。
本质上，速度层弥补了批处理层所导致的数据视图滞后。比如说，批处理层的每个任务都需要 1 个小时才能完成，而在这 1 个小时里，我们是无法获取批处理层中最新任务给出的数据视图的。而速度层因为能够实时处理数据给出结果，就弥补了这 1 个小时的滞后。
所有在批处理层和速度层处理完的结果都输出存储在服务层中，服务层通过返回预先计算的数据视图或从速度层处理构建好数据视图来响应查询。
例如广告投放预测这种推荐系统一般都会用到Lambda架构。一般能做精准广告投放的公司都会拥有海量用户特征、用户历史浏览记录和网页类型分类这些历史数据的。业界比较流行的做法有在批处理层用Alternating Least Squares (ALS)算法，也就是Collaborative Filtering协同过滤算法，可以得出与用户特性一致其他用户感兴趣的广告类型，也可以得出和用户感兴趣类型的广告相似的广告，而用k-means也可以对客户感兴趣的广告类型进行分类。
这里的结果是批处理层的结果。在速度层中根据用户的实时浏览网页类型在之前分好类的广告中寻找一些top K的广告出来。最终服务层可以结合速度层的top K广告和批处理层中分类好的点击率高的相似广告，做出选择投放给用户。
Lambda 架构的不足
虽然 Lambda 架构使用起来十分灵活，并且可以适用于很多的应用场景，但在实际应用的时候，Lambda 架构也存在着一些不足，主要表现在它的维护很复杂。
使用 Lambda 架构时，架构师需要维护两个复杂的分布式系统，并且保证他们逻辑上产生相同的结果输出到服务层中。
我们都知道，在分布式框架中进行编程其实是十分复杂的，尤其是我们还会针对不同的框架进行专门的优化。所以几乎每一个架构师都认同，Lambda 架构在实战中维护起来具有一定的复杂性。
那要怎么解决这个问题呢？我们先来思考一下，造成这个架构维护起来如此复杂的根本原因是什么呢？
维护 Lambda 架构的复杂性在于我们要同时维护两套系统架构：批处理层和速度层。我们已经说过了，在架构中加入批处理层是因为从批处理层得到的结果具有高准确性，而加入速度层是因为它在处理大规模数据时具有低延时性。
那我们能不能改进其中某一层的架构，让它具有另外一层架构的特性呢？
例如，改进批处理层的系统让它具有更低的延时性，又或者是改进速度层的系统，让它产生的数据视图更具准确性和更加接近历史数据呢？
另外一种在大规模数据处理中常用的架构——Kappa 架构（Kappa Architecture），便是在这样的思考下诞生的。
Kappa 架构
Kappa 架构是由 LinkedIn 的前首席工程师杰伊·克雷普斯（Jay Kreps）提出的一种架构思想。克雷普斯是几个著名开源项目（包括 Apache Kafka 和 Apache Samza 这样的流处理系统）的作者之一，也是现在 Confluent 大数据公司的 CEO。
克雷普斯提出了一个改进 Lambda 架构的观点：
我们能不能改进 Lambda 架构中速度层的系统性能，使得它也可以处理好数据的完整性和准确性问题呢？我们能不能改进 Lambda 架构中的速度层，使它既能够进行实时数据处理，同时也有能力在业务逻辑更新的情况下重新处理以前处理过的历史数据呢？
他根据自身多年的架构经验发现，我们是可以做到这样的改进的。
像 Apache Kafka 这样的流处理平台是具有永久保存数据日志的功能的，通过平台的这一特性，我们可以重新处理部署于速度层架构中的历史数据。
下面就以 Apache Kafka 为例来讲述整个全新架构的过程。
及时获取更多大数据技术分享，请关注我的微信公众号《大数据技术进阶》
第一步，部署 Apache Kafka，并设置数据日志的保留期（Retention Period）。这里的保留期指的是你希望能够重新处理的历史数据的时间区间。
例如，如果你希望重新处理最多一年的历史数据，那就可以把 Apache Kafka 中的保留期设置为 365 天。如果你希望能够处理所有的历史数据，那就可以把 Apache Kafka 中的保留期设置为“永久（Forever）”。
第二步，如果我们需要改进现有的逻辑算法，那就表示我们需要对历史数据进行重新处理。
我们需要做的就是重新启动一个 Apache Kafka 作业实例（Instance）。这个作业实例将从头开始，重新计算保留好的历史数据，并将结果输出到一个新的数据视图中。我们知道 Apache Kafka 的底层是使用 Log Offset 来判断现在已经处理到哪个数据块了，所以只需要将 Log Offset 设置为 0，新的作业实例就会从头开始处理历史数据。
第三步，当这个新的数据视图处理过的数据进度赶上了旧的数据视图时，我们的应用便可以切换到从新的数据视图中读取。
第四步，停止旧版本的作业实例，并删除旧的数据视图。
与 Lambda 架构不同的是，Kappa 架构去掉了批处理层这一体系结构，而只保留了速度层。你只需要在业务逻辑改变又或者是代码更改的时候进行数据的重新处理。
在讲述完 Kappa 架构之后，我想强调一下，Kappa 架构也是有着它自身的不足的。
因为 Kappa 架构只保留了速度层而缺少批处理层，在速度层上处理大规模数据可能会有数据更新出错的情况发生，这就需要我们花费更多的时间在处理这些错误异常上面。
还有一点，Kappa 架构的批处理和流处理都放在了速度层上，这导致了这种架构是使用同一套代码来处理算法逻辑的。所以 Kappa 架构并不适用于批处理和流处理代码逻辑不一致的场景。
小结
在本文中，我们简述了 Lambda 架构和 Kappa 架构这两种大规模数据处理架构，它们都各自有着自身的优缺点。我们需要按照实际情况来权衡利弊，看看在业务中到底需要使用到哪种架构。
如果你所面对的业务逻辑是设计一种稳健的机器学习模型来预测即将发生的事情，那么你应该优先考虑使用 Lambda 架构，因为它拥有批处理层和速度层来确保更少的错误。
如果你所面对的业务逻辑是希望实时性比较高，而且客户端又是根据运行时发生的实时事件来做出回应的，那么你就应该优先考虑使用 Kappa 架构。