superguguji

[superguguji]

more~

- structural/relational data  - 范SQL计算(SQL, SQL-like such as Pig, DF) - Data Engineering/Analytics, Metric Computing, Reporting and dashboarding, monitoring, Business Intelligence

- matrix/tensor data - 范... 矩阵计算 ？ (Matrix computation, Tensor computation, ML, DL, Graphics, etc) - Data Science, Scientific Computing, Machine Learning, Deep Learning, Vision, Graphics... - This seems to be a much broader ecosystem and space and can potentially always find something interesting inside it :)  - 长期战略方向？ -- TA只是一个transition - Rec might always be a good 万用枢纽

[superguguji]

考虑以下这些因素吧, 从现实角度来说，肯定还是只能做incremental 的choice~

- 战略转型 -- 注意 C 几乎是一个和 AI同等重要的方向( 因为你不会直接做 appl)

- 能做啥项目, 能不能有意思的人一起做 :( 

- Drama（不心累）

[superguguji]

主要的问题

- 如何在”情怀” (R, OS, 深入思考问题 etc) 和”收入“直接找到一个平衡点。。。不能说是完全失败的，但是似乎总觉得有点不满意...

- 怎么完成战略转换. (假设是必须要完成的). 以及从执行线路来看，是否实现半 FI之后再做会更加轻松呢？

[superguguji]

基本思路

PT 依然是首选 (看两种engineer 相对收入吧~）另外考虑到long term, 按照存档同学的建议。 在我们这里搞 ML基本没啥大搞头。

:)  主要看有没有合适的项目以及坑不坑~

不然退而求其次分别是 流QL， 然后是我们自己的加强语言

最后是 interactive 问题是有意思的，但是也做了很久了~ 

[superguguji]

SQL+ML

Classic 的 In-DB ML: 

- 经典的 Towards a Unified Architecture for in-RDBMS analytics 和后续的 MADLib等一系列工作

- BigQuery ML:  https://dl.acm.org/doi/10.1145/3127479.3132746

Running ML as separate process (calling the like UDF): 

- SQLServer ML:  https://docs.microsoft.com/en-us/sql/machine-learning/tutorials/quickstart-python-train-score-model?view=sql-server-ver15

Just use SQL as a language (compiles to Kubernate)

- SQLFlow: https://arxiv.org/abs/2001.06846

Just a bridge:

- Run SQL on other SQL engines (e.g. MySQL, Hive..)

- Run the extension on Machine Learning library ...

..-_- 

DB4ML: 

https://dl.acm.org/doi/pdf/10.1145/3318464.3380575

这个工作有那么一点意思 :). 不过感觉没啥用哈哈哈 

https://arxiv.org/pdf/2004.05517.pdf

[superguguji]

年鉴

1. 往应用层（e.g. language 层， user 层) 靠，而不是底层 :) 

2. In-DB ML可以做着玩，但是应该很难有巨大的成功

[superguguji]

更多

回头看来（以及分析了一些为什么有些情况下会触动）， 本质上在追求以下两样东西的平衡点 

1. 高质量的，含有insight的可发表物（可以是paper, 但也可以是高质量的OSS code / design doc/blog / industry talk 等)

2. 合理的升值(哈哈哈，升值 = 升职 + 薪水) 真是太传神了. 

3. (implicit) 不要太心累。in general, 花很多时间想技术问题是可以的。但是一堆政治破事/周围的人很弱鸡/没有高质量的讨论 其实就很烦心

我们来分析一些case:

- Research Lab in general 是favor (1) 而稍微 sacrifice (2) 的。 当然根据个人品味不同， 我对 (1)都要提出一定的challenge. 比如IBM Research 做的是啥。。。MSR in general 做的感觉。。。也有点太偏了？当然这可能是个人品味。 

    * 比较有意思的一个东西 是 zeng 哥当年去的 CISL Lab，如果时机合适其实还不错(就是过两年要跑路) :). 唉，当年 CISL Lab intern 失败了 :(.. that’s fine. 有时候机遇比较可遇不可求

- Google 的一些好的项目 (赛车查询 / procella/ Dremel) 有不错的 (2) （当然还是比纯卖身慢）。 然后 (1) 是concede为很solid 的技术项目，但是发表物刻意的抹除了真正有意义的细节 (看看 Dremel/F1 Query / Procella的paper... :) ). 当年的 GFS / BigTable / MR真的是早期少见的机会~

