pandas和sql各自擅长的领域

[Onlymoi]

你这图很高级呀，还是活的图。

你也可以用。网络上的tradingview

[fantasist]

你自己的贴子也是两种语言混一起, 很常见, 没问题

sql的可读性比熊猫草创的玩意儿还是强, 更何况是零学习成本

我给的sample code全部是纯python语法，除了那个.where(sql_query)只是举例说明非要按基本没什么人用的sql语法写也能运行而已。
你推荐polars没问题，但它主要也就是相对于pandas有更多perf优化，用法实际上大同小异，文档里完全没有推荐往语句里嵌sql：https://docs.pola.rs/user-guide/migrati ... -predicate

你推荐sql估计是没体验过复杂analytical data transform pipeline的痛苦，比如这种屎山：
(SELECT max(c1) as max_c1, mean(c2) as avg_c2, c3
FROM table1
WHERE xxx
GROUPBY c3) AS t1,
(SELECT c1, count(c2) as cnt_c2, sum(coalesce(c3, NULL, 1)) as sum_c3
FROM table2
WHERE yyy
GROUPBY c1) AS t2,
SELECT t1.c3, t1.max_c1, t1.mean_c2, t2.cnt_c2, ...
FROM table1 join table2 on (t1.c3 = t2.c1)
WHERE ccc and ddd
ORDERBY ...

一坨几百上千行的sql query，mix各种agg函数和coalesce，尤其是array与string操作非常不方便，看着瞎眼不说，随便改一点就出错要调半天。碰到复杂函数就会碰到framework dialect不兼容的问题，在SF上写的query跑到spark上运行不了，或者做不到一个query打通spark batch和flink streaming。实际可用性比能分步unit testing的python代码差几百条街。

[xyzcrai]

数据太大的话pandas 内存不够用，只能用sql之类的数据库。数据小的话pandas全在内存里操作，当然快很多。但pandas的命令确实是狗屎一样，需要重复打的字太多。

[wokao]

这个屎山用pandas一样很屎

实际上duckdb sql可以这么写, 可读性很好. 当然也能分成三步, 如果要debug

WITH t1 AS (
SELECT
MAX(c1) AS max_c1,
AVG(c2) AS avg_c2,
c3
FROM table1
WHERE c2 > 100
GROUP BY c3
),
t2 AS (
SELECT
c1,
COUNT(c2) AS cnt_c2,
SUM(COALESCE(c3, 1)) AS sum_c3
FROM table2
WHERE c1 IS NOT NULL
GROUP BY c1
)
SELECT
t1.c3,
t1.max_c1,
t1.avg_c2,
t2.cnt_c2,
t2.sum_c3
FROM t1
JOIN t2 ON t1.c3 = t2.c1
WHERE t1.avg_c2 > 50
ORDER BY t1.max_c1 DESC;

我给的sample code全部是纯python语法，除了那个.where(sql_query)只是举例说明非要按基本没什么人用的sql语法写也能运行而已。
你推荐polars没问题，但它主要也就是相对于pandas有更多perf优化，用法实际上大同小异，文档里完全没有推荐往语句里嵌sql：https://docs.pola.rs/user-guide/migrati ... -predicate

你推荐sql估计是没体验过复杂analytical data transform pipeline的痛苦，比如这种屎山：
(SELECT max(c1) as max_c1, mean(c2) as avg_c2, c3
FROM table1
WHERE xxx
GROUPBY c3) AS t1,
(SELECT c1, count(c2) as cnt_c2, sum(coalesce(c3, NULL, 1)) as sum_c3
FROM table2
WHERE yyy
GROUPBY c1) AS t2,
SELECT t1.c3, t1.max_c1, t1.mean_c2, t2.cnt_c2, ...
FROM table1 join table2 on (t1.c3 = t2.c1)
WHERE ccc and ddd
ORDERBY ...

一坨几百上千行的sql query，mix各种agg函数和coalesce，尤其是array与string操作非常不方便，看着瞎眼不说，随便改一点就出错要调半天。碰到复杂函数就会碰到framework dialect不兼容的问题，在SF上写的query跑到spark上运行不了，或者做不到一个query打通spark batch和flink streaming。实际可用性比能分步unit testing的python代码差几百条街。

