Metabase

172.16.11.130:3000
user: admin@admin.com
pwd : Admin123***
Metabase 的后端是用 Clojure 写的，前端是用 React + Redux 写的单页应用。
​
由于我对 Clojure 几乎一无所知，所以后端架构方面也就不好做什么评价了。React + Redux 是目前最流行的前端开发框架之一，Metabase 的系统切分与模块化做得非常出色，所以在前端架构方面 Metabase 我给满分。
​
Metabase 是三个项目中唯一提供完整 API 文档的项目，这使得开发者即使完全不会 Clojure，依然可以凭借丰富的 API 与文档完成许多二次开发。
​
部署方面，Metabase 提供了 Jar 文件，Mac 应用程序，Docker 镜像等方式可以让使用者在本地快速尝试该项目。而在生产环境中，它提供了如何在 AWS、Heroku、Kubernetes 上部署的详尽文档，可谓体贴入微。

 

HUE

172.16.6.37:7000
user: admin
pwd : admin
​
依存关系
特定于操作系统的安装说明列在 安装指南
Python 2.7+（已跟踪Python 3支持 UE8737）
Django（1.11已包含在发行版中）
Java（Java 1.8）（应在之后消失 上色8740）
Node.js（10.0+）

 

redash

Redash 的服务器端是用 Python 来写的，Web 框架以 Flask 为基础，并充分利用了 Flask 的插件生态圈，主要用了以下的组件 
- API 框架：Flask-RESTful - 数据库：Flask-SQLAlchemy - 认证：Flask-Login
​
个人觉得 Redash 的选择比 Superset 更明智，选用的都是典型的工具型组件，不会对项目将来的发展产生限制。并且以上列出的三个开源组件都是很成熟的项目，在 Python 社区中被广泛应用。
​
Redash 的前端是一个纯的单页应用，用 AngularJS（1.5）实现，结构清晰，代码整洁。但众所周知，AngularJS 在 v2 之后做了巨大的架构调整，所以 AngularJS v1的处境就有些尴尬。这和目前 Python 2 的处境类似。短期内不会有问题，长期来讲是个隐患。
​
在部署上，Redash 除了 SQL 数据库外，还依赖于 Redis，但 Redis 只用来保存查询锁（防止多个相同查询同时进行），不需要做持久化。总体上说，Redash 的部署也比较简单。另外，Redash 直接提供了 AWS 上的镜像，以及开发环境的 docker-compose 配置，无论是对运维人员还是开发人员都蛮贴心的。
​
Redash 也提供了完整的 RESTful API 接口，它前端的单页应用就是通过这套 API 与后端通讯的，所以理论上在前端界面上做的任何事，都可以用 API 来完成。它的 API 原生支持 API Token 的认证方式。
​
总体而言，Redash 在技术架构上做得比 Superset 更出色。

###

Knowage

Knowage是从SpagoBI发展而来，使用 Java 语言写的开放源码的商业智能分析工具,是一套适合现代商业分析的开源 工具 套装。在版本6以前是完全开源的SpagoBI,2018年发布的6.0版本开始，改名为Knowage并走向开源的社区版及收费的企业版两个版本，相比SpagoBI，Knowage在功能上进行了很大优化，重心移到在线开发模式，加强了在线Document的功能，更推荐使用CockpitEngine进行报表设计。

 

superset

Superset 的后端用 Python 开发，主要用到的开源组件包括 
- Flask App Builder（简称 FAB） - SQLAlchemy
​
我当前团队的主力语言是 Python，所以这是一个加分项。SQLAlchemy 是非常成熟的数据库 ORM 解决方案，也没毛病。但问题出在了 FAB 上。注意，不要把这个开源组件与 Flask 混为一谈，FAB 是构架在 Flask 之上的一个应用开发框架，可以根据数据库的表结构，自动生成增删查改的前端界面，功能上类似 Django Admin。
​
FAB 在初期可能可以为 Superset 的开发节省一些写前端代码的时间，但从中长期来说，它严重限制了 Superset 界面的灵活性。在上篇文章中，我就吐槽过 Superset 里 Dasbhoard 的管理不方便，权限系统复杂，其实就是受制于 FAB。另外，FAB 本身已处于半死状态，从 Github 上的记录看，从 2016 后就没什么更新了。
​
在我看来，Superset 的开发者在选 FAB 做为核心框架时是有欠考虑的。在选框架时，我觉得应该为自己选择一组称手的工具，而不是一件半成品。好的工具可以至始至终为你提升开发效率。而半成品虽然在初期能让你快速搭出一个 MVP，但长远来看一定会挡你的路。FAB 就属于后者。如果做简单的管理系统或是开发原型，FAB 是不错的选择。但 Superset 的目标是成为一个优秀的开源商业分析平台，FAB 注定会成为绊脚石。
​
在前端，Superset 借助 FAB 来生成大部分管理界面，而图表或是 SQL 编辑器等对交互性要求很高的界面，则由 React + Redux 来实现。这种混合的模式让前端代码显得有些乱，说到底还是 FAB 留下的祸根。
​
Superset 的部署还是很简单的。Web 服务器是一个标准的 WSGI 应用，存储层支持用任意的 SQL 数据库（只需 SQLAlchemy 支持），所以部署方面无论是高可用还是水平扩展都很方便。
​
至于 API 接口方面，FAB 原生支持 RESTful API，可以对大部分对象做 CRUD 操作。但认证方式不够灵活，只能通过 cookie。

 

davinci (达芬奇)

国内开源（宜信）、反馈响应迭代及时、功能模块清晰
ABD敏捷大数据全套解决方案，重磅级姊妹产品

flume

​