概述编辑
FineBI6.0 采用了存算分离架构，将业务服务（BI-web）、引擎服务、存储剥离拆分，在稳定性、可扩展性上有了新的提升，能够满足更高要求客户的需求。
下面我们根据架构图，查看存算分离架构的不同之处：
未配置存算分离的 FineBI 架构（3BI+3worker集群），如下图所示：
配置了读写分离（2BI+4worker集群）架构，如下图所示：
存算分离的优势编辑
FineBI的抽取集群，经过几代发展，从5.x时代的插件热备，到6.0时代的抽取集群，开始支持读写分离。
在6.1版本中，我们带来了存算分离架构的抽取集群，进一步提升了稳定性、扩展性、更新性能。
稳定性提升
5.1.X 版本 / 6.0.X 版本：引擎和BI在同一个进程中，用户访问跟查询更新互相影响，宕机之后整个服务崩溃
6.1.0 版本：将引擎服务跟业务服务（BI-web）剥离拆分。
完善的内存控制，引擎 拆分独立进程，引擎宕机无感知；引擎支持自动重启，可以在分钟级别快速重启，多个引擎节点下，满足真正高可用需求。
可扩展性提升
5.1.X 版本：抽取数据只支持通过插件实现主备集群，无法实现高可用；只支持本地磁盘存储；
6.0.X 版本：最多只支持 5 个同步节点，集群扩展节点方案受限；只支持本地磁盘存储，不能满足客户个性化存储需求；
6.1.0 版本：引擎计算和存储分离，抽取数据支持使用云 OSS 。
增加统一数据访问层，将计算和存储分离，突破了历史spider抽取集群节点间本地抽取数据持久化同步的瓶颈，引擎突破节点数限制，横向扩展超过10+节点，查询并发线性提升，能够满足高并发查询的用户群体；
抽取数据存储支持使用云 OSS ，持久化数据不落地，满足企业数据安全需求；
性能提升
5.1.X 版本 / 6.0.X 版本：非容器化部署下，工程启停、获取日志、查看监控系统内存CPU使用情况等都需要在后台执行命令操作；且整个工程资源使用情况缺少监控预警手段（只有插件功能在前端能够看到内存、CPU使用情况）。
5.1.X 主节点会将抽取数据无尽同步到备节点服务器上，主备两个服务器都需要准备很大的磁盘空间来储存抽取数据；
6.0.X 节点内部会进行抽取数据同步，每个同步节点服务器都需要准备一个很大的磁盘来储存抽取数据；
6.1.0 版本：日常运维操作简单化、可视化；磁盘空间释放。
FineBI 基础运维操作，均可通过运维平台前端可视化完成：如工程启停、下载日志、生成堆栈dump等，有效降低一部分运维成本；
取消bitmap存储，多个引擎节点就只持久化一份数据，不再需要准备非常大的磁盘。
存算分离的风险项编辑
master节点暂时不支持高可用
在整个集群架构中，BI-web 、worker 都是支持节点扩展的，但是 master 无法进行扩展。后续产品规划迭代开发会解决这一问题。
运维平台Ops部署自带的 minio 是单机，不支持高可用
默认部署minio单机版本，不提供存储层高可用保证。如果有高可用诉求，存储层需要客户自己提供共享存储（OSS>nas）。