叶剑烨

叶剑烨

Head of Technology at Glow

中国,上海
8 posts
Website
data-visualization

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

在上篇结尾处我提到“如果现在让我重新选择,我会使用哪个可视化工具?”我的答案是 Redash,原因主要不是功能层面,而是技术层面。本篇就从项目关注度与活跃度,项目的技术架构,源代码的规模与质量,这三个方面来比较一下 Superset,Redash 与 Metabase。 关注度与活跃度 看一个项目在 Github 上的星数,是评判一个项目成熟度最快速的方法。**那除了星数以外,项目的 Github 页面上还有什么重要信息呢?这里我建议大家去看一看项目的 Insights。**首先我们来看 Superset 最近一个月的活跃度 这张图告诉我们以下几个信息 这个项目最近一个月有 53 个提交,说明项目仍在积极开发中。图中显示项目在最近一个月有新增 21 万行代码,这主要是因为提交了一个巨大的地理数据文件,去掉这个文件之后,实际新增的代码行数大约为 2000 行。 从新增和处理的 Issue

data-visualization

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

人是视觉动物,要用数据把一个故事讲活,图表是必不可少的。如果你经常看到做数据分析同事,在SQL客户端里执行完查询,把结果复制/粘贴到Excel里再做成图表,那说明你的公司缺少一个可靠的数据可视化平台。数据可视化是Business Intelligence(简称BI)中的核心功能,有许多成熟的商用解决方案,如老牌的Tableau, Qilk,新生代的Looker,国内的FineBI等等。不过对于许多小公司来说,这些服务的License费用是一笔不小的开销,且有一种“杀鸡用牛刀”的感觉。那在开源软件如此发达的今天,在数据可视化方面,有什么靠谱的方案可以选择呢?今天给大家介绍三个比较知名的项目,分别是Superset, Redash和Metabase。前两个我都在产生环境中实际使用过,在本文中会重点介绍。Metabase我只是试玩了一下,但我觉得这是一个非常有想法的项目,所以也会和大家聊聊我对它的看法。 选择一个称手的工具,功能上能满足我的需求肯定是首要的。就先从功能需求讲起,我们的数据仓库用的是Amazon Redshift(如果你没听过Redshift,就把它看作是为大数据优化过的PostgreSQL),所以大部分的实际用例都是要将一个SQL查询的结果可视化。我们所需的图表类型也就是常用的那几种,包括折线图,柱形图,

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_

devops

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

排查性能问题往往比排查功能性的Bug更让人头疼,主要有以下几个原因 很多性能问题只会在高负载的生产环境下出现,在开发过程中很难发现。 功能性出错时我们通常会抛出异常,我们可以通过Tracestack很快定位到问题所在代码的位置。但对于性能问题,我们很难做这样的快速定位。 虽然我们有各式各样的Profiling工具,但适用于对生产环境的并不多。当然这因编程语言而异,Glow服务器端的技术栈是Python + Gevent,目前为止我们都没有找到合适的Profiling工具。 对于服务器端的性能问题,我们常用的方法是写日志文件,例如把每个请求的响应时间都记录下来,但对海量日志文件的存储,聚合与分析又成了另一个麻烦。常用的解决方案有ElasticSearch + Logstack + Kibana,或是StatsD/CollectD + Graphite等等。在Glow,对于性能监控这样的通用服务,我们更偏向于选择云服务,而不是自己去维护这些系统,这样我们的精力才能集中在产品研发上。 在对于性能监控类的云服务做了一些横向比较后,我们选择了Datadog,使用一年多,感觉很不错,所在在这里分享给大家。 Datadog简介 Datadog的工作方式是在每一台需要监控的服务器上运行它的Agent。Agent不但会收集这台服务器的各类基础性能数据,如CPU使有率,剩余内存空间,剩余磁盘空间,网络流量等,也可以收集用户自定义的性能数据,灵活性很好。

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 │   ├── monitors.py │   ├── mysql.py │   ├── nginx.py │   ├── redis.

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工程师)的运维入门教程。如果你是专业的运维工程师,请不要浪费你自己的时间。 先说一下,什么是“轻量化运维”?简而言之,就是用最快最省事的方法做好最基本的运维工作。这里的工作主要包括以下几个部分 生产环境服务器集群的日常管理 自动化系统配置与代码发布 系统状态与性能监控 今天先来聊聊服务器的日常管理。这里包括各种琐碎的任务,例如重启服务,安装或是更新软件包,备份日志文件或是数据库等等。通常对于这类任务,我们要解决两个问题 针对每项任务编写脚本,避免重复劳动。虽然许多运维都是Shell脚本达人,但大部分程序员看到Shell脚本都是一个脑袋两个大。 需要在许多台机器上执行同一项任务。 如果你碰巧对Python略知一二,那么恭喜你,从此以后你只要使用Fabric这个神器,就再不用为Shell脚本头痛了。 Fabric初探 - 执行单条指令 Fabric可以通过pip来安装 pip install fabric 它的功能是将一个任务通过ssh在多台服务器上执行,而每个任务可以是单条shell指令或是一段python脚本。一个最基本的例子

infrastructure

用户事件的存储与分析

许多时候我们说一款产品的设计是数据驱动的,是指许多产品方面的决策都是把用户行为量化后得出的。一个典例的例子就是注册流程的设计,如果用户需要填写的注册信息较多,一般就会分成多个页面,而产品设计师最关心的就是每个页面的流失率,从而不断的对这个流程作调整以达到信息量与流失率之间的平衡。 为了能够量化用户的行为,前提是要将各种用户事件都保存下来。其中最典型的事件包括user creation, page view和button click,但实际上还有许多其他事件,比如用户更改了状态或是录入了某些数据等等。目前有许多第三方的服务可以帮助你做这方面的统计,国内有友盟,国外有Google Analytics和Mixpanel。但如果你记录的事件数量非常庞大,或是对之后的数据分析有非常定制化的要求,那就要考虑自己构建事件分析的平台,而这个过程中最关键的一步就是如何存储用户事件。 首先我们来分析一下用户事件存储有哪些特性 数据量巨大 用户在应用中产生的事件数量远远大于他们产生的数据。非常简单的一个例子,就是用户在浏览各个页面时,他们并不产生任何数据,但却产生了大量的page view事件。所以事件数据的量往往是主数据库的几十倍甚至上百倍。 不一致的数据结构 虽然所有的事件都有一些公共的属性,比如事件名称,事件时间,应用的版本与操作系统等等,但有很多事件有自己特定的属性,比如用户注册事件,我们会非常关心注册的渠道,是用email注册还是用社交网络注册(比如微博,微信等)