才用过一段时间的Clickhouse，在基本摸清了它的原理、常用玩法，以及支持的各种功能外。
现在就又开始马不停蹄的试用Doris，你不能说我喜新厌旧，主要是应球友们的邀约，盛情难却，想对它跟CK来一番对比，看看它在各个方面的表现，孰优孰劣。
0. 文档
打开Doris官网的第一感觉就是，对中文用户实在是太友好了，可能由于是中国公司贡献到Apache的项目，因此它的中文文档写的非常用心，相对于英文版的文档，暂时没有看出有阉割的痕迹(对比CK的文档)。
而且，也不像一些伪中文文档那样，只有少数几个不痛不痒的句子被翻译成了汉语，其他还是英文，跟闹着玩似的。
另外，还有一个就是文档的结构布局非常好，所有的内容都在一个页面能全部显示完全，想看哪个直接找到对应的顶级目录就可以找到，但是CK则不是，之前文章也吐槽过CK的文档目录结构，乱七八糟，比如文档首页是没有提供表引擎这个入口的，想要查看，必须要手动搜索。
1. 适用场景
Doris是一款其实跟CK功能差不多的，近实时分布式OLAP数据库，这个从它的介绍，以及文档中的总体内容就可以大概看出来：
至于介绍中说的“亚秒级返回海量查询数据”，很明显是催牛逼的广告，现在只要是个数据库，就没有说自己慢的，至于在生产中能有多快，那就要看你写入了多少数据量，以及使用者水平高不高了，跟它用了多少“黑科技”关系其实并不是特别大，或者说，再牛逼的黑科技，如果使用的不当，一样会慢的像蜗牛。
官方给了如下这个使用场景说明图：
它把自己放到一个实时数据仓库的地位，说可以支持后面的报表分析、即席查询、联邦查询、机器学习等，其实明眼人都知道，这个位置并不是Doris的专属，很多数据库都支持这些功能，以及相同的生态。
只能说它是当下众多优秀的，近实时OLAP数据库的又一个新选择，而并不是这类似场景中，非它莫属(当然，Doris肯定希望你这么认为)。
2. 技术架构
如果说CK是一款“以表为单位”构建起来的分布式数据库，那么Doris就是一款主从架构分明，master/slaver角色明确的，典型的传统分布式数据库。
只不过，它好像也没有那么传统，因为它的架构跟普通的master/slaver架构又有些不一样：
Master：
可以看到，它的master可以有由多个实例组成，而且不同的实例扮演的角色又有细微的区别，虽然是master，跟一般其他的master不一样的是，这个master的子集群数量是可以横向扩展的。
而这个master，Doris给它起了个专门的名字，叫Frontend，简称FE，主要负责用户请求的接入、查询解析规划、元数据的管理、节点管理相关工作，跟大部分分布式系统的master一样，干的都是管理类的活。
只不过，这个master的组织架构跟其他分布式系统不太一样的地方在于，它内部的分工和角色特别像zookeeper，通过对官方文档描述的理解，我对他们3个的角色大致总结如下：
Slaver：
子节点就没什么好说的了，历来就是专门干活的，分工特简单，就是存储数据，然后执行数据的查询计算要求，只不过有点特殊的是，该部分的实现代码语言跟master的Java不一样，为了极致的数据处理效率，它是用C++实现的。
同样，Doris也给它的slaver起了个新名字，叫Backend，简称BE。
别说，这种master跟slaver用不同的编程语言实现的技术架构，我还是头一次见，算是长见识了。
3. 安装部署
之前在聊CK的文章里说到，对于一个成熟的，且流行度高的服务器软件来说，一般都会提供多种部署方案，以满足不同的人群需求。
从Doris官方文档提供的部署方式来看，相比于CK，它多了个K8s部署的支持，但是却少了yum安装，和rpm安装这两个选择。
它这里的标准部署，其实指的是压缩包解压的方式，也是我最常用的一种方式。
那么接下来，就把这套玩意给部署起来，既然是部署，那就会面临版本选择的问题，那选个版本呢？
版本选择的考量：
之前说过，对于软件的选择我都是尽量选择次新版本，但是这个选择的前提是，除了最新版本可能因为用的人少，网络上的相关资料会比较少外，其他一切，比如生态的兼容性都是OK的。
之前在部署CK的时候，在官方文档里因为没有找到对应兼容组件的说明，但是这次在Doris里却有，比如跟他紧密相连的计算引擎Spark版本，还有操作系统的版本，以及对应的JDK版本等。
对操作系统，以及JDK的要求如下：
spark版本的兼容情况：
当然，此外还有Flink等其他可能与之直接关联的生态组件的兼容性说明，这个就为你要安装的Doris版本选择提供了另一个重要依据。
因为我当前集群的spark是3.2的版本，因此就可以大胆选择Doris1.0以上的版本了。
这里我选择了Doris的1.2.3版本，不过在选择时，你可要擦亮眼睛看清楚，一不下心可能会选错：
有意思的是，文档明明说的是1.0以上版本的Doris兼容的是spark的3.2、3.1和2.3这3个版本，但是当我下载完它的FE，在解压安装时居然发现它的lib目录中spark的版本都是2.4.6的。
emmm... 说明就算是官方文档，也不一定就100%靠谱，凡事还得自己亲自动手实践验证。
不仅Doris的软件架构是master/slaver分离的，其部署的软件包也是一样，分为FE(master)部分和BE(slaver)部分。
我们知道，对于master来说，Doris之所以让它能部署多台，核心原因之一在于满足高可用，如果只是满足集群运行的基本条件，肯定一个也就够了。
master部署：
将下载的FE压缩包放到目标master机器的目录下并解压，根据常规操作，打开解压后的FE目录，目录结构如下：
bin目录：服务控制目录，目前就启动和关闭两个；
conf目录：核心配置就是fe.conf，配置你的Java环境，元数据存储位置，日志位置，ip地址等；
lib目录：依赖的，或者可能需要依赖的各种jar包；
doris-meta：默认主节点的数据目录，也就是保存元数据的，一般建议修改到数据盘目录下；
log：默认记录服务的日志目录，也是建议改为统一的日志目录下；
webroot：提供主节点的访问页面需要的相关信息；
spark-dpp：这个里面有个跟spark相关的jar包，目前不清楚干啥的，后续再研究；
其他的目录：目前看来并不重要。
确认好以上目录的内容，直接启动bin目录下的start_fe.sh脚本就可以了。
slaver部署：
同样，将BE的安装包放到slaver机器的目录行并解压，在启动服务前，也是来看一下软件包的目录结构：
bin：启动和停止服务的脚本目录；
conf：配置文件目录，主要关注关键配置be.conf，要修改其中数据的存储位置，jdk位置，IP地址，日志位置等等;
log：slaver端的默认日志目录，建议更改为统一的日志目录；
storage：默认的存储数据目录，建议更改为统一的数据目录；
www：应该是提供slaver端web服务的目录；
同样，按理说应该通过执行bin目录下的start-be.sh就能服务启动起来了，但是，这里面主要有有2个坑：
坑1：
当前默认的BE安装包是缺少东西的，当你修改be.conf配置文件，添加一些诸如jdk的环境，以及MySQL connector环境后，启动该服务会有个报错，作为一个大数据开发人员，应该可以从这个报错中敏感的发现：它缺jar包。
而这一点，在官网中其实是没有交代清楚的，虽然它有说要添加UDF依赖，但是没有说清楚是哪个依赖啊。
而它说的这个依赖，在这里：
要把这个压缩包下载下来解压，然后把里面的udf包放到BE家目录下的lib目录中：
再启动，这个错误才消失。
坑2：
严格来说，这个谈不上是坑，因为官网其实已经预知了这个可能的错误，那就是当前服务器的默认打开的文件句柄数是不够的，需要增加一些，否则BE服务还是启动不起来。
这个问题不仅针对Doris，其他很多数据库都有这个要求，一般我们都会提前修改这个参数。
master和slaver建立连接：
之前因为master和slaver都是各自启动的，彼此之间暂时还没有进行关联，也就是谁都还不认识谁，那怎么办呢？
通过master的客户端添加slaver，从而让master认识自己的小弟。
这里有个有意思的点就是，Doris的客户端可以复用MySQL的客户端，它的使用方式也完全遵从MySQL的使用习惯，这样一来，就能大大降低开发者对Doris的使用门槛，是一种非常聪明的做法。
具体做法，则是通过执行一条操作语句来实现：
4. 总结一下
因为Doris的中文文档支持的非常好，且文档编排方式也非常友好，目录结构清晰，让人读起来比较清爽，好评。
其次，整个Doris的部署还是挺简单的，小坑有一点，大坑几乎没有，不至于让人在刚开始接触它时就会受挫，而且还天然提供了一个直观的图形界面，让人通过它大致可以窥探系统的全貌，这个也是优点。
至于后续使用过程中的体验怎么样，有哪些可以让人激动人心的功能，有没有吹牛逼，咱在后续的文章中逐一揭晓...
