20210126-20210130 阅读笔记

本周文章

写给一线分析师的几点总结

https://zhuanlan.zhihu.com/p/149400859

重点回顾：

好的分析就是一个「数据比较 -> 洞见 -> 业务优化」的过程。无论是哪种场景，「比较」都要具象化到实际业务场景才能提出可落地的业务洞见，而具象化的分析依赖一个关键工具：画像体系与业务指标体系。这个体系对业务的还原度越高，分析质量也越高，因此分析师团队要不断去「养」自己业务的画像指标体系。最直接「养」画像与指标体系的机制就是不断去用，每次应用所发现的问题持续小步迭代解决。

在对接一个业务需求的时候，分析师一定要搞清楚：

1. 这个需求围绕的业务目标（O）是什么，什么指标去量化 O？
2. 业务聊的核心用户群体是谁，什么维度可以量化这些细分用户群体？
3. 潜在的抓手（KR）有什么，业务提到了哪些，我们又可以举一反三出来哪些？

数据分析需求分为三类：
5. 基本型需求：分析师必须具备的能力与交付，是分析师做事情的行为底线。基本型需求完成不好的时候，再多的锦上添花也是徒劳，也会直接失去业务方的信任；
6. 期望型需求：一般业务与分析师正式拉会所讨论的项目与预期就在期望型需求的范围，这部分需求完成的越及时或者越多，业务方对数据分析的评价也会越高；
7. 惊喜型需求：主动分析，跳出业务的思考框架，数据分析产生的洞见帮助业务解决困惑，发现战略机遇，或者数据所提供的策略帮助业务完成难以达成的目标，就是惊喜性需求。惊喜性需求没有被满足业务不会不满，一旦被满足的时候业务的满意度是非常高的；

伴随业务发展 4 个阶段，对数据分析的需求：

• 第一阶段：从零到一，直觉驱动业务野蛮生长。需求：** T+1 准确反映业务 OKR 指标表现，分析师及时做好 BI 角色支持**。
• 第二阶段：增长放缓，实验评估助力业务小步迭代。为业务提供的关键价值就是：引入实验机制，以 AB 测试为典型的统计方法可以精确、科学的度量每个实验的微弱效应，帮助业务在投石问路过程中「听到」方向。
• 第三阶段：增长遇到瓶颈，数据驱动业务找到新目标体系与增长发力点。需求：深度思考业务问题并主动提出需要数据分析的问题。
• 第四阶段：数据持续驱动细分人群的差异化策略迭代。需求：在细分用户群体粒度整合阶段二的实验能力和阶段三的观测性研究能力，打通数据驱动细分策略迭代的流程。

思维方式

科技爱好者周刊（第 144 期）：提高收入的根本途径

http://www.ruanyifeng.com/blog/2021/01/weekly-issue-144.html

• 你需要的不是"水平方向的努力"，而是"垂直方向的努力"

996的几个不同面相

https://mp.weixin.qq.com/s/rmYagBadh6L7n3ZOMrHK7Q

• 这些问题能够完美解决，两全其美吗？应该可以，不过需要团队有很高的平均素质，也需要领导者有很高的管理水平。
• 评论：我觉得根源在于劳资双方的议价能力太悬殊，资方因为资本的优势（大多数行业，大多数时间，都是资本更稀缺）议价权远远大于劳方，而分散的个体劳方没有任何反制手段。但是如果劳方能聚合起来凝成一股绳来讨价还价，有没有胜算？当然要，现实中早已有先例。问题是能拧成一股绳吗？难，原因没法说。就因为老板们看清了这个，才敢恬不知耻地说“福报”。

996 体现的，其实是因为国内大部分公司管理水平偏低，管理上只能这么一刀切。但是有这么大的话题度，还是在于公司和员工之间权利的不平衡。一个员工在面对 996 的时候，失去了“选择权”。在公司利益和个人利益之间，只能服从公司，完全没有说“不”的权利。
因为对公司说“不”，只有两个下场，一个是自己走人，一个是别人顶上来，自己（薪资）下去。而对公司一味服从，又意味着透支自己的身体和健康。
人们的关注点并不是这些现象，而在于怎么解这个两难的困境。希望随着社会的发展，管理层的水平能够慢慢提高，不需要 996 也能保证产出。员工之间也能逐步形成保证员工整体利益的组织。

数据库

唯一约束带来的锁问题：原因在于数据在未提交前，也会先写入索引，相同数据再次写入时，由于索引的键值重复，只能等待。

多索引会带来的问题：除了对 DML 操作的影响。也会导致优化器评估成本的时间加长，因为优化器会尝试评估每条符合条件的索引的执行成本。

PG CBO 算法

https://billtian.github.io/digoal.blog/2016/02/03/01.html

pg_hint_plan

https://zh.osdn.net/projects/pghintplan/
https://github.com/ossc-db/pg_hint_plan

优化器
https://www.postgresql.org/docs/12/planner-optimizer.html

The planner/optimizer starts by generating plans for scanning each individual relation (table) used in the query. The possible plans are determined by the available indexes on each relation. There is always the possibility of performing a sequential scan on a relation, so a sequential scan plan is always created. Assume an index is defined on a relation (for example a B-tree index) and a query contains the restriction relation.attribute OPR constant. If relation.attribute happens to match the key of the B-tree index and OPR is one of the operators listed in the index’s operator class, another plan is created using the B-tree index to scan the relation. If there are further indexes present and the restrictions in the query happen to match a key of an index, further plans will be considered. Index scan plans are also generated for indexes that have a sort ordering that can match the query’s ORDER BY clause (if any), or a sort ordering that might be useful for merge joining (see below).

https://dba.stackexchange.com/questions/274926/slow-planning-time-on-postgresql-12-4

having many similar indexes on a table is not a good idea: data modification time and query planning time will increase (the latter because the optimizer has to consider all indexes).

其他

10万座大坝的诞生！

https://mp.weixin.qq.com/s/cLiEv282p1PXQ93u_NW39w

pyecharts

https://pyecharts.org/#/zh-cn/intro