[TheMatrix]

这个贴我跟下来之后有两点看法：

1，解了我一点疑惑：大家总是说pandas好，我也看过好几次，每次都感觉和SQL的功能是重复的。是不是有什么功能是我没学到的，而且是SQL做不了的？答案是没有。

2，pandas的好处在于和Python的interoperability。如果主程序是python的话，确实，pandas更方便，比SQL方便得多。

一个问题：df[df['age'] > 30]，这里写法用到了Python操作符重载吧？

[hci]

是的。本质上，pandas这种数据处理语言是一种DSL（domain specific language），不是一种全功能的程序语言，所以需要有比较好的与原生语言的互操作性，才觉得方便。

用duckdb的话，其实也可以弄得方便。duckdb是embedded，所以它的sql也是个DSL。比如你想unit test，很容易呀，开一个test db来测试呀，测完了删了就完了，与在python里写测试没区别。

以前大家不习惯给sql写测试，是因为是client/server结构，搞个embedded postgresql来测试是可以的，但一般人不知道，也不会弄，而且也比较重。其实就是个习惯问题。

这个贴我跟下来之后有两点看法：

1，解了我一点疑惑：大家总是说pandas好，我也看过好几次，每次都感觉和SQL的功能是重复的。是不是有什么功能是我没学到的，而且是SQL做不了的？答案是没有。

2，pandas的好处在于和Python的interoperability。如果主程序是python的话，确实，pandas更方便，比SQL方便得多。

一个问题：df[df['age'] > 30]，这里写法用到了Python操作符重载吧？

[hci]

Julia需要编译，这就让大多数数据语言用户不爽了。

julia
跟matlab及其相像, 改过一个matlab, 最主要的就是把矩阵索引的圆括弧改成方括弧

[wokao]

跟R和python一样都是支持交互的

google colab里唯三支持的语言

Julia需要编译，这就让大多数数据语言用户不爽了。

[pnlmpnlm]

这个贴我跟下来之后有两点看法：

1，解了我一点疑惑：大家总是说pandas好，我也看过好几次，每次都感觉和SQL的功能是重复的。是不是有什么功能是我没学到的，而且是SQL做不了的？答案是没有。

2，pandas的好处在于和Python的interoperability。如果主程序是python的话，确实，pandas更方便，比SQL方便得多。

一个问题：df[df['age'] > 30]，这里写法用到了Python操作符重载吧？

（1）公司里模型评估（model evaluation）和迭代（iteration）阶段主要依赖 MLflow、AutoML、Weights & Biases 等 MLOps 工具，感觉和SQL关联小。

在训练阶段，DS使用 版本化的静态数据集（TFRecord、HDFS 文件），这些数据是清洗好的不变的（read-only），会被反复用于不同模型架构的测试和对比。这个阶段不需要频繁地从数据库提取数据，那用SQL干嘛？

训练阶段以文件为中心（file-based），大家用pandas; production阶段以pipeline-based，依赖 Spark 或 SQL。

（2）再就是DS有时候其实也是快速响应一些想法的作用，毕竟也是搞笑的“Scientist”嘛，比如人家email给你一个比较大的不容易直接打开csv文件直接pd.read_csv就看到结果了然后1，2，3可以聊聊，但是如果用SQL先定义scema后画图看讨论一下？。。。。。反正我是觉得奇怪

（3）pandas 的优势不在“写 SQL 能不能实现”，是“能否把复杂逻辑用一行函数表达”。因为SQL函数是有限的但pandas 是可编程的，可以在 DataFrame 上运行任何 Python 函数。

比如工业上监控sensor，找出每个传感器最近 10 秒内斜率变化超过 3σ 的点

df["is_spike"] = (
df.groupby("sensor")["value"]
.apply(lambda s: np.abs(np.gradient(s)).rolling(10).apply(
lambda x: x[-1] > x.mean() + 3*x.std()
))
.reset_index(level=0, drop=True)
)

