开发者学堂课程【2020版大数据实战项目之DMP广告系统（第一阶段）：kudu入门_应用场景_方案二】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/676/detail/11748
kudu入门_应用场景_方案二
介绍了方案一，本节继续介绍方案二，首先先来回顾一下需求，kudu 的需求就是要做一个工业大数据的项目，所有的机器的数据收集放到数据平台当中，因为数据是一条一条的，所以又要求及时查看近期数据并且可以访问历史数据，因此对数据层有两个层面的要求，第一个层面要能够随机插入然后快速得到某一部分数据，还有一部分就是存储层要能够处理大规模的数据扫描。如果是这种项目，使用 SparkStreaming+HDFS 。因为要对数据进行模式处理，而SparkStreaming 在处理完数据落地到HDFS里会产生大量的小文件，这个时候再来说第二种方案，第二种方案为SparkStreaming+HDFS（合并压缩），意思是要处理 HDFS 文件，把小文件合并起来。
方案二: HDFS+compaction
SparkStreaming 处理完以后会产生非常多的小文件，这些小文件可以合并起来可以使用 file_compact 合并成大文件。这么做性能会有改善并且能做到之前做不到的事情，但是在合并的过程非常复杂，有可能把文件放到某一个文件中，比如说在 SparkStreaming 处理完以后放到第一个文件又放入了第二个文件又放入了第三个文件，第一个问题就是假如说外部有系统正在读取这个文件，但这个文件足够小，因此想把这三个文件合并在一起，但这个文件还正在被读，或者外部正在往这个文件里去写，不管什么原因这个文件正在被使用，此时没有办法合并，因此要注意一个文件只有不再活跃时才能合并。
还有的问题就是第一个文件在外部还有关联，外部可能在读取或者进行相应的处理，但又要将这些文件合并起来。假如产生了三个文件，当外部正在使用这个文件时，但要将这些文件合并起来，为什么能合并是因为外部可能没有东西去写了，文件有可能不会发生变化了，所以可以把它们合并成一个文件，合并成一个文件以后，一个文件不能覆盖原来文件的位置，因为外部正在读取，所以需要再加一个目录来装合并完的文件，等三个文件的目录的请求都处理完后，接下来再把合并的文件拷贝进去，然后让外部访问大文件，是这样的方案。即要注意不能将覆盖的结果放回原来的位置。
合并文件需要考虑系统，数据源源不断的来，又要源源不断的查，在这样的场景下要考虑首先文件会不会变其次那边是否在读，所以要注意如下两个问题：
（1）一个文件只有不再活跃时才能合并
（2）不能将覆盖的结果放回原来的位置（因为有可能中断外部的查询，而且刚才的过程是有两个目录，当前一个目录正在活跃当中，当活跃的目录不再活跃时，另一个目录中的文件可以放入不再活跃的文件中，然后让外部访问新的目录，不一致的问题一定会存在无法解决。）
所以一般在流式系统中进行小文件合并的话，需要将数据放在一个新的目录中，让 Hive/Impala 指向新的位置，再清理老的位置。