- 边公司的魔方项目在当时看起来提供了不错的这个机会~

- 脸公司当时不确定性大。事后看来还是有一些平衡的。 当然 (1)并不顶尖 (AC同志的taste呀~  长劲鹿当然是有意思的，但在我看来insight 不足~ ). 后来的 好市多 倒是取得了不错的平衡。 别的很多项目饼画的不错但是执行的傻逼 （哼，鄙视某双木~)

- 失衡感的出现: 

    * 其实(2) 回头看来还可以（一开始慢了些，但不要忘了由于某些事情确实没法早点脱身）。 SA说的嘛，毕竟他们还是早了一些（真的,坑差好多！）。以及有些估计是卖身给business 了. 以及他们确实能力比我强半个档次，这个还是没办法的 , 要承认~ 而且考虑到我一开始由于某些事情算是浪费了一年把（否则可以早点脱身）。这个影响还是客观存在的 -- 注意到即使一开始做了正确选择基本上开头一年肯定也没法专心 。。。 :) ，也部分导致了选择偏保守所以选了双木（以及忽略掉了相对不��悉的流 或者 ai) 然后这个half又碰到黑天鹅，诸如此类。我觉得考虑到这些客观不利因素（都是存在的，不能否认，都是命） 其实做的不错了~

    * (1) 其实我的taste做的不差。但是我们的leadership 是傻子 ，没有大力宣传等～）。 另一个导致落差的就是其实在工业界给报告可能难以得到高质量的讨论回馈（可能和 M$的那个情况有落差把-- 但是其实退回来想，他们也未必有真正高质量的讨论回馈是不是？-- 在我们这儿可能还有更多真正insight的讨论了~). Academia 确实可能可以有更多志同道合的人讨论 （但是不要指望in genernal conference 上的人可以吐出啥象牙来～，主要还是可以有一些最好的大学的人关注把。

             + 这个很可能是落差的一部分，是否有高质量的发表是一方面，能否得到高质量的关注是另一方面 。 但这个in genenral industry 的发表物也没办法了~ （有个别exception， 比如火花， Flink, Kafka）。 你看看正常能做出来的不错的工作  ( 好市多， AC的工作) 也就这样了. 当然我们的项目本来其实是可以跻身exception的，但是你看这混乱，就没戏了～。这个有时候就是运气了～。撞上了就撞上了~ 。 那想想也还不错了 :) 

     * 另外就是没想到的(3). 哈哈哈，确实太动荡/胡闹了(不是一般的胡闹，看看宝石事件）。导致幸福感下降 :) (你看看有integrity的人都走了，确实没那么值得了。 本来没有(3)的问题 其实(1) 和(2)的平衡还可以的(参见之前的讨论，尤其是有些客观原因不能忽略)。但是(3) 真的太糟糕了所以不值得了~~ 我觉得也很合理....当然这种都是没办法的啦，不一定要怀疑战略层的思想

   * 其他的变数: 

         + Research Lab 对(2)比以前做的好一些了 （看YY也往上了，而不是万年的 entry level). 但是肯定还是没法和纯工业界比。 以及我也challenge过他们的 (1)没有想象的那么好

        + Google的一些好的项目似乎(1) / (2)兼顾的不错。 但注意其实他们的 (1)不行 -- 我们是有后门了解了细节觉得哇！ 但是你真的直接读paper... 不给你insight!

       + 边公司稍微出乎了我的意料。M$的那个工作乍一看还是有那么一点 (1)/(2) 兼顾的味道的 :)... 但是你真的仔细想，其实边公司的 (2)肯定没法比（因为猥琐的股票refresh). 以及其实 (3)很糟糕 （嘿嘿，经历过的人懂，肯定还是要m$坚持才能做出的）。 (1)么也还是比我们的差了一代把 (基本就是SOS��准的东西～）。简而言之：找到了一个各方面都差一些的平衡，哈哈哈哈。 当然可能有一定关注。但是我说了，只关心高质量关注~~

      + MS(哈哈，另一个MS) 核心思路在于我擦为什么他这么没品也能搞出(1) . 嗯。 一来这个工作确实相对localize (这点其实奶奶倒是也算中允）。 另来么，有时候是有机遇的 :) 碰到好机会猪都会飞呗 --有些人都更高级别去了~,你看in genenral他的taste , 这种也是客观存在的 -- 没有追求(1)但是撞上(1)，也要承认~ 统计结果应用于个体是有特例的，而且其实你看他没有讲清楚真正的核心insight :). 而且其实字母2也ack了我的东西品味更好，他的其实相对更classic ~. ) 我的东西其实scope更大~. 以及 (3)那可是吃屎到翔。            TL; DR就是其实他 (1)不好。哈哈哈。 撞上了一个还行的东西，但是还是没我行，以及他都没意识到真正的insight. 他本质上还是在优化 (2) （但是他也在追求一些别的东西）。 进一步佐证其实我 (1)/(2)的平衡做的很好~ (因为他(1)根本不行~ ； (2)方面没有客观事件来浪费时间~) 

      + 比较懊恼没有早点入场 AI Infra? -- 可以另一个文章在单独分析。我觉得很多综合因素把，归根结底没缘分。 当年CISL 面试挂了。 有些决定也不见得那么挫，当时哪知道 PT会崛起呀（后来看了 Chris L的分析才知道的，赞他）。也不能忘了某些事情导致决策会偏保守~.  或许有一个可以汲取的教训就是还是要多看看大牛的talk? 有些会有insight的~ 

