记一次使用jupyter做数据分析

背景

因为工作需要，最近做了一次数据分析，用于洞察客户的使用情况及服务运行情况。

由于整个体系接触的比较少，因此做一下记录。

数据分析的结构

在 数据分析 这项工作中，有如下环节：

  • 确认需求，明确想要分析的问题是什么，预期的产出是什么
  • 确认数据源，明确数据的结构、格式、数据量等
  • 确认数据逻辑，明确需要分析的问题所需数据是否到位
  • 做数据预处理，数据清理、异构数据格式转换
  • 查询的语句、分析的代码编写 (eg: sql、numpy 等)
  • 数据可视化，图表绘制 (eg: BI 工具、excel、echarts、plotly 等)
  • 数据结果的分析与说明 (eg: doc、slides、pdf 等)

在本次的分析中，我的选择如下：

  • 确认需求： 分析客户基本特征、系统使用特征、磁盘空间占用分析

  • 确认数据源： postgresql 数据库备份、du 结果文件

    1
    2
    3
    4
    5
    6
    7
    8
    9
    [root@iZ2ze6jqzxxt4hf0qgpcglZ fordisk]# ls -lh
    total 13G
    -rw-r--r-- 1 root root 1.1K Mar  7 21:50 df.log
    -rwxr-xr-x 1 root root  292 Mar  7 21:42 getdiskusage.sh
    -rw-r--r-- 1 root root  929 Mar  7 22:53 minio_disk_usage_info.log
    -rw-r--r-- 1 root root 6.0G Mar  7 23:31 minio_disk_usage.log
    -rw-r--r-- 1 root root 3.4G Apr  7 17:09 minio_disk_xx1.log
    -rw-r--r-- 1 root root 3.4G Apr  7 17:16 minio_disk_xx2.log
    -rw-r--r-- 1 root root  770 Mar  7 22:22 nfs_disk_usage_info.log

  • 确认数据逻辑： 分析 pg 数据库表结构及逻辑关系，确认 du 数据与业务含义

  • 数据预处理： ① 对 pg 的数据做拆分聚合，形成多张能直接查询的表； ② 对 du 结果做处理，以关系数据的方式写入 pg 库中。

    1
    2
    3
    1. 去除 pg 中的无用数据
    2. 使用 CREATE TABLE xxx AS SELECT * FROM xxx WHERE xx and xx; 的方式创建能直接使用的表
    3. 写脚本将 du 的结果变成 csv 格式，并使用 COPY xxx FROM 'xxx.csv'      WITH ( FORMAT csv, DELIMITER ',', HEADER false); 导入到 pg 数据库

  • 查询的语句： 拆分需求所需的关键分析项，写 sql 查询，对查询结果做进一步处理得到所需结构。 工具上，使用 jupyterhub，所有操作均在 jupyter python note 中完成。

  • 数据可视化： 根据需求，使用 pie、bar、line、heatmap、pareto 等图进行展示。 工具上，使用 plotly，直接在 jupyterhub 上生成图表。

折线图

柱形图

帕累托图

  • 数据结果的分析与说明： 直接使用 jupyterhub，使用 markdown 写结果分析。整个文件以 html 的方式导出图表和分析结果。

一些坑点/趣点小记

jupyter 的导出问题

按理，jupyter 是可以直接导出 pdf、html、slides 之类的，本想导出 pdf ，但要导出 pdf 需要各种插件依赖，我们的 jupyterhub 是用 centos 装的，依赖安装很难搞，建议用 ubuntu 装 jupyterhub。
最后无奈，只有导出 html ……

note 的数据大小问题

一般而言，jupyterhub 要使用域名，就会在前面挡一层 nginx，我们也用的这种方式，但没有配置上传的 body 大小限制，默认是 1MB，超过就会报 413 错误，具体可以参考 nginx 官方文档 ，可以设置为 20MB，大点的 note 也差不多在这之内。

导出的 html 有点丑

jupyter 导出的 html 既有 code 块 也有 输出块 (eg: 图表) 也有 文本块 (markdown)，但实际上对外分享时不需要 code 块，隐藏的方式在网上有一些用 plugin 的，简单尝试了下有点难搞，于是就在 html 的样式上下功夫，为了去掉 code 部分，添加了如下 style:

