Generally speaking, Idea will fix merge conflict by offering a visual window which shows the differences between two files for user, who can then resolve conflicts easily. However, there could be exceptions. In this situation，we have to follow git instructions. Git is so smart, it offers lots of tips for us to deal with every […]
大数据平台，有一类需求，需要验证sql的正确性。你能想到几种方式？ 1、单纯的用antlr生成AST是否足够？答案是对于和hive表相关的验证是否定的。就像spark sql的执行过程，逻辑执行计划 到 物理执行计划，需要结合source schema添加列信息。所以直接用工具生成AST还不够。 2、使用hiveserver2 执行一段sql？举例验证concat(field, field1) as new_field这个sql是否正确。可以生成一个sql=’select ${to_verify_pattern} from hive_table limit 0’。这种方式部分可行，由于没有发生agg聚合，hiveserver不需要生成mr任务，直接拿一个新的分区获取数据即可。但如果是要验证数据模型是否正确，例如有相关的join操作，则这种方式会生成mr任务。hiveserver2对mr也快废弃了，可以替换成tez会快一些。更快的方式？在sql前加个explain，使用explain的方式一起把语法和schema都检查了，还不用生成实际执行任务。 3、使用spark?向“在线spark常驻进程”发送sql，对方将执行结果写到redis，客户端从redis获取结果集。主要的优势是常驻进程内存迭代，运算快也没有mr的启动时间。但也有劣势，from xxx表之后如果没有where partition限定条件，spark没法像hive那样决定读哪些文件即可，所以它会把全量文件都读取进来，再做数据过滤或运算，所以不一定会更快，看自己的场景需求。 关于spark sql的谓词下推、列裁剪等，详见：https://www.hnbian.cn/posts/7049ff8.html ColumnPruning 列裁剪可以把那些查询不需要的字段过滤掉，使得扫描的数据量减少。 PushDownPredicate 将 Filter 算子直接下推到 Join 之前。 扩展：trino的pushdown https://trino.io/docs/current/optimizer/pushdown.html
deep learning course @ stanford: https://www.youtube.com/watch?v=PySo_6S4ZAg ml course by Andrew Ng: https://www.youtube.com/watch?v=PySo_6S4ZAg Both are for free, just enjoy it and take your time…
做YARN做了N年了，也想着存算分离吧？关于HDFS的存储有联邦存储和异构存储策略等内容，存算分离又算一个。存算分离，活生生的例子是KAFKA与PULSA的变化。KAFKA历史悠久，体量大的公司要替换很难，另辟蹊径的是，使用不同服务使其兼容kafka的rpc协议。协议一直是这个问题的根源，要实现存算分离，就要实现相应服务的协议，S3由于体量巨大，一直都是协议标准之一，所以首当其冲。 数据湖，一般结合现有的object store服务，提供基础的存储服务。同理，对于CK等服务，在OSS上实现相应的协议GATEWAY即可替换CK的本地存储，如MINIO。 存算分离有没有性能问题？一方面比较考验的是网络IO，所以局域网需要有理想的网络环境，例如50GB以上带宽。另一方面性能很受本地服务的缓存机制的影响，是否每次请求都重新从OSS拉取一遍数据。对于数据服务类的情况。例如一次查询10GB级的大表，网络不好的话，带宽占用、网络抖动等问题就会出现，所以本地磁盘优先原则依然是适用。 存储操作本质上可以分为两大类：一个operation就是一个对象全量的操作，类似对象存储的put。另一个是append log，不断追加：可以像kafka一样append本地log，也可以用bookeeper做分布式log。 后续一起看看存储相关的底层原理：TODO
午间休息，看了google面试官对一个Facebook工程师的面试，处理一个字符串是否包含特定子串的问题。 视频见 https://www.youtube.com/watch?v=PIeiiceWe_w 过程 面试者来自facebook，小年轻。面试官是精神抖擞的大嘴哥。面试者实时在google doc上表达对题目的理解，伪代码，编码。给出解决方案，给出一个是最简单的方案，另一个是aho算法，做出了对比。所以表达清楚一个方案，要多给1个方案，没有对比，哪有更深的印象？ 面试者用手写图例的方式，表达了aho算法，连初次认识这个算法的我都能略知一二，所以表达的方式很重要，要借助工具。 之后再完全手写代码，不借助ide，老外都这么牛的吗？ 最后再对整个过程做时间复杂度和空间复杂度的分析。 整个过程面试者的精神状态由理解，慢慢到他自己说的comfortable。所以往往随着问题的深入，你的体验不是更害怕，而是更释然、轻松。 后续 Follow到这个工程师的github账号 https://github.com/SecondThread 与 twiter，以及个人网站。 外国人的个人站点很酷，是自己做的一些网页游戏，和国人不同，国人写文章托管要考虑平台seo，自建站考虑自己做seo，出发点不同。Not just for fun. 浏览他的twitter，发现平时有在做codeforces竞赛。这个平台比国内的leetcode，会更纯粹一些。 几个体会 编程要成为兴趣，兴趣才能成为动力，才会做更有意思的事情，你根本不用担心35岁。 顶级公司的面试更注重实操，考察算法与硬编码等基本功，过程中也体现了知识储备和逻辑思维。 个人站点对国内而言，大多是博客。但国外很有趣，是拿来做交流，不限于博客，for fun。
consensus协议，有paxos、raft、pacificA，应用最普遍的有paxos。由于paxos难以理解、实现困难，例如日志空洞（leader宕机时，当前leader在上一任leader的任期内可能错过了一些日志的同步, 而这些日志在其他机器上形成多了多数派. 由于logID连续递增, 被错过的日志就成了连续logID连续递增序列中的”空洞”, 需要通过重确认来补全这些”空洞”位置的日志。）的处理等非常复杂，诞生了raft，逐渐替代paxos普遍应用到分布式系统中，例如mongodb、kafka等。 raft 一致性协议，一般是基于replicated state machine，基于这个理论：所有节点处理相同顺序相同内容的指令，结果就会一致。一般是以log的方式实现，将client请求append到log中，并同步给各节点，对raft而言做了简化，只有leader才执行读写，日志只会从leader流向follower，follower只参与选主，平时只做replicate。 consensus解决的实际上是3个问题：选主、log复制、safety(never returning an incorrect result) under all non-Byzantine conditions, including network delays, partitions, and packet loss, duplication, and reordering.)。 client请求只要大多数执行成功即返回成功。只要the majority of servers are operational and can communicate with each other and with clients，这个分布式系统就是稳定的。 Raft只有两类rpc，选举与append log，并约定一定的规则。见如下两图：注意约定的规则，在图中也有说明。 以下是选主rpc 以下是append log rpc 以下是各节点选主状态转换图 初始时，大家都是follower。leader通过定期heartbeat告诉follower自己是主。如果heartbeat间隔大于elect timeout，follower认为没有leader，就会发起选主。 任期term随时间递增，发起elect，会生成新的term，发给rpc给其他所有server，变成candidate. 万一同时有多个candidate多个term怎么办？重试 + […]