建议: 战略层面其实做的挺好的。 因为注意其实(1)和(2)的平衡做的不差，千万不要忘了一些客观因素 对(2)其实有很大影响。在给定条件下做的已经很好了（毕竟影响战术层面执行 -- 一开始受限以及跳出来之后偏保守）  :).  主要还是因为 (3). 策略是独善其身，不要管这些 :). 把(2)的最后一步做好~ . 学到的一个事情是: 以后做战略选择的时候也要考虑 (3) . 不然空把 (1)和(2)的平衡做的其实不错了最后还是不开心. 

总之，记住其实你做的很好。某些客观事情的影响对战术执行层的影响毕竟不能简单的抹去（lifetime的大事情呵，怎么可能不影响 :) ). 在评估你自己的执行的时候千万不能忘了这个因素。 以及注意你是在平衡 (1)/(2)而不是单纯的优化 (2). 按照上面的评估，其实做的非常不错了 :) . 导致失衡感是因为 (3) . 短期想办法独善其身把。长期的话确实做战略选择的时候要考虑(3). 

不过有时候也没办法。 能够兼顾(1)/(2)的地方令人遗憾的很有��能也是一个兵家必争之地，所以(3)比较混乱。。。 :).... 嗯～ 只能说考虑到这一点，尽量避免吧~

[superguguji]

Research

不同人说Research的时候，肯定指的是不一样的东西

- 有些人是指搞 Pig/Spark 这样有新的思路，但是不一定工程上正确的东西 （做着玩~ )

- 有些人是指高一些新东西出来，即使不真的知道原因

- 有些人则会更加看重insight. 和真正理解透 :) (其实确实和有一种类型的工程的区别已经开始不大了.. :) ) 

[superguguji]

反内卷

反内卷的最基本的奥义在于不要去扎堆做最热门/最有意思/最有钱的方向。

- 这些问题吸引了最多的人去做，因而必定内卷

- 除非你特别皮糙肉厚(能卷赢)或者特别聪明。。。否则扎堆做毛呢...

        * 参考E公司的H组.. :) 在那儿做就是避免不了内卷的命运。

- 不要主动去做的意思是，如果happen做好了，那也不要太担心。

- 你可以当最早去做的那批人，但是等到grow了，就可以跑路了 ... :) 

[superguguji]

更多随感

我们都看到说，科技发展已经到了一个瓶颈期。短期内难以有巨大突破。

