碎碎念写点什么东西吧，不成体系，想到什么就写什么吧。
文字越来越八股文，以前还写写随笔，写写一些读书感悟，彼时文字就像一只画笔，画出我内心的汹涌。
后面生活模式慢慢固定下来，工作日就是两点一线，休息日就是宅在家。生活虽偶有起伏，但已完全没有那种能唤醒文字欲望的场景。
每个人都是一头挨了锤的牛。
曾经壮志对生活保持激情，到头来发现对生活保持激情是需要资本的。但大多数人都在追寻这个资本的路上，不是渐渐对生活失去了激情，就是慢慢变得油腻了起来。
不像求学时那样傻，不像刚毕业时好奇万物，但也没有很油腻，没有为五斗米折腰。或许现在的自己，更像是慢慢变成恶龙的勇士吧。
总的来说，还是个好人。
年初定了个目标——今年能继续和女朋友走下去。
制定这么一个目标，多少有点令人匪夷所思。
但当时确实是想走下去又觉得有些风险，所以才制定这么一个目标，算是督促自己吧。
走到这儿颇多不易。时至今日，每一天都在感谢遇到了正确的人。
对日本的了解越多，越喜欢这个国家。
没去过日本，对日本所有了解都是从书本和纪录片中看到的。给人的感觉就是这是一个很简洁，很优雅，很适合人居住的国家。
读了一本《日本的细节》的书籍。对日本的生活更加憧憬。
从书中能看到日本的服务，生活品质等。但给我印象最深刻的，是租借服务。
比如租借衣服，租借宠物。这几年经历了多次搬家，越来越希望舍弃一些东西，但又不想放弃比较优雅的生活环境，不想降低自己的生活质量。所以每次搬家都很痛苦。如果能有这种租借服务，需要的时候租来用，不需要的时候还回去，该多好。
就像云计算领域，提倡的按需付费，按照使用的资源进行付费，节省企业很多资金。
如果生活中也有这种服务该多好。衣服可以租借，宠物可以租借，厨具可以租借，如果有这种服务，生活中就可以只保留必需的物品，其他的按需付费就好了。整个生活都很整洁。
后面有机会一定要去日本看一下。他们对待生活的态度深得吾心。
中国也有类似的服务出现，但是还不成熟。比如租借衣服这方面，有共享衣橱服务的出现，但远远达不到成熟可以大规模推广的程度。记得之前看过一篇报道，头部共享衣橱企业破产的报道。
好久没出去旅游了。
看到美丽的风景图片就会心动。
今年计划里也有和女朋友出去旅游一次的计划，但谁能想到这个疫情一直持续这么久，现在又有新的变种出现。这种情况下出去也不安全，只能老实待在家里。
等后面疫情消失了，或者至少稳定下来了，一定要和女朋友一起去新疆玩一玩。
学习了《Beautiful In White》，大概花了二十天左右。很简单。比那个简版卡农要简单太多。
想想简版卡农虽然比它难不少，但学习了好几个月才学会，好像也有点说不过去。但想到是学习的第一首曲子，对指法，键盘，识谱等都不熟悉的情况下，其实也还好啦。
正是因为在学第一首曲子的时候打下了一些基础，所以现在学习的才快了一些。
《Beautiful In White》这首曲子，出现了一些我不熟悉的内容，比如用到了D大调，A大调。本来以为很难，以为五线谱对应钢琴按键的位置全都会变，但后来跟一位学习钢琴七八年的小妹妹请教了下，发现并不是这个样子，其实要做的变更很少。比如D大调相对于C大调，在弹奏的时候，把C换成C#，把F换成F#就好了，A大调相对D大调，再把G换成G#就好了。还是蛮简单的。
对钢琴的关注越多，进步也就越快。
比如有很用心地找钢琴课程，找到了一个在线课程，感觉不错，但并没有报名，而是拿着它的大纲去自学。比如经常会跟小妹妹请教自己在乐理方面不懂的地方，比如延音踏板要怎么踩，乐句怎么呼吸等。比如在对键盘很熟悉的情况下，有刻意去练习视奏。比如有在蒙上眼睛的情况下练习左手盲弹和弦分解。比如有去了解各种大调的由来。
这个月对自己的进步很满意。后面也按照这个节奏继续下去。
但和自己预期还是有不小差距。在钢琴弹奏纯音乐这方面，差距在于就算对于简单的谱子，现在还不能熟练的进行视奏，这个后面再熟悉下，熟能生巧。对于流行音乐，民谣，在练习吉他的时候，更多的是关注伴奏，但对于弹唱来说最重要的应该是唱这部分。无奈我唱歌难听。所以打算下个月报个声乐班学习下，刚好取消了大小周，有足够的时间。声乐过关以后，后面起码可以用万能和弦弹唱。对于每首歌自己的谱子，再学的时候也能更关注唱。
前路虽长，但未来可期。
读书不少。可能是前段时间没怎么阅读，这段时间报复式读书。
有些书能引起我的共鸣，能让我学到不少东西。不管是工具书，还是传记类，还是纪实类，还是研究报告，都能学到不少东西。这也是我喜欢阅读的原因。而另外一些书，读完以后除了说一句666，没有更多感触。
这个月读的书中，对我触动最大的几本书，一本是《杜月笙传》，一本是《日本的细节》，一本是《阿里巴巴大数据之路》。
《杜月笙传》中讲述了杜月笙如何发家，发家以后如何做人等。我对杜月笙还是比较敬佩的。
他的一些观念非常认同。
比如花钱的态度，他说”花1文钱要收到10文钱的效果，这才是花钱能手 “。这句话说的就很妙。钱怎么花是一门很大的学问。花的正确，能起到事倍功半的效果。比如之前在做公众号阅读平台的时候，给一个爬虫的作者发了一个100块的红包，他就主动了解我的需求，然后看他的项目能不能满足我的需求，有什么更好的方法。从结果来看，这100块起到了成千上万块的作用，节省了我很多时间，并且也了解了一些其他的类似的产品，以及存在的法律风险。再比如，学习钢琴，跟那位小妹妹请教，发了一个50块的红包，我问的问题她就回答的很详细，并且后面我再问其他问题也非常及时回复。所以，钱这个东西，该花的时候别省，不该花的时候别动。
“不要怕被别人利用，人家利用你说明你还有用”这句话也很认同。利用这个东西也分两种，如果是被人当枪使，自己没有收益的被利用，这种要尽量避开。但如果是那种互惠互利的被利用，这种就应当尽力维护。人脉这个东西，就是基于被利用才建立起来的。资源交换也是一种利用。平时多想想自己能给别人带来什么价值，除了金钱上的，还有精神上的，这样才能走的够远。
《杜月笙传》给我另一点最大的感触就是，有钱没权，最多只是二等公民。钱在权的面前，只能算是个奴才。而枪杆子里面出政权。
《阿里巴巴大数据之路》这本书是挺偶然看到的。我想了解下在顶级互联网公司中，数据是如何被使用的，如何生产，如何存储，如何服务上层客户，给业务会带来什么价值。刚好看到了这么一本书。这本书还是不错的，涵盖了从数据埋点，数据收集，数据离线/实时计算，数据建模，数据应用，数据产品等各方面的知识。读完之后对数据如何为互联网行业赋能的认识加深了很多。同时也更加清楚我们团队一些数据产品的初衷。也看到了现在我们数据产品的不足之处。有些想法自己也是雾里看花，就想办法和其他团队的同学沟通，尽量看到全局，以及必要的细节，希望拨云见日，理清楚自己预期的样子，然后推进改变。
专业方面，只看书是不够的，还得经常参加一些技术分享，一些会议。听头部互联网企业是如何在数据治理，能从中吸收到很多知识。
尝试了一下Spark3。之前写的转化漏斗功能，由于底层计算框架是Spark2，而Spark2的UDAF实战在性能上有很大损失，这次换成了Spark3。性能测试的结果发现，会有3-5倍的性能提升。还是很不错的。
但这种方案也有一个缺陷。之前Spark2的UDAF可以在SparkSQL中全局注册好，然后用ThriftServer去进行调用。而在Spark3中，由于UDAF继承自Aggregator，而不是Spark2中的UserDefinedAggregationFunction，不满足Spark对UDAF的注册条件，所以不能直接注册好在ThriftServer中进行调用。解决方案也简单，就是自己写一个ThriftServer，然后供前台调用。因为基于Aggregator实现的UDAF可以在Spark中通过代码的方式注册，然后再调用sparkSession.sql()去进行调用，所以这种方案是可以走通的。
接口还需要提供能够kill查询的功能，这部分参考了ThriftServer的源码，通过JobGroup配合sparkContect.cancelJobGroup实现的，不难。
日常工作很多时间也在和帆软打交道。用的越多，越能发现这个系统的强大，但也越能意识到它的局限，和我们的不适配之处，也能发现我们这边流程上，底层基础设施的一些薄弱之处。
帆软提供的功能还是挺强大的，比如足够灵活，需要什么都可以让客户自己配置，比如强大的管理功能。但它也有一些局限，比如无法在执行查询时，无法根据Dashboard中选择的条件对数据集的SQL进行优化操作，去掉不需要的列，这就导致每次查询出来的数据比需要的要多，会产生额外的开销，特别是有聚合操作时。更好的方法应该是根据选择的条件，对底层数据集的SQL进行裁剪。
这个问题另一方面也不是帆软的问题。因为这就是一个很矛盾的点，一个数据集会被很多Dashboard用到，如果我们一个数据集兼容性做的足够好，查询的列足够多，那么就会牺牲性能。如果为了性能，每个Dashboard专用一个数据集，又会牺牲兼容性，同时存储压力，维护成本，复用性等方面都会带来压力。所以这就是很矛盾的地方。
另外一个突出这个矛盾点的地方在于，数据集的SQL，可以采用两种方式，一种是离线洗成一张宽表，然后SQL直接查宽表，这种方案的优点在于查询速度快，不需要进行shuffle，缺点在于复用性不够，维护麻烦，极端情况下就是一个数据集一张宽表。另一种方式是SQL将基础数据进行join，得到结果。这种方案灵活，但由于需要进行join，性能会有一定的损失。
我们数据都是放在Doris里面。Doris好用是好用，但有几个缺陷也愈发明显。
首先，就是多租户隔离机制做的不够好，我们有很多用户会去Doris里面查数据，其中有些SQL可能逻辑很复杂，时间范围又长，很容易导致整个集群的资源都被这个SQL用光，其他SQL无法用。而像SparkSQL，基于YARN时，是可以根据队列实现多租户资源隔离的。Doris在这方面的进展，在24号的开发者会议上提了一下，但感觉还做的不够好。
另一点，就是索引机制不够给力。我们经常会这么用，一张表里面有10个指标列，然后查询条件只有5列，其他列没有。这个就是我上面提到的，兼容性和性能取舍的问题。在Doris中，会为指标列生成前缀索引，但除非查询条件严格匹配前缀索引，否则相当于没用。Doris中提供了物化视图这个概念来解决这个问题，大意就是在原表的基础上新建一个物化视图，然后你可以通过调整指标列的顺序，生成匹配的前缀索引。这个方案我认为有点鸡肋。因为在我们的场景中，为了兼容性，可能这张表查询条件中有一个指标列，两个指标列，n个指标列。我不可能每种条件都建一个物化视图，这样不仅存储成本会增加很多，而且数据插入速度也会慢。而且特别难维护。在Doris的开发者会议上，有位同学提出了用z-order的方式来解决这个问题，目前已经开发完了，具体机制我还没有深入研究。但带来的后果有两个，一个是对于能匹配上前缀索引这种反而会慢，另一个是数据插入速度会变慢。
Doris的数据摄入也存在一定的问题。如果要导入Hive数据，那么只能先生成Hive表，然后再通过文件的方式导入到Doris中。这一方面增加了工作成本，本来就是想把几张表join一下导入到Doris中，现在非得先在Hive中落一份一样的数据，然后才能导入Doris中，这就很不友好，另一方面还增加了存储压力。
Doris虽然有诸多问题，但是还是现阶段所有OLAP引擎中能满足我们需求的组件。毕竟对于这种要求高并发，秒级返回，灵活，支持join，且需要和MySQL兼容的场景下，能做到的引擎实在是很少。MOLAP，像Kylin，够快，但不够灵活。Druid，SQL支持不好。MPP架构的CK，不支持join，分布式特性运维太复杂，Presto，Impala，理论上来说由于没有数据本地性的特性，所以应该没有Doris快，但谁知道呢？现在Doris大多数也是把T-1的数据先聚合好然后导入进入，然后查询而已。完全没有用到数据实时摄入，实时聚合的特性。那Presto或者Impala会不会速度比它更快呢？而且还不需要把数据先生成到Hive再导入Doris。是一个值得探索的方向。只是对于有一些需要数据实时摄入的场景，这个就满足不了了。但这种任务很少，这种就需要去沟通了。
本月支出和预期大致相符，有少部分预期之外的支出，但不存在胡乱消费的情况。
这个月在持续买入食品饮料行业的基金。先是月初把标普中的50%转换成食品饮料基金，然后工资中的一部分也买入了食品饮料，月末又把剩余的标普全都转换成了食品饮料。一顿操作下来，到现在基金收益率-5.6%。
但丝毫不慌，下个月工资发下来还会继续买入食品饮料。
逻辑是食品饮料中的企业，像五粮液这种，市盈率已经到了21左右了，食品饮料中的企业大多市盈率在20-50之间。相对于半导体行业动不动100多的市盈率，食品饮料更加稳健，未来收益率我相信会更高。
最近没有关注基金新闻，没有关注动向。如果动向在吹其他的板块，或者唱衰消费，那大概率食品饮料就要反弹了。
九月份计划
写在这儿备忘。但切忌每天都检查一遍。
生活方面重要的事情:
- 学习《送别》(✔️)
- 进一步照着大纲学习乐理知识以及钢琴知识(✔️)
- 报名声乐课程并上两节课(✔️)
- 学习弹奏《Olimpica》(✔️)
生活方面不重要但最好能完成的事情:
- 追完《黑名单》(✔️)
- 周末有空再弹下吉他玩玩
- 找本书看(✔️)
- 发掘一些喜欢的钢琴曲(✔️)
工作方面重要的事情:
- 了解头部互联网企业如何进行数据治理(✔️)
- 想办法优化现在BI的流程(✔️)
工作方面不重要但最好能完成的事情:
- 了解核心链路上数据分析师们关注的数据内容(✔️)
- 了解头部互联网企业是如何利用数据实现流程上的优化以及带来更高的收益(✔️)
