数据湖小探

数仓的建设总是离不开业务，一般来说都是业务驱动，我需要什么样的东西，有什么样的需求才开始去做相应的事情。

生活中也是如此，有了目标，有了需求，才有了以后。

生产决定消费，更多描述的是事物的有和无。

从某些方面来说，更应该是我需要哪些，才会生产哪些。我思故我在。

因为只有先认识世界，才有世界的以后。否则，这个世界只是个世界，一个未知的不确定的存在。

个人的理解的数仓的建设是基于：write on schema的方式，基于业务进行建模，业务上需要什么，我就采集什么，别的我不关心。

数据湖只是个建仓理念，write as object，read on schema，就是把对象存储+数仓结合起来，理解得比较片面，请见谅。建模是必不可少，是业务驱动的。只是在建模前先把数据接入进来，将数据存储层纳入进来。就像我们去湖里钓鱼，湖里面除了鱼之外，还有龙虾。我来钓鱼的，要是由于鱼饵太香了，龙虾也咬钩了。你说我是收还是不收。收，我没有准备好存龙虾的地方。不收，也合理，因为我是来钓鱼的，不是来钓龙虾的。我妈妈也不喜欢吃龙虾。

好，我们来聊聊对象存储。一直好奇百度云盘这些厂商的顶层实现，是不是基于hdfs来实现的，还是ceph或者MinIO。

项目中也涉及到对象存储的地方，比如：设备上传的日志文件、摄像头视频文件等。前期调研选择了fastdfs，之所以没有选择hdfs，主要是不想引入更多的技术组件。但是随着后面的数据分析等功能的开发，慢慢的我们还是引入了hadoop，使用了：yarn和hdfs。于是乎，我们感觉也许fastdfs并不适合我们。

1、项目停滞

2、社区不活跃

3、基于c编写。

那对象存储我们到底用啥来弄呢？目前看比较好的开源方案：hbase。hbase是可以理解为一个大的KV数据库，面向列的数据库。为何说是面向列，因为他具有列族的概念，可以理解为列的分类。一个列族，可以放很多列，可随意增减的，这块也体现了它可以存储半结构化的数据。可以把他看成一个超大的hashmap，底层存储使用的hdfs。hdfs是一个非常成熟的分布式文件系统，可运行在廉价的pc机器上，社区相当活跃，技术成熟度很高。Apache HBase2.0 版本开始支持中等对象存储（Medium Object Storage，简称 MOB），这个特性使得HBase能够非常良好的存储大小在100KB-10M的图片、文档、音频、短视频等二进制数据。

另一方面，我们基于rowkey进行简单的业务检索，hbase的检索特性，可以简单理解为标签检索。支撑固定维度的记录筛选。这些也是很多OSS产品所不具备的。下图简单画了下数仓和数据湖的关系，仅仅是个人的理解，供参考。