一、Hadoop

狭义来看，Hadoop由用于存储的分布式文件系统HDFS，用于海量数据分布式计算引擎MapReduce以及用于资源管理以和调度工具Yarn三部分组成。从广义的角度来看，基于Hadoop之上的生态圈，其中涉及数据采集，存储，计算，分析等大数据处理的方方面面，如Flume，Sqoop，HBase，Hive，Hue，Oozie，Spark，Storm，Flink，Kafka，Kylin，甚至Redis, ElasticSearch等。

Hadoop是一套相对比较重的系统，一般企业的数据量没达到TB甚至PB级别的时候，很少会采用Hadoop这套体系，而且TB，PB可能只是一个开端而已，纵观古今，数据量能到达这个级别的公司占比又有多少呢，特别是传统行业。Hadoop作为一套比较重的系统，不管是在使用还是在运维上，需要付出的成本自然而然就比较大了。

除此之外，在各大企业越来越追求实时性的时候，Hadoop这类贴着离线处理标签的工具就越来越不太合人群了，不是说Hadoop这套体系做不到实时性的要求，而是实现起来的复杂度相对比较高而已。相较而言，MongoDB，ElasticSearch这类后生小辈凭借硬件能力的快速发展，不仅可以满足PB级数据量的实时查询分析诉求，而且在易用性、实时性方面可谓是完爆Hadoop搭建的实时查询系统。再依托于每种云服务的基础设施，可谓是如虎添翼。

二、批处理与流计算

实时流计算和离线计算是相伴而生的，相对离线(批)处理计算需要等很长一段时间能够获取结果，实时流计算有两个特点：实时，通俗一点来讲就是随时都可以看数据，“实时”可以是分钟级、秒级、甚至毫秒级，你可能前脚在头条上浏览了个新闻，后脚就会在抖音上刷到了一个对应的广告；另一个是流，流水不争，绵延不绝，断不可断。

流计算的技术挑战点很多：1）从应用服务的角度来讲，它是一个7x24不间断的服务，一旦开始很难停的下来，本身应用程序升级、依赖服务升级挑战很大。2）流是一个看不见摸不着的东西，在管道里面流动的这些数据是否按照我们预期的逻辑进行计算，数据是否积压，现有基础设施是否肯扛得住峰值，这些现象都需要依赖比较完善的监控体系和运维系统才能获取到我们想要的信息。3）在数据量大，端到端网络环境复杂的情况下，进行计算的分布式任务中经常会有某个task失败的情况，如何保证失败的任务被自动的重新调度起来做到容错，同时保证处理的数据不会多一条，也不会少一条。是在流计算中常常要以牺牲性能去解决的问题。4）大多数业务中都存在多个流Join起来联合计算的逻辑，如何去处理迟到的消息。

以实时仓库为例，实时数仓是为了解决传统数据仓库数据时效性低解决不了的问题，实时数仓是面向主题的、集成的、稳定的、处理上一次批处理流程到当前的数据。我们可以基于实时数仓来拓展现有OLAP分析工具支持实时分析，在实时数据看板中实时播报核心数据，实时计算实体特征进行精准营销，以及核心业务指标实时预警监控(特别是面向C端的互联网公司)等。在实现这些业务场景的时候差不读都会遇到上述的技术挑战，比如实时数仓的数据(无论ODS，还是DW/DM层)一般都存在Kafka中，ODS层会对来自不同系统大量的实时数据流(如Binlong流，日志流，消息流)分别进行解析过滤等操作，后面再基于这些流进行聚合运算，或者多主题的关联合并运算，以及元数据、血缘、数据质量管理等等。基本上每一个环节都会遇到上述的问题，在哪个环节失败一次基本上就要重来一遍，在大数据量得场景下，就会造成数据积压，拖垮整个计算的速度，就没有实时可言了。除了技术上的挑战以外，还有业务上的，因为只处理部分数据(某个时间段的数据)，数据的准确性、可靠性、实时性以及对异常数据或者延迟数据需要进行监控和预警，并分析原因都有要求。

如果要论方案的话，相比于传统数仓，构建实时数仓要减少层次的划分；用Kafka存储明细和汇总数据，用Redis、HBase等缓存存储维度数据；ODS层尽量保证数据来源尽可能统一，并利用分区保证数据局部有序；在DW层对数据加上唯一键、主键、版本、批次数据，来解决数据重导，重复，有序以及表表结构变化的问题；对于频率变化低的维度表，要充分利用缓存，频率变化高的，用拉链表来减少存储空间。当然还有一些其它依托元数据和数据血缘来保证仓库质量的方法

2. HDFS：分布式文件系统