开发者学堂课程【2020版大数据实战项目之DMP广告系统（第一阶段）：kudu入门_应用场景_方案三】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/676/detail/11749
kudu入门_应用场景_方案三
kudu入门_应用场景_方案三SparkS treaming+HBase
本项目的场景是必须对项目进行流式处理，在进行流式处理的时候要找一个存储层去存储源源不断过来的消息和事件，那么 SparkS treaming 要落地到 HDFS 中。前面两个方案的问题就在于 HDFS 不适合进行实时的数据插入，HDFS适合离线批量大规模数据分析。对于实时的数据存储，HBase更合适一些，HBase 的目标为在 HDFS 之上提供一个类似与表的服务，类似于数据库的层虽然 HBase 适合实时的低延迟的数据存储，但是对于历史的大规模数据的分析和扫描性能是比较差的，因为在访问 HBase 的时候是通过一个统一的入口来的。所以它不适合像 HDFS 那样的大规模批量的分析，而 HDFS 上有很多文件格式，比如说Parquet，Parquet离线大规模数据分析存储量非常高，现阶段模式 Parquet 储存量应该是最高的，但它放在 HDFS 上才能产生威力，所以还要结合 HDFS 和 Parquet 来做这件事。
Spark Streaming 在插入数据的时候是不应该往 HDFS 上插，应该插到HBase上面，但是要使用 SQL，Spark 和 HBase 来进行交互的话，HBase 对于大规模的数据处理分析又存在弊端。此时可以再加一层 HDFS Parquet 层，HBase 一直接收外部的数据，外部的数据处理完了及时放到 HBase 中，落地到 HBase 以后，HBase 收集到一部分数据以后同步到 HDFS，这个时候外部在进行批量的大规模的离线的数据分析的时候，可以直接找 HDFS 来进行分析。所以可以把 HBase 和 HDFS 结合起来，去做适合的事情。
但这种方案又存在一定的问题，因为要将数据库的内容同步到文件系统中，在做这件事的时候，会在维护方面产生巨大的成本，因为它是主从这样的结构。HBase里面收集一部分数据同步给 HDFS，但 HBase 中永远会有一部分数据没有同步给 HDFS，所以要进行全局统一的数据查询就不太容易做到做到。两个主要问题如下：
（1）维护特别复杂，因为需要在不同的存储间复制数据
（2）难以进行统一的查询，因为实时数据和离线数据不在同一个地方
这种方案，也称之为 Lambda,分为实时层和批层处理，通过这些这么复杂的方案，其实想做的就是一件事，流式数据的存储和快速查询。
