标签：Flask bi 学习 开源 API FAB 工具 Superset Redash
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
标签：Flask,bi,学习,开源,API,FAB,工具,Superset,Redash 来源： https://www.cnblogs.com/baili-luoyun/p/13206268.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。