但是SQL要做到计算gradient，在滚动窗口里执行子窗口运算，用“上一行的导数是否超出 3σ”这种递推逻辑。反正我不会。在我看来，
pandas 是“任意函数 + 任意窗口 + 任意逻辑”，
SQL 是“固定函数 + 固定窗口 + 固定规则”。

（4）当然我的SQL就是从deltalake提取数时候用，别的倒不怎么用。水平太差不会写特别高级的SQL也是个主要原因。

[hci]

记得你推Julia好几次了，写个帖子宣传一下嘛。

跟R和python一样都是支持交互的

google colab里唯三支持的语言

[wokao]

针对你的第二点

result = duckdb.sql("SELECT * FROM 'huge_file.csv'").df()

针对你的第三点

duckdb允许用python写个函数, 然后sql里使用.

其实一般处理数据不会碰到这个. 而且这个用pandas也不如用julia

（1）公司里模型评估（model evaluation）和迭代（iteration）阶段主要依赖 MLflow、AutoML、Weights & Biases 等 MLOps 工具，感觉和SQL关联小。

在训练阶段，DS使用 版本化的静态数据集（TFRecord、HDFS 文件），这些数据是清洗好的不变的（read-only），会被反复用于不同模型架构的测试和对比。这个阶段不需要频繁地从数据库提取数据，那用SQL干嘛？

训练阶段以文件为中心（file-based），大家用pandas; production阶段以pipeline-based，依赖 Spark 或 SQL。

（2）再就是DS有时候其实也是快速响应一些想法的作用，毕竟也是搞笑的“Scientist”嘛，比如人家email给你一个比较大的不容易直接打开csv文件直接pd.read_csv就看到结果了然后1，2，3可以聊聊，但是如果用SQL先定义scema后画图看讨论一下？。。。。。反正我是觉得奇怪

（3）pandas 的优势不在“写 SQL 能不能实现”，是“能否把复杂逻辑用一行函数表达”。因为SQL函数是有限的但pandas 是可编程的，可以在 DataFrame 上运行任何 Python 函数。

比如工业上监控sensor，找出每个传感器最近 10 秒内斜率变化超过 3σ 的点

df["is_spike"] = (
df.groupby("sensor")["value"]
.apply(lambda s: np.abs(np.gradient(s)).rolling(10).apply(
lambda x: x[-1] > x.mean() + 3*x.std()
))
.reset_index(level=0, drop=True)
)

但是SQL要做到计算gradient，在滚动窗口里执行子窗口运算，用“上一行的导数是否超出 3σ”这种递推逻辑。反正我不会。在我看来，
pandas 是“任意函数 + 任意窗口 + 任意逻辑”，
SQL 是“固定函数 + 固定窗口 + 固定规则”。

（4）当然我的SQL就是从deltalake提取数时候用，别的倒不怎么用。水平太差不会写特别高级的SQL也是个主要原因。

[fantasist]

（1）公司里模型评估（model evaluation）和迭代（iteration）阶段主要依赖 MLflow、AutoML、Weights & Biases 等 MLOps 工具，感觉和SQL关联小。

在训练阶段，DS使用 版本化的静态数据集（TFRecord、HDFS 文件），这些数据是清洗好的不变的（read-only），会被反复用于不同模型架构的测试和对比。这个阶段不需要频繁地从数据库提取数据，那用SQL干嘛？

训练阶段以文件为中心（file-based），大家用pandas; production阶段以pipeline-based，依赖 Spark 或 SQL。

（2）再就是DS有时候其实也是快速响应一些想法的作用，毕竟也是搞笑的“Scientist”嘛，比如人家email给你一个比较大的不容易直接打开csv文件直接pd.read_csv就看到结果了然后1，2，3可以聊聊，但是如果用SQL先定义scema后画图看讨论一下？。。。。。反正我是觉得奇怪

（3）pandas 的优势不在“写 SQL 能不能实现”，是“能否把复杂逻辑用一行函数表达”。因为SQL函数是有限的但pandas 是可编程的，可以在 DataFrame 上运行任何 Python 函数。

比如工业上监控sensor，找出每个传感器最近 10 秒内斜率变化超过 3σ 的点

