数据可视化的开源方案: Superset vs Redash vs Metabase (二)

在上篇结尾处我提到“如果现在让我重新选择,我会使用哪个可视化工具?”我的答案是 Redash,原因主要不是功能层面,而是技术层面。本篇就从项目关注度与活跃度,项目的技术架构,源代码的规模与质量,这三个方面来比较一下 Superset,Redash 与 Metabase。 关注度与活跃度 看一个项目在 Github 上的星数,是评判一个项目成熟度最快速的方法。那除了星数以外,项目的 Github 页面上还有什么重要信息呢?这里我建议大家去看一看项目的 Insights。 »

数据可视化的开源方案: Superset vs Redash vs Metabase (一)

人是视觉动物,要用数据把一个故事讲活,图表是必不可少的。如果你经常看到做数据分析同事,在SQL客户端里执行完查询,把结果复制/粘贴到Excel里再做成图表,那说明你的公司缺少一个可靠的数据可视化平台。数据可视化是Business Intelligence(简称BI)中的核心功能,有许多成熟的商用解决方案,如老牌的Tableau, Qilk,新生代的Looker,国内的FineBI等等。不过对于许多小公司来说,这些服务的License费用是一笔不小的开销,且有一种“杀鸡用牛刀”的感觉。那在开源软件如此发达的今天,在数据可视化方面,有什么靠谱的方案可以选择呢?今天给大家介绍三个比较知名的项目, »

Python profiling

Profiling(性能调试)是我一直很感兴趣的一个话题,之前给大家介绍过Datadog这个工具,今天我们来看看Python语言中有哪些方法来做Profiling。 Poorman's Profiler 最基础的就是使用time.time()来计时,这个方法简单有效,也许所有写过Python代码的人都用过。我们可以创建一个decorator使它用起来更方便。 import time import logging import functools def simple_profiling(func): @wraps.functools(func) »

生产环境下的性能监控 - Datadog

排查性能问题往往比排查功能性的Bug更让人头疼,主要有以下几个原因 很多性能问题只会在高负载的生产环境下出现,在开发过程中很难发现。 功能性出错时我们通常会抛出异常,我们可以通过Tracestack很快定位到问题所在代码的位置。但对于性能问题,我们很难做这样的快速定位。 虽然我们有各式各样的Profiling工具,但适用于对生产环境的并不多。当然这因编程语言而异,Glow服务器端的技术栈是Python + Gevent,目前为止我们都没有找到合适的Profiling工具。 对于服务器端的性能问题,我们常用的方法是写日志文件,例如把每个请求的响应时间都记录下来,但对海量日志文件的存储,聚合与分析又成了另一个麻烦。常用的解决方案有ElasticSearch + Logstack + Kibana,或是StatsD/CollectD + Graphite等等。在Glow, »

写好DevOps的文档

每个DevOps都一个百宝箱,里面放着各种命令行脚本,可以用来自动化各式任务。但若文档不全,即便是脚本的作者,时间一久也不敢随便乱用,毕竟运维的大部分工作是管理生产环境,要是出了错,不是轻描淡写就可以蒙混过关的。写好DevOps的文档其实也是一门技术活儿,这里给大家分享一些组织运维脚本及其文档的经验。 Fabric的任务管理与文档 在以前的文章中,我们曾经介绍过Glow使用了fabric来执行各种日常管理的任务。Fabric提供了非常好用的任务组织以及查阅任务文档的功能。 Fabric的主文件一般命名为fabfile.py,但任务多了,都写在一个文件里显然很难维护。Fabric有一个很实用的特性,就是当fabfile.py里导入其他模块时,会自动发现里面的fabric任务。利用这个特性,可以把各种任务分类写在不同的模块中,然后在fabfile. »