生而为人

程序员的自我修养

0%

Posted on In

运行

win+R mstsc 远程连接

certificate

win search 中 搜cert即可

Posted on

[3/24 10:17] Bolun YaoNew Bing又增加了什么神奇的监测机制，现在挂私人梯子完全上不去了
今天之前还没什么问题，现在会被疯狂redirect到“国内版”，即便偶尔打开 chat 一次也会报错 looks like your network settings are preventing access to this feature.
全局也没用了，这怎么检测到的

[3/24 10:50] Ray Sun
清 cookie，或者 ?mkt=en-US ？
​[3/24 10:51] Ailing Ji
我倒是不会，你是关闭过浏览器吗，设置一下url参数：setlang=en&cc=us
<https://teams.microsoft.com/l/message/19:9268e0678e654fc1a8965e739a1859ec@thread.skype/1679626207358?tenantId=72f988bf-86f1-41af-91ab-2d7cd011db47&amp;groupId=2e06e852-2e42-4acb-a366-5df01ee87a68&amp;parentMessageId=1679624261164&amp;teamName=Suzhou Life&channelName=General&createdTime=1679626207358&allowXTenantAccess=false>
关闭浏览器试过了，清cookie 和 mkt 还没试。不过有个更根本的问题是即便想办法打开 chat 也会报错 looks like your network settings are preventing access to this feature.
貌似最近有些 IDC 的 IP 段也被 new bing ban 了，可以在梯子上套一层 cloudflare warp

Posted on

推荐chatgpt。用公司的 150刀 azure credit，把chatgpt 和 speech recognition, text to speech 连起来，就是一个超棒的英语口语陪练了

Posted on
  1. 在driver打印spark所有参数，包括默认参数

Posted on In

join

1. 大表join小表

产生原因：

解决方案：

使用mapjoin，spark程序则广播小表

1
/*+ mapjoin(table_aliases) */

2. 某些key数量过大

产生原因：join过程中，某些key数据量大，导致某些节点的处理数据明显多于其他节点。

解决方案：

进行数据拆分，将量大的key单独处理

示例：

数据倾斜优化——某些key过多

聚合

Posted on 
1
2
3
4
5
spark.sessionState.conf.setConfString("spark.sql.streaming.minBatchesToRetain", "5")
logger.info("spark.sql.streaming.minBatchesToRetain:" + spark.sessionState.conf.minBatchesToRetain)
logger.info("spark.sql.shuffle.partitions:" + spark.sparkContext.getConf.get("spark.sql.shuffle.partitions"))
logger.info("spark.sql.streaming.multipleWatermarkPolicy:" + spark.sparkContext.getConf.get("spark.sql.streaming.multipleWatermarkPolicy"))
val logSparkConf = config.getConfig("logSparkConf")

Posted on In

grouping sets 要保证sets中每个组合中缺失的维度，不能包含null值

group语法增强，可以使用维度下标表示，但如果grouping sets不支持，只能写字段名

Posted on In

Join 类别

1. inner join

2. left/right join

3. cross join

4. left/right semi join 半开连接

LEFT SEMI JOIN:左半开连接会返回左边表的记录，前提是其记录对于右边表满足ON语句中的判定条件。对于常见的内连接（INNER JOIN），这是一个特殊的，优化了的情况。大多数的SQL方言会通过in…exists结构来处理这种情况。

  • 只会保留左/右表中能关联上的数据，且数量不会受另一张表影响而膨胀（即在原表中是几条数据，结果还是几条）

总结：

对待右表中重复key的处理方式差异：因为 left semi join 是 in(keySet) 的关系，遇到右表重复记录，左表会跳过，而 join on 则会一直遍历。
left semi join 中最后 select 的结果只许出现左表，因为右表只有 join key 参与关联计算了，而 join on 默认是整个关系模型都参与计算了。

5.