1
2
3
.jp-CodeMirrorEditor.jp-Editor.jp-InputArea-editor {display: none;}
.jp-InputArea.jp-Cell-inputArea {display: none;}
.jp-OutputArea-child:has(pre) {display: none;}

不得不说， css 选择器中加了 has 这种能力后，父节点选择直接方便了不少

另外，默认的字体大小为 14px，改了下 css 变量 --jp-content-font-size1: 18px，好看多了。

sql 中直接做分组也挺方便

除了常用的 to_char(created_at::DATE, 'YYYY-MM-DD') as day 、date_trunc('week', created_at::date) as week 这种时间分组操作外，还可以使用 cross join lateral (values (max_kb / 1024)) xx (size_mb) GROUP BY xx.size_mb 这种横向 join 的能力。

之前还有一些分组是在 python 脚本里手写的，但其实 sql、python 的 numpy 库中都可以直接做分组聚合，挺方便。

结合 AI ？

很多数据分析其实都是很常规的，比如统计信息，一定程度上算得上是 机械重复的工作 ，那么结合 AI 就是一个比较容易的事了。 相信很多团队都会在这个方向搞些事情，尤其是那些专门做 BI 工具的公司。(比如: power BI、tableau、神策？等)

从结合的方式来看，如果结合 AGI 例如 GPT，小团队使用还好，大团队的安全担忧会比较大。如果使用特定领域的 AI，那么问题就会变成 如何让 AI 理解业务结构的问题。会存在结构化或非结构化的方式，非结构化对应类似 GPT 的 prompt。

jupyter 的 runtime 模式有点意思

jupyter 的特点主要是 code 和 markdown 的结合。当另外一点我认为也很有价值： runtime 保持。这对我们学习脚本语言的体验有很大提升，相当于一直处于断点模式，并且还可以随意修改下一个断点前的代码。

其他的工具

在准备做这项事之前，花了一小段时间去调研用什么方式管理要做的事，最简单的例如：excel 图表 + 文档 的方式，这种方式管理起来很麻烦。于是想到了可以直接进行代码交互的方案，例如 jupyter notebook。 其实，这种工作属于 数据分析，而数据分析有更多专门的工具，主要的诉求有如下：

  1. 连接各类数据库
  2. 对连接的数据源进行查询，并对结果做处理
  3. 生成图表
  4. 结果的分析记录
  5. 对外分享分析结论

jupyter 算是一个比较通用的 python / nodejs 工具，但在数据分析方面的使用成本还是挺高的，例如连接数据库等等 (当然也有一些 jupyter 的插件能做到这件事)。

上面提到过的 power BI、tableau 在上手难度上很低，都属于面向分析人员的低代码方案。

不得不说，这其中还是存在一些需求的，市面上也确实看到过一些类似于 jupyter ，但是提升了在数据分析方面能力的工具，比如: hex observablehq 。 count 直接在 canvas 上操作，交互体验更有意思。还有开源的方案 zeppelin 。

更进一步

熟悉 numpy 的使用

数据分析领域比较常用 python，主要是 python 下科学计算的库比较完善，比如 numpy，这次的分析中由于对 numpy 不熟悉，所以有些数据处理都是手写的，拉低了效率。

之后可以在 numpy 等工具应用上多看一下，同理 plotly。

了解更多的数据分析方案

用 OLTP 关系数据库分析在少量数据时挺好用，但大数据量下性能就不大行了，比如千万级以上的数据，这种时候得使用其他方案了。

  • 数据库: clickhouse、hive、cassandra、hbase、mongodb、redis、rds……
  • 分布式存储: hadoop(hdfs)、s3
  • stream: kafka、rocketmq、flume
  • 任务与计算: flink、spark

在数据分析之后，还有 AI 算法和模型训练，然后才能接上 AI

调研过程中发现 smartbi 在做类似的接入了~

未来 20 年是 AI 的时代，拥抱数据分析、拥抱 AI

Ignorance never settles a question.
— Benjamin Disraeli