下記に示すように、まず私たちは、典型的な大規模なインターネット・データ・プラットフォーム・アーキテクチャを見てみましょう。
ブラウンアウトを持つユーザーのオンラインビジネス処理コンポーネントに示す。このアーキテクチャ図、ビッグデータプラットフォームでは、この部分は、ビッグデータ関連コンポーネントの青色の部分の他の部分に属するオンラインアプリケーションのためのインターネットの一部であり、オープンソースのビッグデータ製品の使用または自分の大規模データ関連コンポーネントを開発。
データ収集、データ処理、出力および表示データ：あなたが見ることができるように、上から下への大規模なインターネットデータは、3つの部分に分けることができます。
データ収集
アプリケーションは、データを生成し、大規模システムへのアイソクロナスデータをログデータ同期システムは、実際に関連する複数のシステムの組み合わせである異なるデータソースからです。データベースの同期は、後のメッセージキューカフカなどを介して送信されるように変換されたデータフォーマットロギング、水路を選択するために、同期のログを、通常Sqoopです。
異なるデータソースによって生成されたデータの品質が大きく変化することができる、データベース内のデータを直接大規模なデータシステムをインポートすることができる場合があり使用可能な状態であり、データ生成されたログと爬虫類、洗浄、効果的に使用される変換処理の多くを必要とします。
データ処理
これは、大規模なデータストレージおよびコンピューティングのコア、データ・ストレージ・システムリードHDFSにおけるデータの同期です。MapReduceの、ハイブは、計算されたHDFS上のデータを読み取るために、他のコンピューティングタスクをスパークして、HDFSに結果を書き込みます。
MapReduceの、ハイブ、スパーク演算処理等は以下のようにオフライン計算と呼ばれる、データストレージはHDFSオフラインデータと呼ばれます。オフライン計算は、一般に、すべての注文のために商品関連マイニング履歴などのすべてのデータ（の一の態様）のために大規模なデータシステム上で実行、データが非常に大きい場合、この時間は、それは、このような計算を実行するのに長い時間がかかりますオフラインコンピューティングです。
オフライン計算に加えて、いくつかのシナリオがあり、データサイズが比較的大きいが、処理時間が比較的短いが必要です。そのような淘宝として監視およびアドボカシー1秒あたりに生成注文の数をカウントします。このシナリオは、エンジンが秒あるいはミリ秒の計算された時間内に完了することができます完了するために他の大規模なデータ・ストリームを蒸しスパーク、通常は嵐、大規模なデータ・ストリームを計算すると呼ばれています。
データ出力と表示
得られたデータを算出するための大規模なデータはHDFSまたはで書かれているが、アプリケーションは、HDFSにデータを読み取ることができないので、HDFSにデータベースにデータをエクスポートする必要があります。データ同期をエクスポートすると計算されたデータを生成することは比較的容易であるデータベースと少し進むSqoopが好きなシステムにエクスポートすることができ、より標準化されています。
この時点で、アプリケーションは、推奨製品に関連付けられているユーザに表示など、ユーザにデータベース、リアルタイム表示で直接データにアクセスすることができます。
ユーザアクセスにデータを提供することに加えて、大規模なデータは、適切なバックエンド・システムにアクセスして動作し、意思決定の統計レポートを、データは、データベースに書き込まれる様々なを提供する必要があります。多くの事業者や経営者、仕事毎日は、バックエンドのデータシステムは、それが通常の業務であるかどうかを確認するために、前日のデータレポートを表示するにはログインされています。データが正常であるかさえも増加している場合、あなたは少しリラックスすることができ、データの秋ならば、気になる方や忙しい一日が始まろうとしています。
上記の三つの部分、スケジュール管理システムを統合し、異なるデータが同期、MapReduceのさまざまなを起動したときに、リソースを最も合理的に利用するためにどのように合理的なタスクスケジューリングをスパーク、時間と一時的ながら、あまりにも長く待つことはありませんすることですまた、重要なタスクを完了するために、タスクスケジューリング管理システムを必要とする、できるだけ早く実行することができます。
また、ラムダ・アーキテクチャとして知られているような大規模なデータプラットフォームアーキテクチャは、上述した、従来のアーキテクチャプロトタイププログラムビッグデータプラットフォームを構築することです。ラムダアーキテクチャのプロトタイプは、以下のチャートを見てください。
ラムダアーキテクチャ
ラムダアーキテクチャ（ラムダ・アーキテクチャ）は、Twitterのエンジニアナンセンマット（ネイサン・マルツ）ビッグデータ処理アーキテクチャにより提案されています。これは、TwitterのBackType分散データ処理システムのアーキテクチャ上の経験とマッツに基づいて作られました。
ラムダアーキテクチャは、開発者は、大規模な分散データ処理システムを構築することを可能にします。これは、優れた柔軟性と拡張性を持っていますが、またハードウェア障害やヒューマンエラーのために良いフォールトトレランスを持っています。
3系統の合計のラムダ・アーキテクチャ：バッチ層（バッチレイヤ）、クエリに応答して、ならびにサービス層（なる層）の処理層（感度層）の速度。
ラムダアーキテクチャでは、各レイヤは独自のタスクを背負っています。
ロットマスタデータセットのストレージ管理層（不変データセット）と予め計算バッチ図。
批处理层使用可处理大量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的，能够修复任何错误，然后更新现有的数据视图。输出通常存储在只读数据库中，更新则完全取代现有的预先计算好的视图。
速度处理层会实时处理新来的大数据。
速度层通过提供最新数据的实时视图来最小化延迟。速度层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整，但它们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后，在速度层的数据就可以被替代掉了。
本质上，速度层弥补了批处理层所导致的数据视图滞后。比如说，批处理层的每个任务都需要 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 架构。