大数据实时依旧是一项很难的技术

大数据实时依旧是一项很难的技术

背景

      自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架构实现了自己的版本。

未完待续 ... ...