在某种程度上，是因为大家过去主要以专业化的突破为主，专攻某些方向。

那么到了一定的程度，就难以融会贯通和有big picture 了。

这时候发展会慢下来，然后人们可以开始对已存在的工作做总结。

类似于把书读薄的过程。

这个阶段，其实我们没有发明什么新东西。但是我们简化了已知的东西，将它的奥义更好的展现出来，以为以后的人们作进一步的突破打下基础。

在这个意义下，寻找良好的抽象和��洁的code “当然” 有其意义. 

当然，从企业的角度来说，更关注于赶紧往前推。

那么需要寻找平衡点

- 再推的同时顺便小心的思考 :) 重写已有的技术 （类似于重写教科书）

- G家那样的公司, refactor算大project~ 不过据说已经都是政治了 >.< 

- 以创新为名作总结；其实是在revisit + 一些总结~ 参考我之前的一些R工作 :P 

[superguguji]

https://www.pathofexile.com/forum/view-thread/2466756/ . tree: http://poeurl.com/ckWj

https://www.pathofexile.com/forum/view-thread/2473036 . tree: https://www.pathofexile.com/build/n5mjse

some insights about equip

https://www.pathofexile.com/forum/view-thread/2502611 . passive tree reasonable. 4 cheap unique also good. also have guide about flasks

passive tree: http://poeurl.com/cnIe

gears: 

------------------------------------

https://www.pathofexile.com/forum/view-thread/2458430 . passive tree looks reasonable.  but less relevant

Konsta's build. Looks cheaper :D

https://www.pathofexile.com/forum/view-thread/2452117

[superguguji]

[superguguji]

迷茫

一片混乱

不知道该咋办...

--------------------------------------------

乱糟糟

或许这一切都没法避免

--------------------------------------------

hmm~

召唤先知之P~

--------------------------------------------

战略性撤退？前进？混着？ 

honestly, i don’t know....

或许选择体制内，选择精致的利己主义者；可能是一个更好的选择呢~

但好像现在太迟了？

我不知道....

--------------------------------------------

一切似乎都只是因为某个东西断了而起~

无力感，混乱和孤独感~

也真是很黑色幽默呢...

--------------------------------------------

无常

[superguguji]

Hack:

- 未必最先进

- 原型开发

-bottom up

- 将一些东西拼在一起？

Engineering:

- 将现有的做到最先进

- 产品可用

- top down

- 规划，慢速开发进度

Research:

- 突破现有最先进

- 原型开发

- bottom up

[superguguji]

系统应当有良好设计的边界和抽象

应当仅在如下情况混淆系统的边界

      - 问题确实太难 :P ，或者效率. 应当进行明确的讨论来决定这一tradeoff.

      - hack做原型的时候

hack应当仅限于

     - 一种精神 (bottom up), 承担风险，快速原型开发

     - 作为原型开发的测试

Hack in Infra并非不可行. P就是一个典型的 bottom up的, 起于hackthon的system. 

但是需要有long term的 vision和direction. 而不应作为不想好好设计系统 xjb搞得借口 

或者，as team scale up, hack本身就难以持久  :D

[superguguji]

Lifespan阅读笔记

所以schedule完了之后，`lifespanScheduler::onLifespanFinished` 是作为 一个 listener注册给 stageExecution的。然后StageExeuction会知道哪些lifespan finish了。然后finish了之后再通知 lifespan scheduler (through onLifespanFinished)

有东西完成之后就可以 reset newDriverGroupReady.set(null), 告诉大家我又可以schedule 新的 driver group 了...(其实就是可以schedule新的lifespan了 )?

------------------------------

之所以这样做是因为scheduler是single threaded (???)

[superguguji]

LifespanScheduler & SourceScheduler

在 FixedSourcePartitionedScheduler 中， 假设有三个 source scheduler S1 -> S2 -> S3 那么, S1的lifespan 在constructor 中schedule 一些，接下来由 LifespanScheduler 负责

S2, S3的lifespan则是由 FixedSourcePartitionedScheduler::schedule 来负责 。 看上家finish的lifespan来 schedule自己的...