zoukankan      html  css  js  c++  java
  • 待学习bi工具

    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

     

  • 相关阅读:
    Execution Contexts (执行上下文)
    OOP—ECMAScript实现详解
    requireJS入门
    SqlServer 傲娇的表变量
    CSharp进阶 引用类型引发的血案
    CSharp进阶 都是请求惹的祸
    z-index问题
    js中事件(自定义事件)
    做了个后末日朋克风的梦
    昨晚的梦
  • 原文地址:https://www.cnblogs.com/baili-luoyun/p/13206268.html
Copyright © 2011-2022 走看看