背景
? ? ? 自google发布3篇GFS,BigTable,MapReduce已过去近20年之久，市面上针对大数据治理方案也层出不穷，但大数据实时依旧是一项很难得技术。其主要表现在如下方面：
（1）需求实现很难。对数据使用的用户持续增长，用户需求复杂多变，而这种复杂的需求实现又局限于目前的大数据生态，几乎没有某一个组件能解决几乎所有用户需求场景，依旧需要灵活的组合各大数据组件来实现。
（2）实时存储很难。随着场景需求发展，需要数据从离线向实时迈进，要求满足实时场景下逐行插入、低延时随机写、满足实时更新、是否数据具有完整性保证等。
（3）实时分析很难。实时分析场景下需要能够对数据具有快速扫描的能力、能快速过滤、减少数据IO等。
架构演变
hdfs+compaction
? ? ? ? ?GFS被设计用来可以解决大数据场景下的实时快速分析，扫描批量查询性能优越，但却对数据的随机读写、更新显得力不从心。为满足一个能基于hdfs快速分析且较实时写入的系统，也许会基于如下方式实现,通过spark streaming 程序读取实时流数据，写入至hdfs上，数据分析通过spark近似的程序读取hdfs写入的文件块。
? ? 过一段后发现hdfs小文件过多，已经验证影响hdfs磁盘查询性能。于是考虑采用一个后台线程compaction方式不停对hdfs文件合并，同时还需要考虑合并文件时不能在用户查询过程中进行，否则导致用户分区暂时“丢失”，需要将合并后的文件替换成新的，因此必须保证数据一致性。这样hdfs上可能会存在一个base和landing目录存在，base用来保存已经compaction的数据，loading目录保存待合并的数据，每次都将loading目录下的数据移动的base下完成合并，然后将元数据指向新的分区，并利用试图保证用户看到一致性数据。于是修改为如下架构：
该方案尽管是实时的，但却是伪实时，因为还是小文件，只不过通过小文件合并减少了，即使可以通过文件合并等方式模拟随机写来实现，但这样做会导致成本很高。原因很简单，试图让hdfs做不善长的工作。
hbase+hdfs
? ? ?hbase作为bigtable的开源实现，可以做到随机读写，却缺少数据分析性能，于是有人将其改造为下架构：
?数据不断的写入hbase，等积攒至一定大小时，就flush至批层，批层将其刷成一个parquet文件，然后向hdfs上添加一个数据表分区，通知元数据层增加了新分区数据。但这样做就必须要求client端知道有2个系统，否则就不在流与批之间添加一个“连接层”。
实时流计算
? ? ?还有一种架构是通过spark streaming，storm，flink等实时处理框架实现的，提供实时读取和处理功能，但这类系统在实时计算和统计时，往往需要与外部存储交互，这样外部数据存储也必须满足行插入、低延时随机读写、快速查询分析、更新等能力，如下图所示，这样导致采用大数据技术来实现变得很复杂。
因此说，大数据实时依旧是一项很难得技术。
但大数据实时真是一项很难得技术吗？
KUDU
kudu介于hdfs与hbase的产品，具有实时写入、实时分析特性，后期市场上出现的hudi也模拟kudu架构实现了自己的版本。
未完待续 ... ...
?