@b1u2g3 巧了。。身边统计学结果：80% 除了 IDE 点 run 。编译报错得找运维给看

经验之谈。先拍脑袋写一个。然后再以事故为导向

@wmlz 我个人觉得 lz 吐槽的不是这玩意难安装，是被动接受，不愿意去接受。。

是的，可以用 NumPy 的广播功能来去除 for 循环。NumPy 是一个强大的科学计算库，它允许你对整个数组或矩阵进行快速操作，而不需要显式地编写循环。在你的例子中，你可以使用 NumPy 的布尔索引来直接设置 alpha 通道的值。

下面是一个如何用 NumPy 的广播和布尔索引来替换掉 for 循环的例子：

from PIL import Image
import numpy as np

def jpeg2png(path, name, mask=(255, 255, 255), limit=32):
img = Image.open(path)

arr = np.array(img.convert('RGBA'))

# 创建一个布尔掩码，其中接近指定 mask 颜色的像素为 True
mask_arr = np.all(np.abs(arr[:, :, :3] - mask) < limit, axis=-1)

# 设置 alpha 通道为 0 (透明) 在 mask_arr 为 True 的地方，否则设置为 255 (不透明)
arr[:, :, 3] = np.where(mask_arr, 0x00, 0xFF)

Image.fromarray(arr).save(f'{name}.png')

# 使用函数转换图片
jpeg2png('input.jpg', 'output')
在这个改写后的函数中，np.where 函数用于选择性地替换数组中的元素。mask_arr 是一个与输入图像同样形状的布尔数组，它标志了所有需要被设置为透明的像素。np.where 根据 mask_arr 的值来设置 arr 的 alpha 通道，如果 mask_arr 为 True 则设置为 0x00 ，否则设置为 0xFF 。

这种方法比双层 for 循环更有效，因为它利用了 NumPy 的内部优化来处理数组操作，从而可以显著提升性能，特别是在处理大图像时。


善用工具。。。

@wmlz 你这个逻辑是通的，就跟我说不应该运维管一样。运维如果是主动去接触的，没啥毛病，如果是被动的。就看谁拳头大。。这没啥好纠结的，打工嘛。。谁拳头大听谁的，不然就和稀泥。

对于这种疑问我都是一句回复：我有 32G 内存谢谢

举个简单的例子。假设研发想上 clickhouse 。。。是让运维去研究怎么部署。然后才能上么？最精通的应该是研发而不是运维吧。。。

@wmlz 这种类似的事情研发也跟我争论过。您说的确实也没错，关注不同的方向是会不一样的。但是，实际运维的工作是研发先研究，研究好了。这东西可以上了，提交给运维部署文档。运维按照运维部署文档操作。这事也是商量着来的，不能甩手掌柜啊。一般和合作多了的研发就会变成，商量一下，我先按官方的文档给你部，参数对不对我也不知道。研发你来看一下参数会实际产生什么后果，有什么重要的参数要注意的。是合作关系不是对抗关系。

我是运维。。。是我我也把锅甩出去。
原则：谁用谁研究谁第一次部署
运维有几个会写代码的？为啥是系统运维去首次部署？生产环境除外，生产环境肯定是厂商交接给运维，运维去维护。
第一次在开发环境弄的东西，麻烦金贵的研发先自己搞明白。出了问题别让我们运维抓瞎除了找厂商就是网上找文档

应该还是要以 debian 作为上游，自己维护软件库是理想但是不现实的。看了一下 LFS 的相关东西，也只是一个纯净的 linux 内核启动。然后就没然后了

不是。。没别的意思。技术人都是直来直去。。你要吹你的东西多好没问题。别整天想着搞个标题党然后就爆火了。就算是官方博客你即不是行业领袖也不是行业大拿。这个语气和内容完全不匹配。
想赚钱没什么寒碜的，光明正大的赚光明正大的打广告爱看的就看一眼，不爱看的就划过了。

@jheroy 哦。这玩意就是喜欢的特别喜欢，不喜欢的就是不喜欢。。。我是纯为了静音和相对手感好一点。还是和薄膜有区别的。。。静电容的有段落感。。当然，用机械轴的用惯了会觉得很奇怪

PS 一句。。刚顺手按回复了。

你这个无非就是一个 sql 的语法糖。那么问题来了，这个和预计算有啥必要的关系吗？？硬联系在一起？

我觉得做技术不能光做技术。还是要考虑点别的。

横竖你是不考虑成本的，但这通常又是选型中的重点。

就我自己身边的统计学来看，如果只是集中怎么查。怎么说呢。起步做大数据分析的时候考虑，但是不重要，只要满足 MVP 功能要求，这个事就算起步了，kpi 就算完成了，前端只要有时间随时可以换。在选型过程中反而最怕选这类没什么公司用过的。后面数据多了，就跳进去出不来了。学习成本是最大的成本，这是在很多做决策的人都明白的道理。这也是为什么最近出现的产品绝大部分是即支持自己的 DSL 又支持 SQL 。这是学习成本的一方面，另一方面，计算引擎和算法确实是核心，但是使用者不关心，作为大数据平台还关心一点：我能不能把这玩意很方便接入到别的平台上去。
metabase ，superset 这类就选起来没什么压力，不好用换一个就是了，想两套展示，一套研发自己看，一套给领导看。数据展示平台直接支持 sql 接入，轻轻松松，没工作压力。来个 dsl ？你要说服决策者会有很大的阻力。

对于决策选型的人来说，不会考虑实现细节。就几点：
1.能不能满足数据分析需求
2.成本多少。和别的技术比起来成本差异怎么样。成本包含计算成本，存储成本，人力成本和学习成本。
3.扩展性，n 年后，有新的技术出现，现在这个选型会不会成为阻碍。

OP 的产品只回答了第一个问题。

预计算成本在大数据+云平台的情况下成本只有存储成本。极其低廉。
绝大多数数据，早上跑个把小时，所有计算资源就可以释放了。只有少量的数据需要实时分析，这是实时分析的舞台。因为在这个博客里面有这么一句：“人工是最贵的开销。”。这句话我以前是信的，当然，现在用来推脱一些不想做的事也会说这句话。但这句话对于 99%国内公司不成立，人工反而是最便宜的开销。如果你现在就是 CEO 。。。你做几年老板就知道了。

只要看到发奇怪朋友圈的都直接仅聊天。这样才有看的价值