df["is_spike"] = (
df.groupby("sensor")["value"]
.apply(lambda s: np.abs(np.gradient(s)).rolling(10).apply(
lambda x: x[-1] > x.mean() + 3*x.std()
))
.reset_index(level=0, drop=True)
)

但是SQL要做到计算gradient，在滚动窗口里执行子窗口运算，用“上一行的导数是否超出 3σ”这种递推逻辑。反正我不会。在我看来，
pandas 是“任意函数 + 任意窗口 + 任意逻辑”，
SQL 是“固定函数 + 固定窗口 + 固定规则”。

（4）当然我的SQL就是从deltalake提取数时候用，别的倒不怎么用。水平太差不会写特别高级的SQL也是个主要原因。

传统data pipeline有很多数字column的aggregation操作，用SQL勉强可写，非要增强还有UDF之类的玩意，相信用过的人都说“好”。直到几年前还有不少人在红红火火地堆data pipeline屎山，一个模型能用几百种feature，我搞各种ML相关的Infra项目被恶心坏了，还好现在抛弃了这些垃圾。
这几年进入GenAI的时代，从文字到多模态数据的处理，肯定得写代码。反正我从没见过用SQL干活的AI engineer，很难想象谁会去用SQL函数实现给一个text column加chat template之类的操作。

[wokao]

首先得明确pandas和duckdb这类dataframe应用的典型场景, 只能在这些典型环境评价工具优劣

pnlmpnlm提了那个工业传感器的例子, 那个并非这类dataframe设计了干的, 用pandas勉强能干, 来证明pandas的优势, 犹如给CRV和RAV4（Pandas/DuckDB）装上好轮胎, 让它们去跑 F1 赛道（工业级复杂分析), 然后以成绩说明优劣

你看看他提供的那个嵌套lambda, 可读性极差, 还不好调试.

这个时候最好定义函数, pandas和duckdb都能干

传统data pipeline有很多数字column的aggregation操作，用SQL勉强可写，非要增强还有UDF之类的玩意，相信用过的人都说“好”。直到几年前还有不少人在红红火火地堆data pipeline屎山，一个模型能用几百种feature，我搞各种ML相关的Infra项目被恶心坏了，还好现在抛弃了这些垃圾。
这几年进入GenAI的时代，从文字到多模态数据的处理，肯定得写代码。反正我从没见过用SQL干活的AI engineer，很难想象谁会去用SQL函数实现给一个text column加chat template之类的操作。

[TheMatrix]

pandas 是“任意函数 + 任意窗口 + 任意逻辑”，
SQL 是“固定函数 + 固定窗口 + 固定规则”。

你这点总结的很好。

来我们拆分看一下：

“任意逻辑 vs 固定规则”：这点不清晰，我想了很久。我认为这应该是指程序的control flow，也就是让pandas和SQL干一个general programming language该干的事情。这件事情不容易，因为pandas和SQL的初衷都不是为了图灵完备。但是通过语法的补充，现在勉强都可以算图灵完备了。所以在这一点下我认为两者应该差不多。

“任意函数 + 任意窗口 vs 固定函数 + 固定窗口”：这个确实。明显pandas有优势。窗口操作在SQL中是很不容易的。而且还要配合上任意函数。pandas任意函数的优势还在于它和python的interoperability，这是一方面。另一方面还在于SQL缺少“集合作为元素”这个数据结构，所以定义集合函数的能力受到了限制。rolling(10).apply(f)在SQL里写很不方面，需要用python写好了，SQL调用才可以。

[TheMatrix]

比如工业上监控sensor，找出每个传感器最近 10 秒内斜率变化超过 3σ 的点

df["is_spike"] = (
df.groupby("sensor")["value"]
.apply(lambda s: np.abs(np.gradient(s)).rolling(10).apply(
lambda x: x[-1] > x.mean() + 3*x.std()
))
.reset_index(level=0, drop=True)
)

你这个逻辑拆分一下就是这样：

代码： 全选

def rolling_10_apply_f(s):
    #return transformed s
    t = s
    return t

df.groupby("sensor")["value"].apply(
    lambda s: rolling_10_apply_f(np.abs(np.gradient(s)))
    )

