在大数据3.0时代，Lambda大数据架构已经无法满足企业用户日常大数据分析和敬意运营的需要，去ETL化的IOTA大数据架构才是未来。
Lambda架构
Lambda 是用Nathan Marz（实时处理框架storm的作者） 提出的用于同时处理离线和实时的数据的，可容错的，可扩展的分布式系统。它具备强鲁棒性，提供低延迟和持续更新。它通过批量MapReduce作业提供了虽有些延迟但是结果准确的计算，同时通过Strom等实时计算引擎将最新数据的计算结果初步展示出来
缺点：
1、实时与批量计算结果不一致引起的数据口径问题；基于MapReduce和HDFS的Lambda系统有一个长达数小时的市价窗口，在这个窗口内，由于是是是任务事变二产生的不准确的结果一直存在
2、Lamdba架构需要在两个不同的API中对同样的业务逻辑进行两次编程，一次为批量计算的系统，一次为流失计算的系统，针对同一的业务问题产生了两个代码库，各有不同的漏洞，系统维护成本大大提高。
3、批量计算在计算窗口内无法完成：在IOT时代，数据量级越来越大，经常发现夜间只有4、5个小时的时间窗口，已经无法完成白天20多个小时累计的数据，保证早上上班前准时出数据已成为每个大数据团队头疼的问题。
4、数据源变化都要重新开发，开发周期长：每次数据源的格式变化，业务的逻辑变化都需要针对ETL和Streaming做开发修改，整体开发周期很长，业务反应不够迅速。
5、服务器存储大：数据仓库的典型设计，会产生大量的中间结果表，造成数据急速膨胀，加大服务器存储压力。
Kappa架构
Kappa架构的核心思想是通过改进流计算系统来解决数据全量处理的问题，使得实时计算和批处理过程使用了同一套代码。Kappa架构认为只有在有必要的时候才会对历史数据进行重复计算
Kappa架构的核心思想包括以下三点（我看大家基本上都这么写，我就直接复制过来了，捂脸）
- 用Kafka或者类似的分布式队列系统保存数据，你需要几天的数据量就保存几天。
- 当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。
- 当新的实例做完后，停止老的流计算实例，并把老的一些结果删除。
-
缺点：
1、流式处理对于历史数据的高吞吐量力不从心：所有的数据都通过流式计算，即便通过加大并发实例数亦很难适应IOT时代对数据查询响应的即时性要求。
2、 开发周期长：此外Kappa架构下由于采集的数据格式的不统一，每次都需要开发不同的Streaming程序，导致开发周期长。
3、 服务器成本浪费：Kappa架构的核心原理依赖于外部高性能存储redis,hbase服务。但是这2种系统组件，又并非设计来满足全量数据存储设计，对服务器成本严重浪费。
Lambda和Kappa优缺点：
选择
1、业务需求
所需的历史数据规模比较大，并且达到TB以上，那么选择Lamdba架构可能较为合适；如果历史数据相对较较小，比如电商网站仅30天的数据，可选择Kappa；
如果项目中需频繁的对算法模型进行调优，比如在实际应用中，需要机器学习，需要有批量处理生成预测模型，在交由实时计算进行是是是分析，这种情况下，批处理和实时处理系统不能合并，因此应选择Lambda架构
2、开发和运维成本
Kappa批量和实时计算共用同一套代码，开发和运维成本较低。