这一大系列博客将介绍一个伟大的大数据处理平台是如何诞生的.
预计会有很多很多篇,持续很长很长时间. 为什么说 "伟大" 呢? 因为这将打造一整个新的体系. 不同于现有的大数据生态圈里各种产品的新的函数式体系结构. 数据处理本是函数式语言的专长, (比如Map 和 Reduce 是所有函数式语言的最重要的两个基础函数---哪怕在某些语言中不叫这两个名字), 无奈Hadoop 根植于jvm, 来源于Java,带动整个社区生态从hdfs, hbase, zookeeper, spark 以及其上的各种组合的平台, 都走java系. 现在说大数据处理, 不管用的哪一套体系, 最终都会走到hadoop的hdfs上去. 全世界都这么走.
但是, 万一全世界都错了呢? hdfs 并不完美, 而且是跟完美完全不沾, 他有各种问题, 甚至从一开始, 他就做错了一些事, 并且越错越远.
我们在大数据处理上, 需要的核心是一个Bigtable实现, 和一个MapReduce框架. hadoop 的实现上先有hdfs, 后来才有hbase这个bigtable实现, 因此是hbase去适应和迁就hdfs了. 这就导致了一些不必要的复杂性.
在我们实现里, 我们在设计我们的分布式文件系统时, 我们是假设我们已经有一个bigtable实现, 我们的这个实现, 需要什么样的分布式文件系统来支撑它, 我们就打造一个那样的文件系统. 而对我们的bigtable实现没有帮助的功能,我们则尽量不添加.
整个过程设计遵从 "正交性" 原则, 并且尽力让一切回归本源的简单性, 因为: "如果把简单的事情做复杂, 那以后事情变复杂以后就会太复杂了!". hadoop就是把简单事情做复杂的一个典范, 当然包括大多数 "成熟" 的 java 系的apache开源项目都有这个问题, 就是早期为了以后莫须有的扩展性而过度设计了, 这里面的罪魁祸首其实是 "开闭原则", 为了不修改现有代码而增加或修改功能, 增加了大量的抽象层. 而实际上, 最终还是在大版本里通过重构大量修改了代码.
作为有极大量开发者的开源项目, 这可能是没办法的事情. 带来的问题, 也基本是无解的.
我们这个新轮出来的体系, 必须尽力回避这种附加的复杂性.
整体上的规划:
- 为什么用F#? 因为我们需要一个函数式的基因来引导我们走出一条函数式主导之路, Haskell和其他大多数函数式语言缺乏一个足够强劲的工业化强度的运行时环境作为支撑. Clojure 生成的bytecode质量使得它可能并不是合适的性能热点位置的选择. 另外一方面, 作为现在最广泛的2个高强度的运行时.Net 和 Jvm , 其实各有优缺点, 选择一个与hadoop不同的基础平台, 有助于在未来的演化中引入.Net的特色而产生更多差异化. 当然, 出于跨平台考虑, 我们的 F# 将只使用Mono 和 .Net Core 的交集部分的特性.
- 我们将会轮哪些部分? 首先MapReduce框架是必须的(相当于hadoop mapreduce或spark的地位), Bigtable实现是必须(相当于hbase的地位), Bigtable的底层分布式文件系统(相当于hdfs)是必须的, 作为分布式体系, 一个监控管理的组件是必须的(相当于zookeeper)同时为了在分布式文件系统以外, 存储这个框架的各种元数据, 包括文件系统自己的元数据, 我们还需要一个 轻量级的 key-value 的nosql数据库(至少可以当我们的分布式文件系统的分区表.....)
- 上面需要的那些组件, 现在 .Net 世界里都没有合适的么? 最后那个nosql数据库显然我们已经有类似RavenDB这样的东西了, 不过它太重了, 而且性能特点跟我们需求不太符合, 我们需要的是一个支持超快速写入和读取的, 支持非常大数据量的, 越简单越好的数据库. 其他几个, 至少现在我是没有找到.
- 这个项目会开源么? 当然, 一定会. 我将放在github上.
- 项目名称是 Longlad
- Longlad.MetaStore 是我们的KV数据库
- Longlad.FileSystem 是我们的hdfs替代品
- Longlad.Bigtable 是我们的hbase替代品
- Longlad.MapFold 是我们的spark替代品
- Longlad.Guard 是我们的zookeeper替代品
- Longlad._______ 未来如果时间够, 再加吧, 因为上面5个已经是超大工程了(这项目申请国家核高基的资金怕都不过分....)~~~
- Longlad.MetaStore 是我们的KV数据库
- 组件之间的大体关系, 与 hdfs/hbase/spark/zookeeper 的关系类似, 我就不多解释了. 至于那个Longlad.MetaStore 是作为其他几个的一个子部件存在的.
- 开发的顺序预计将会是: 1,2,5,3,4 下一篇开始从Longlad.MetaStore实现
