大数据初篇谈存储

天下苦‘秦’久矣，大数据风风雨雨一路走来，经历了全球的疫情，见证了美股的多次熔断，其自身存储也在不断发展，前面提到不痛不痒，其实有点夸张。当然如果开发者从传统数仓转到以 Hadoop 为存储的数仓，也许会感到极不适应，犹如戴着脚镣跳舞一般，形容的有点夸张了。

那是什么原因导致传统开发小伙伴不适应目前大数据架构下的数仓呢，吗就是所谓的 CRUD 操作，当然再这里就是特指 Delete 和 Update 两个更新操作，基本上这两个操作困惑了我们大数据小伙伴好多年，因此开篇提到了天下苦秦久矣，其实就是这更新操作做起来比较麻烦，比如想要对历史拉链表进行 Merge 操作，在 Hive 语法中就要写一大串 SQL 代码来实现，而且性能可能还不是很好。记得当初在 Y 公司，有次改了离职小伙伴留下的脚本代码，不小心掉入陷阱，导致我们的拉链数据全部出错，那怎么办呢，那就解链吧，坑啊，Hive 的SQL 语法不太好解，既然这个招我们接不住，那就重做。幸好我们当时对数据做了快照可以恢复，因为我们的拉链任务多，而且跑起来很慢，所以干到凌晨好几点才做完。又是一次特殊的经历，从那时起再也不敢轻易动那个拉链脚本了，里面的日期参数的坑太多了。

然而这两年开源社区也在不断的努力来解决这个问题，可谓雨后春笋、百花齐放、百家争鸣，先后出来了CarbonData、Delta Lake、Iceberg 等存储方面的组件来解决数据库方面的 ACID 和 Update、Delete操作，当然 Hive 本身也是支持更新操作，但是就是太弱了。而前面提到那个三个组件，也大多数基于 Spark 来解决更新操作的，虽然功能还可以，但是业界用 Hive 的还是比较多的，目前也正在努力支持 Hive。

聊完了数据更新的苦，我们再聊聊下一个苦，人在江湖混，哪能随心所欲快意恩仇，我们不仅要对老板负责，而且还要对自己的手艺有敬畏之心。目前大数据平台的数据仓库有两种形态，一是离线数仓、二是实时数仓，现在又是数据中台又是数据湖又是什么数据沼泽，其实都是业界炒出来的概念吧了。所谓的离线数仓可以通俗的理解为在上面执行的 SQL周期为一天或者更长时间执行一次，比如老板需要看昨天的UV数（网页访问的用户量），那我们可以简单在凌晨 12 点之后执行 SQL 取出昨天的数据，然后形成报表给早晨上班的老板看，这种跑 SQL 的任务我们称为离线任务；那所谓的实时数仓又是什么鬼呢，其实就是可以理解把离线的 SQL 执行周期缩短饭每秒或者更短时间取出数据，比如老板办公室里有个大屏幕主要实时的显示当天访问的用户量，那这种 SQL 就要不停的执行，我们称之为 实时任务。于是乎，老外提出了两个牛逼的概念 Lambda 架构和 Kappa 架构，所谓的 Lambda 架构就是只能处理离线任务，而Lambda 架构可以处理两者的任务，也就是我们说的流批一体，代表是今天的 Flink。

Flink 在这方面发展的很快，比如新版本可以完全兼容 Hive SQL 语法。但是这个 Flink 只是个计算引擎，也没有解决更新操作的问题，也早接触其他存储，所以江湖中的小伙伴依旧苦秦，只是习惯了这种规则，所以也感受不到苦了，还乐此不疲的说我们用了 Flink，当然我也比较喜欢。

每个公司都有自己的业务模型，选择适合自己的技术而且能玩的转的那都是王道。接下来聊聊目前开源的一个TiDB，在 讲TiDB 之前，社区也出现了很多应用于 OLAP（就是为分析数据量身打造的存储引擎，传统的数据库如Oracle等我们称OLTP） 存储的 DB，比如Kudu、Greenplum、ClickHouse 等这些数据库都是基于列式存储的，相比于传统基于行式的Oracle等数据库的优势在是能快速对大量数据进行聚合计算，这种涉及到行存和列存的底层文件原理，简单来讲列存就是一列数据存储在一个文件里，在做求和运算的时候只要扫描这个一个文件就行，而行存的某一列的数据都是分布在多个文件，在求和运算的时候要遍历多个文件，那当然是遍历一个文件效率高了啊。

那有没有一种数据库可以基于 OLTP 的实现ACID 和 CRUD的，又可以实现 OLAP 快速分析场景的数据库呢，目前可能比较好的是阿里的 OceanBase，但是没有开源，具体有多牛逼没有用过。偶尔在 Y 公司，小伙伴引入了 TiDB 使用，眼看起来存储结构蛮像 Hbase的，那就用用了解了解，反正开源的，本人也比较喜欢其中的开发语言 go，因为一直想学习 kubernetes，所以当时也对 TiDB 比较感兴趣。不过当时用的时候版本是2.X的，各种奇葩的坑都经历过，有个映像特别深，就是“select count(1) from t”和 “select count(disctinct pk) from t”的数据居然不一样, 很奇怪吧，官方解释由于分布式数据库，主键被更新的时候可能保留多个副本，还有个不好的地方就是 left join 的时候 on 后面的条件不走索引，希望这些东西不要在4.X版本出现了哈。TiDB之所以在这篇文章提到，他不仅支持 OLTP 而且还支持OLAP，不过支持 OLAP 的功能还没有开源，因为它两个都兼容了，所以解决了OLTP 和 OLAP 两个兼容的问题，期待 TiDB 新版本出来有一种全新的感觉。

其实未来我们想要的数据库，无论数据大小，无论 SQL 逻辑有多复杂，都可以像今天的 Oracle 等一样方便的实时操作。估计随着硬件技术的提高，若真正实现了这种数据库，Hadoop 的生态圈也就夕阳西下了吧， 也就不用苦秦了，我们也就可以告老返乡泛舟于西湖之上。