data-visualization 数据可视化的开源方案: Superset vs Redash vs Metabase (二) 在上篇结尾处我提到“如果现在让我重新选择，我会使用哪个可视化工具？”我的答案是 Redash，原因主要不是功能层面，而是技术层面。本篇就从项目关注度与活跃度，项目的技术架构，源代码的规模与质量，这三个方面来比较一下 Superset，Redash 与 Metabase。 关注度与活跃度 看一个项目在 Github 上的星数，是评判一个项目成熟度最快速的方法。**那除了星数以外，项目的 Github 页面上还有什么重要信息呢？这里我建议大家去看一看项目的 Insights。**首先我们来看 Superset 最近一个月的活跃度 这张图告诉我们以下几个信息 * 这个项目最近一个月有 53 个提交，说明项目仍在积极开发中。图中显示项目在最近一个月有新增 21 万行代码，这主要是因为提交了一个巨大的地理数据文件，去掉这个文件之后，实际新增的代码行数大约为 2000 行。 * 从新增和处理的 Issue 与 PR 来看，项目的社区很活跃，项目开发者也在积极解决问题。 从短期指标来看，
data-visualization 数据可视化的开源方案: Superset vs Redash vs Metabase (一) 人是视觉动物，要用数据把一个故事讲活，图表是必不可少的。如果你经常看到做数据分析同事，在SQL客户端里执行完查询，把结果复制/粘贴到Excel里再做成图表，那说明你的公司缺少一个可靠的数据可视化平台。数据可视化是Business Intelligence(简称BI)中的核心功能，有许多成熟的商用解决方案，如老牌的Tableau, Qilk，新生代的Looker，国内的FineBI等等。不过对于许多小公司来说，这些服务的License费用是一笔不小的开销，且有一种“杀鸡用牛刀”的感觉。那在开源软件如此发达的今天，在数据可视化方面，有什么靠谱的方案可以选择呢？今天给大家介绍三个比较知名的项目，分别是Superset, Redash和Metabase。前两个我都在产生环境中实际使用过，在本文中会重点介绍。Metabase我只是试玩了一下，但我觉得这是一个非常有想法的项目，所以也会和大家聊聊我对它的看法。 选择一个称手的工具，功能上能满足我的需求肯定是首要的。就先从功能需求讲起，我们的数据仓库用的是Amazon Redshift（如果你没听过Redshift，就把它看作是为大数据优化过的P
python 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) def wrapped(*args, **kwargs): start_time = time.time() result = func(*args, **kwargs) time_spent = time.time() - start_time fullname = '{}.{}'.format(func.
devops 生产环境下的性能监控 - Datadog 排查性能问题往往比排查功能性的Bug更让人头疼，主要有以下几个原因 * 很多性能问题只会在高负载的生产环境下出现，在开发过程中很难发现。 * 功能性出错时我们通常会抛出异常，我们可以通过Tracestack很快定位到问题所在代码的位置。但对于性能问题，我们很难做这样的快速定位。 * 虽然我们有各式各样的Profiling工具，但适用于对生产环境的并不多。当然这因编程语言而异，Glow服务器端的技术栈是Python + Gevent，目前为止我们都没有找到合适的Profiling工具。 对于服务器端的性能问题，我们常用的方法是写日志文件，例如把每个请求的响应时间都记录下来，但对海量日志文件的存储，聚合与分析又成了另一个麻烦。常用的解决方案有ElasticSearch + Logstack + Kibana，或是StatsD/CollectD + Graphite等等。在Glow，对于性能监控这样的通用服务，我们更偏向于选择云服务，而不是自己去维护这些系统，这样我们的精力才能集中在产品研发上。 在对于性能监控类的云服务做了一些横向比较后，我们选择了Datadog，使用一年
devops 写好DevOps的文档 每个DevOps都一个百宝箱，里面放着各种命令行脚本，可以用来自动化各式任务。但若文档不全，即便是脚本的作者，时间一久也不敢随便乱用，毕竟运维的大部分工作是管理生产环境，要是出了错，不是轻描淡写就可以蒙混过关的。写好DevOps的文档其实也是一门技术活儿，这里给大家分享一些组织运维脚本及其文档的经验。 Fabric的任务管理与文档 在以前的文章中，我们曾经介绍过Glow使用了fabric来执行各种日常管理的任务。Fabric提供了非常好用的任务组织以及查阅任务文档的功能。 Fabric的主文件一般命名为fabfile.py，但任务多了，都写在一个文件里显然很难维护。Fabric有一个很实用的特性，就是当fabfile.py里导入其他模块时，会自动发现里面的fabric任务。利用这个特性，可以把各种任务分类写在不同的模块中，然后在fabfile.py中统一导入。比如Glow的DevOps代码库的结构大概长这个样子 $ tree ├── __init__.py ├── fabfile.py ├── fab_scripts │ ├── __init__.py │ ├
career 如何提升你的能力？给年轻程序员的几条建议 一转眼工作已有8年，前两天公司一位初入职场的同事希望我给一些建议与经验。我觉得这个话题很有价值，这里以个人的想法与经历写成此文，希望给年轻的开发者们一些启发。 我工作过的公司有4家，NVIDIA, Google, Slide和Glow。其中两家是知名的大公司，Slide我是D轮过后加入的，那时约150人。Glow则是从它第一天创立，一直走到现在。个人的工作也从Developer，Tech Lead，Engineering Manager到CTO。这些经历使我对程序员的个人发展之路有比较全面的看法。 如果你问一个年轻的前端开发人员，你在今后的3年内如何提升自己的能力？他可能会说“我现在对Web前端比较熟悉，但我想深入了解AngularJS，另外React现在发展的很快我也想看一下。之后，我会花时间去学习iOS和Android开发。”看上去不错，但缺乏系统性的目标。或者说，他制定了学什么，但对为什么要学这些并没有仔细的思考。 在技术领域，有太多的东西会迅速的过时，如何利用有限时间，最大化你的长期收益？这里我可以给出几条建议 打造你的工具箱 工欲善其事，必先利其器。每个
python 轻量化运维之一 Fabric 其实在Glow的技术团队中是没有全职的Ops或是Sys admin，我想很多小的创业团队也是如此。但是运维是整个产品发布过程中必不可少的一环，所以想写一个针对开发工程师（特别是Python工程师）的运维入门教程。如果你是专业的运维工程师，请不要浪费你自己的时间。 先说一下，什么是“轻量化运维”？简而言之，就是用最快最省事的方法做好最基本的运维工作。这里的工作主要包括以下几个部分 1. 生产环境服务器集群的日常管理 2. 自动化系统配置与代码发布 3. 系统状态与性能监控 今天先来聊聊服务器的日常管理。这里包括各种琐碎的任务，例如重启服务，安装或是更新软件包，备份日志文件或是数据库等等。通常对于这类任务，我们要解决两个问题 * 针对每项任务编写脚本，避免重复劳动。虽然许多运维都是Shell脚本达人，但大部分程序员看到Shell脚本都是一个脑袋两个大。 * 需要在许多台机器上执行同一项任务。 如果你碰巧对Python略知一二，那么恭喜你，从此以后你只要使用Fabric这个神器，就再不用为Shell脚本头痛了。 Fabric初探 - 执行单条指令 Fa
infrastructure 用户事件的存储与分析 许多时候我们说一款产品的设计是数据驱动的，是指许多产品方面的决策都是把用户行为量化后得出的。一个典例的例子就是注册流程的设计，如果用户需要填写的注册信息较多，一般就会分成多个页面，而产品设计师最关心的就是每个页面的流失率，从而不断的对这个流程作调整以达到信息量与流失率之间的平衡。 为了能够量化用户的行为，前提是要将各种用户事件都保存下来。其中最典型的事件包括user creation, page view和button click，但实际上还有许多其他事件，比如用户更改了状态或是录入了某些数据等等。目前有许多第三方的服务可以帮助你做这方面的统计，国内有友盟，国外有Google Analytics和Mixpanel。但如果你记录的事件数量非常庞大，或是对之后的数据分析有非常定制化的要求，那就要考虑自己构建事件分析的平台，而这个过程中最关键的一步就是如何存储用户事件。 首先我们来分析一下用户事件存储有哪些特性 * 数据量巨大 用户在应用中产生的事件数量远远大于他们产生的数据。非常简单的一个例子，就是用户在浏览各个页面时，他们并不产生任何数据，但却产生了大量的page view