然后用SQL改写一下......也不容易。因为gradient和rolling_10_apply_f本质上都是窗口函数，它们要作用在“集合作为元素”上。这正是SQL缺少的数据结构。不是不能做，比较cumbersome。

[wokao]

做对比需要搞清楚, 不是 python + pandas 对 传统SQL, 那样胜之不武
而是python + pandas 对 python + duckdb

duckdb 原生支持 LIST (ARRAY) 类型，并拥有 LIST 聚合函数, 允许在 SQL 窗口中生成集合元素.

那个pandas处理工业传感器的程序不仅可读性差, 不容易debug, 而且计算非常低效: 由于相邻几个窗口都有大范围数据覆盖, 那个程序每次都重新计算 ...

这反映了pandas的弱点. 却被拿来证明pandas的优势

这种应用, 要么Julia, 要么用duckdb或者Polars

[hci]

DuckDB的SQL是扩展的，gradient descent, window aggregation 都是可以做的，几行代码的事。

你这个逻辑拆分一下就是这样：

代码： 全选

def rolling_10_apply_f(s):
    #return transformed s
    t = s
    return t

df.groupby("sensor")["value"].apply(
    lambda s: rolling_10_apply_f(np.abs(np.gradient(s)))
    )

然后用SQL改写一下......也不容易。因为gradient和rolling_10_apply_f本质上都是窗口函数，它们要作用在“集合作为元素”上。这正是SQL缺少的数据结构。不是不能做，比较cumbersome。

[hci]

对的。DuckDB的SQL可以实现所有ML需要的操作。

直接用数据库做ml是一个db研究热点。也是我老的开发兴趣和方向。在db里面做，优化机会很多。

做对比需要搞清楚, 不是 python + pandas 对 传统SQL, 那样胜之不武
而是python + pandas 对 python + duckdb

duckdb 原生支持 LIST (ARRAY) 类型，并拥有 LIST 聚合函数, 允许在 SQL 窗口中生成集合元素.

那个pandas处理工业传感器的程序不仅可读性差, 不容易debug, 而且计算非常低效: 由于相邻几个窗口都有大范围数据覆盖, 那个程序每次都重新计算 ...

这反映了pandas的弱点. 却被拿来证明pandas的优势

这种应用, 要么Julia, 要么用duckdb或者Polars

[pnlmpnlm]

首先得明确pandas和duckdb这类dataframe应用的典型场景, 只能在这些典型环境评价工具优劣

pnlmpnlm提了那个工业传感器的例子, 那个并非这类dataframe设计了干的, 用pandas勉强能干, 来证明pandas的优势, 犹如给CRV和RAV4（Pandas/DuckDB）装上好轮胎, 让它们去跑 F1 赛道（工业级复杂分析), 然后以成绩说明优劣

你看看他提供的那个嵌套lambda, 可读性极差, 还不好调试.

这个时候最好定义函数, pandas和duckdb都能干

不是lamda可读性差，主要DS，DA之类的都是exploration起家的大多数也不是正宗码农，也是为什么很多时候和SWE有冲突的原因，也是为什么DS DA喜欢jupyternotebook的原因。因为很多时候都是不断尝试，非常典型的在一个cell里面加一个，run一下；再加一个，再run一下，给个comments。不是为了production用。其实这个也许是pandas和sql如同关公战秦琼一样。客户群体和使用场景不一样。Pandas犹如电车，SQL犹如油车。一个适合相对人口多城市逛街买菜，一个适合冰天雪地荒凉小镇也能跑。可读性嘛，对于很多DS只要不递交给production team的时候，可读性就是自己读还有就是给和自己类似背景总干一样事情的人读，大家互相读的还蛮开心。
码农看到jupyter notebook眉头都皱起来了骂道外行；做exploration的私下说码农不就是修水管的么，有啥牛的

[cangyoujiacuo]

刚才我试了一下用duckDB把很多大文件先读进内存，然后在memory里排序->发布，如果文件数量少，速度还挺快的，但如果文件多，比如500个，每个2、3个G，就out of memory了，我相信调duckDB的spill to disk也是能过的。

所以，如果数据太大，还是得从磁盘上读然后自己fully streaming merge-sort，
相应地，如果是数据库，还是得在DB里干活才行啊。