cjuexuan
您能否抽时间讲一下这三个之间的关系，从doc上看貌似只是说window duration和sliding duration都应该设为batch duration的倍数，而job的submit到底是参照的batch duration还是sliding duration，请您为我解惑
# spark metadata cache ## 背景 最近一直忙着搞apm，也没时间写博客，眼看5月已经过半了，赶紧写一篇压压惊，先描述下背景： 我们将sparkSession封装在actor中，每个actor都有自己独占的sparkSession，有些sql是保存数据到hive和hdfs上，但由于是一个多线程模型，如果不加任何干预的情况下，actor1跑出来的数据通过actor2读的时候会抛出以下异常: ```log It is possible the underlying files have been updated. You can explicitly invalidate the cache in Spark by running 'REFRESH TABLE...
2021年度总结
2021年即将结束，惯例整理下一年的总结，由于最近写过一篇工作思考，今年的总结里我就花更多的时间聊下生活的事情吧 ## 工作 今年的工作其实变化很大，首先，这么些年我一直在做计算平台相关的事情，今年在一个机缘巧合之下，我换了一个团队，转岗到集群架构 团队，负责更底层的基础设施建设了，跳出了舒适区之后，迎来了更多的挑战，有段时间压力非常的大，下半年整体故障率也偏高， 明年还有大量的优化空间，另外大数据的机器成本也已经很高了，明年需要花时间将整体的成本降下去，这一块其实还是有很大空间的 需要的就是我们有把事情做极致的信念，有终局意识。未来的一两年，我希望能提高下自己的大局观。 还有个蛮有意思的事情，下半年我做了一次贝尔宾测试，我的自我认知和他人评价都都显示我是一个鞭策者和协调者，按照HR的说法 鞭策者这种性格在技术团队也不是特别多，确实，我是一个胜负心很强的人，强于推动事情，做事情也比较结果导向，他评中靠前的词是 办事高效、从容自信、视野开阔、善于分析和争强好胜，第一个负向的词是争锋相对和强势独断。从测试结果来看，我自我认知和他人认知还是基本一致的， 不过我确实需要在工作中更好的控制自己的情绪。转眼也马上要28周岁了，已经不是刚毕业的小鲜肉了，我也需要好好思考下自己未来的职业规划。 今年也是特殊的一年，在喜马拉雅六年来，我的团队第一次有小伙伴离开，这一天还是终于来了，五味杂陈。 ## 生活 今年生活上经历的事情也非常的多，我用一个时间轴回忆一下 2021年2月 因为疫情，今年春节我和罗老师选择留在上海过年，既没有回南京也没回陕西，第一次和罗老师两个人过年 2021年2月 我做了一个很大的决定，决定在上海落户买房，所以第一时间将南京的房子挂上了中介，当然，又是我爸帮跑前跑后了 整个卖房我都没太参与，都是我爸帮我去处理的，非常感谢我爸爸的付出。房子的事情多说一嘴，买了空关五年多，一天都没住过，六年前来上海的时候怎么也没想到有这么一天，但是也没太多值得后悔的，经历过才是最好的 2021年3月 5年来第一次搬离张江IT新手村，我们租到了更靠市区的地方，我也第一次开始了地铁上班，感谢罗老师这些年的牺牲。 其实我是一个非常怕麻烦的人，包括搬家，但是最后发现只要下决心做某件事后，也就按部就班做就好了 2021年4月 我们选择去丽江去拍婚纱照，为了拍婚纱照我有快半年没剪寸头，不得不说云南的天真蓝，景真好，我拍完婚纱照刚回来的那几天，领导说我心态放开了很多，哈哈 2021年5月 我和罗老师找了个周末跑去苏州的虎丘婚纱城，挑选了婚纱、礼服，为接下来的婚礼准备着 2021年6月 不得不说，deadline才是生产力，我们在陕西出阁宴一个月前还没完成视频素材剪辑和演讲稿的准备，哈哈，最后视频的完成度还是蛮好的 2021年7月...
# 背景 最近在忙着升级spark3，我们自己改的代码基本都已经搞定了，但是外部数据源es还有些问题，这篇文章主要说一下存在的问题和如何修复 # 现象 我们升级spark3之后，集成测试有些索引是能正常工作的，有些索引却不能读取了，主要的异常信息如下： ```log scala.None$ is not a valid external type for schema of string at org.apache.spark.sql.catalyst.expressions.GeneratedClass$SpecificUnsafeProjection.StaticInvoke_3$(Unknown Source) at org.apache.spark.sql.catalyst.expressions.GeneratedClass$SpecificUnsafeProjection.writeFields_0_2$(Unknown Source) at org.apache.spark.sql.catalyst.expressions.GeneratedClass$SpecificUnsafeProjection.apply(Unknown Source) at org.apache.spark.sql.catalyst.encoders.ExpressionEncoder$Serializer.apply(ExpressionEncoder.scala:211) ......
很久没有写东西了，先介绍下最近的工作变化吧，大概是今年7月份的时候，我从计算平台组转岗到了集群架构组，现在在负责大数据集群架构这一块的工作。实话说，从一个熟悉的领域切换到相对远离很久的领域，对我来说也是一次非常大的挑战，到目前为止，主观感觉是勉强跟上了节奏，未来可以做的事情仍然非常的多。 我们组主要负责大数据基础环境的稳定性，容量规划和存储治理、大数据监控告警的建设等，比如hdfs的数据清理、机器的扩容规划、yarn的资源分配等，顺便打个广告，目前还有部分hc，欢迎有兴趣的小伙伴和我联系。从我的角度去看，我们集群架构的工作目前还不够聚焦和高效，这也是我未来的一段时间需要努力改进的地方。 接下来我想要说的是大数据集群架构最近的一些思考 * 降低存储成本： * 目前我们将hdfs集群已经升级到Hadoop3，但是纠删码基本没用起来，这一块是未来节省成本很重要的一个增长点 * 我们今年尝试了做混合云存储，来解决机房扩容的问题，具体来说，按照hive表的访问场景，将n天前的冷数据周期性同步到云对象存储上，并且可以选择云上的低频或者归档存储，由于大的云厂商的对象存储基本都实现了FileSystem的接口，这一块完全可以做到透明对业务无感知，在有一定商务折扣的情况下，云存储的成本可以拉到低于机房3副本存储的水平，总体还是比较划算的 * 利用之前的小文件、冷数据分析等产品，进一步识别冷数据，再进一步挖掘任务血缘，清晰的标识每个数据的产生代价和是否可以重跑恢复等，精细化对存储进行生命周期管理 * 提高稳定性： * 稳定性是一个对于架构来说没有穷尽的问题，今年做SLA任务链路传递等功能，但是现阶段还是以报警为主，因为本身集群不具备更多的资源储备，所以在出现延迟的时候很难有资源来额外保障这些任务，但是今年Q3也和云厂商尝试了混合云的计算架构，具体来说我们会在云厂商那边托管一个最低保障的EMR集群，云上计算集群和自建IDC之间通过专线联通，未来我们将在应急和基于每天的计算潮汐现象使用这部分弹性的计算资源，来解决我们计算集群扩容的问题，结合上面的冷数据上云，我们未来的架构是IDC中有常规的计算资源和热的数据，云上有分时、应急使用的EMR和冷数据 * 对于一个组件，我们通常会收集很多的metrics，硬件层面的的、软件层面的，这么多眼花缭乱的指标可能在某些具体的场景是游有用的，但是对稳定性和告警来说，我们还是需要精简和构建最能反应问题的北极星指标，这一块我希望自己能在未来的一年内通过更多的思考将指标细分，对于重点指标加强监控告警，对于一般指标只做看板展示，不去做太多告警，告警的精简也是为了让我们更能抓住问题 * 减少人的投入： * 现阶段大数据集群维护很多场景下还是手动挡，吃专家知识，但是这不是终局，我理解的终局一定是需要系统去承接和沉淀更多的场景化的经验，我们可以找到的一个衡量的点是人在事情中投入的比重 * 如果让工程师持续做那些枯燥而又重复的事情，本身就是对劳动力的亵渎，我们要通过技术手段去努力降低人在系统运维中做枯燥事情的比例 从当前大环境来看，目前云厂商已经非常成熟了，如何用好云服务来降低人力、机器成本，也是我们需要长期考虑的一个方向，这一块有兴趣的小伙伴也可以一起聊一聊
## 背景 最近遇到一个内存泄漏的case，这里分享下，这是一个老业务，最近代码没改，只是增加了对一个稍大的hbase集群的监控（大概4w个region，之前已经接过另一个小的hbase集群，跑了很久也没问题），在我们上线之后很快运维就找到我们，说我们这台机器用到了swap分区了，首先我们的Xmx是4G，没有oom，但是系统的res显示用到了50多g ## 实验 首先没oom的话，应该不是堆内存和direct buffer的泄漏，让运维dump了下，dump下的heap文件很小，不到1G，又打了个jstack，线程数也是比较正常的，那么应该是native的内存泄漏，这下就比较难排查了，网上google了下相关工具，google出的gperftools还可以，于是配置了下，然后打了个heap看了下,按照占比sort下 ```shell 0.0 0.0% 100.0% 5729.3 97.5% 0x00007fc84acf7fe5 0.0 0.0% 100.0% 5732.5 97.5% Hashtable::new_entry 0.0 0.0% 100.0% 5729.3 97.5% JVM_InternString 0.0 0.0% 100.0% 5729.6...
# 起因 转眼间在我司呆了快4年了，从最开始做XQL（数据计算平台），到后来做Spoor（监控系统），到现在在数据平台这一块做XQL，Panda（调度系统），Unicorn(数据可视化)等，最近到年底了总要总结总结这些年做过的XX系统，所以就有了这篇文章，今天这篇就讲一下XQL和Spoor的一些实践，后续有时间再把Panda和Unicorn的一些实践经验也整理下。 # XQL的一些实践经验 XQL 是我司内部使用多年的数据计算平台，每天产生上亿的Spark task和PB级别的数据读取，任务数占到整个公司数据计算任务的70%。 16年做XQL的时候是从0到1的过程，XQL对外交互并不复杂，对用户的核心功能就是用户提交SQL，我给他跑出来，对于SDK来说也是做了大量的封装，所以我们可以很容易的重构而不用担心对用户产生影响，从UI交互来说呢，XQL是我做的这些系统里最简单的，从开始的只有黑框提交，到后续支持本地浏览器的多窗口，再到后来支持多workspace和tab，风格都一直没产生什么变化。 这个系统的重心是和用户诉求直接相关的， 对于用户来说，希望的是我们性能足够好，尽快的跑完，这里提取成目标就是性能要好，性能要好最简单的方式可能就是设计成一个可横向扩展的架构，然后不满足需求的时候就加点机器呗，但是机器都是要钱的，按照我们dalao精益求精的心态（还是qiong），希望我们尽可能的优化引擎的性能。 所以我们在这里就主要走了两条路，一条路是优化，优化的难度其实是比较高的，所以我们也只能是把一些比较关键的问题通过修改开源系统的源代码的方式去优化掉，另一条路就是治理了，在这一块上我们花了更多精力，因为这一块的出效果会比较快，我们对整个流量做了细粒度的拆分，然后做了一套比较复杂的路由算法来满足用户的诉求，我们也通过大量的监控数据来找到我们系统的流量高峰和低谷，做了一些弹性扩容，这样可以保证我们峰值的一个系统健康度，并且在流量低谷将机器释放出来做其他事情。另外林子大了，我们人力也有有限，所以这个时候就要上一些规则来限制用户的不合理使用，比如用户可能处于有意或者无意会跑一些大的sql，但是你不能一刀切的说完全不能跑，毕竟中台还是服务于业务的，这种情况下有几种可能： 1. 你让他跑，但很浪费资源 2. 你不让他跑，影响了小伙伴的工作 这个问题就变得棘手了，不过好在有成熟的其他业务模型我可以直接拿来用，比如积分体系，在我们日常用的app有些是把他的权益和他的积分进行了关联的，比如同样一件事情积分高的人可以做但积分底的人就不能做，做事情可能会扣掉用户的积分。于是我们做了一个积分体系，当用户跑了一些我们认为比较浪费的sql的时候会对他进行一些扣分，如果分不够了就只能让他的领导进行审批了，另外我们也有每个部门的资源消耗来和部门进行虚拟结算，这样可以宏观的解决掉用户的一些问题 总结下： 1. 优化，对核心的一些路径进行优化 2. 细化： 对流量进行场景拆分和隔离，细化资源使用 3. 生态化： 利用一些成熟的业务模型，比如积分等进一步加强对用户的管理，提高整体的资源使用率，驱使用户提高计算的ROI 我们在做中台类系统的时候上线不代表结束，那只是刚刚开始，后续要用产品思维、运营思维、数据思维来治理好整个生态，这样才能让大家用的开心。这些年也见过一些系统他们的开发者在上线之后一直停留着堆积功能的情况，对用户的真正诉求没有很好的挖掘，最终做出来的效果当然也很难令人满意了 # Spoor的一些实践经验 Spoor目前是一个通用的监控系统，目前的量级大概是每天百亿级别的metric事件。...
# 2020年年度总结 魔幻的2020年就要结束了，按照惯例，总结和复盘下一些事情吧 # 工作 ## 事情 先说一些开心的事情吧，从系统可用性的角度来说，今年对几个核心系统的去单点改造基本都做完了，包括一些中控节点的去单点改造 另外整个团队做了几个比较有意思的工作，第一个是spark写hive/hdfs时智能的小文件合并，之前我们是在XQL中暴露需要被coalesce或者 repartition参数，但是这样做有一些弊端，首先无法适应数据的变化规律，一个上线时候合理的repartition值跑着跑着就不合理了， 另外就是没有经验的小伙伴拍脑袋拍出一个值也比较费力，所以今年我们做了个智能合并小文件的机制，合并小文件这件事情平台会自动在用户的 任务逻辑后面加一些spark task去做，对用户透明了，从机制来说更友好了，收益也不错 另一个事情就是tuning工具，tuning工具是给spark任务推荐参数的一个工具，比如driver配多大，executor配多大，core配多少，instance配多少， 并且我们将tuning和我们panda调度集成整合了，在用户任务跑完之后会panda会调用tuning，来动态调整参数， 从本质来说，tuning和小文件合并是解决同一类问题，那就是让1. 没有调优经验的人能用工具调优，2. 让任务能适配数据的变化，避免出现上线的时候配的很合理 随着数据变化变得不合理的情况。tuning其实用的数据主要就是spark的event log，外加spoor采集的一些性能数据，然后根据用户的任务并行度，资源消耗，算到一个 更合理的值，有了tuning之后，我们很快会把用户的配置收敛到更合理，当然，因为这是一个事后机制，无法处理每天数据波动非常大的情况，但能解决绝大数数据缓慢增长的情况 为了避免tuning影响用户的任务，panda还配合上线了一个沙箱的功能，当被tuning修改配置后跑出问题时，我们会回滚到上一次的成功运行的配置，来减少对业务的影响 第三个事情，是我们在做一些数据价值的评估分析，其实我们也花了很大的精力在做，目前总结就是尚有问题，未来可期，这里就不展开太多了，明年应该会重点发力一下。 ## 团队 今年团队在轮值做的还不错，基本都做到了双人轮值，私聊找我问问题的同学越来越少了，基本都通过值日的小伙伴处理了 code review做的也不错，merge request绝大多数都能做到至少两人review，并且也有很多讨论。 今年在设计评审上花的时间也比往年多，很多问题在评审阶段暴露了，大的返工比往年是要少的。...
# 引子 最近疫情严重，大家千万注意安全，保护好自己。这段时间我一直在陕西，刚好有大段的时间可以用来研究一些业务上的概念，这里整理下最近一些数据业务上的思考，欢迎大家探讨交流。 # 数据的价值 我理解的数据的价值体现就是支撑业务，帮助业务人员做好决策，辅助业务人员做好产品。而计算、调度和可视化这些都只是手段和过程，不注重过程的结果是低效的，甚至是错误的，反之亦然，只注重自己手头的事情也会限制我们的发展，让我们缺乏大局观，缺乏认识到业务的痛点，当然也很难和业务共赢了。有几个现象都反应这种亚健康状态：业务部门关键时候想要数据，但是数据迟迟不能给到，究其原因，数据的采集甚至都没做好。另一种现象是数据部门制定一大堆红线，业务部门叫苦不迭，甚至向上级投诉数据部门制约了业务发展。这都是反面的教材，那我们今天就梳理下如何才能萃取数据的最大价值，让数据成熟度不断提高 # 数据成熟度和职责分工 今天我会介绍四种角色：业务人员、数据分析师、数仓开发、数据平台工程师，其中重点是前面三者，我自己的身份是平台工程师，这一块我会单独提一下 首先，巧妇难为无米之炊，一个新的业务线（这里把不在既有数仓体系中的业务线就叫做新的业务线）要有数据的第一步就是做好数据的采集，有了正确的数据才能有后面的故事，这个阶段就是采集期，在这个阶段，业务人员需要做的事情就是接入埋点体系，将事件落盘，为后续的分析做好准备工作。一些成熟的公司会有无代码埋点或者叫可视化埋点。，接入之后配套的可视化分析系统能支撑这个新晋业务查看一些通用的基础的指标，比如事件分析、留存分析等，另外也能在这个阶段解决比如公司oneID这种大的数据战略。这个阶段是对于单个产品来说是快速试错的阶段，所以分析师和数仓并不需要过早的介入进去，跑一跑还能活下来的产品才能进入下一阶段。当然借助公司的一些技术体系，如数据计算平台、数据可视化平台等，开发和产品也能自己做一些简单的数据分析。 如果你度过了采集期，说明这个业务模式还是比较成功的，那么恭喜你，你即将进入成长期。在这一阶段，需要多方协同配合。首先，作为最理解业务的业务方，需要给分析师和数仓介绍业务背景和一些宏观的目标。这里强调一点，分析师不是取数工具，取数可以用更低成本的方式去做，我理解分析师的主要职责还是发现问题，挖掘指标，提供决策建议，所以这一阶段业务不要直接陷入到我需要分析师给我拉一个非常具象的指标。分析师需要根据聆听的背景知识和宏观目标，做好业务的数据域划分，整理好需要的指标，另外和业务沟通好一些统计的口径。接下来是数仓，数仓根据分析师的需求，同时和业务沟通好一些数据获取途径，整理好数据模型，准备好etl任务，把分层数仓搭建好。当数仓的etl任务有条不紊的运行起来时，就到了这一阶段享用劳动果实的时候了，此时分析师可以大展身手，给业务输出一些有挖掘意义的看板，有针对性的一些分析报告了。同时，一些统计的任务也可以直接由数仓提供给业务，供业务在C端使用（如榜单类的指标）。 如果你的业务还活着，这个时候就进入了成熟期。首先在这个时候你的数仓是基本成体系了，该有的数据都有，另外在采集期和成长期也积累了很多有意义的数据资产，如一些分析报告和数据看板。这个阶段业务最需要的就是跑的更快一点，跑的更稳一点，对于快和稳都需要强力的数据支撑，证明你没有走弯路，指导你完成一些弯道超车，此时可能推荐系统、画像系统等个性化系统准备进场。随着前期的磨合，大家有着一致的业务目标，跨部门的协作在这一阶段也应该变得非常融洽了，这里业务需要做的就是利用好数据运营好产品，分析师需要做的是搭建明确的metrics体系，帮助业务发现问题，并且及时给出建议，而数仓需要做的是协同分析师和业务，维护好任务脚本，并且以开放的心态迎接变化。这一阶段的果实就是最终的业务产出了。 我们用表格的方式整理下： |阶段|业务|分析师|数仓|产出| |---|---|---|---|---| |采集期|埋点、采集数据|||落盘的事件日志、配套的简单分析工具输出看板| |成长期|介绍业务背景和宏观目标|划分数据域、整理统计指标、沟通统计口径、制作定制化看板、输出简单分析报告|数仓建模、开发ETL脚本，搭建分层数仓|分层数仓搭建完成，定制化看板，c端数据输出| |成熟期|基于数据做好运营|搭建明确的metrics体系，发现业务问题，给出建议|维护脚本，开放的心态面对变化|业务最终产出| ## 岁月静好，背后的人 从一个旁观者的视角，我描述了我的合作伙伴们在业务的各个阶段需要做些什么，并且能收获什么，那么作为在背后支持他们的数据平台开发，我们做了些什么。在采集期，我们的可视化埋点和分析系统简化了业务接入数仓的流程，并且能给到一些固定的数据分析工具，同时我们的数据计算平台能支撑业务做一些简单的数据校验和数据分析。在成长期，元数据系统可以帮助数据人员加快数据指标定义，任务调度系统全力保障着etl任务的运行，可视化平台帮助分析师快速搭建定制化看板。在业务的成熟期，画像系统、推荐系统等个性化系统的介入，进一步加速了业务的发展。对于我们来说，理解好业务人员的痛点可以帮助我们迭代数据产品，不然你做了一个yy出来的工具，很难获得用户的真正认同。治理好用户，让真正的用户享受最好的服务，而不是纯粹搞一大堆红线规则，限制用户的使用，而我们的用户，就是上面那一群人：）
聊一聊晋升答辩
# 引子 今年自己做了一次职级述职答辩，并且帮超过5位同学review过他们的述职ppt，这里稍微总结一下我在答辩中的收获，以及做答辩的一些技巧和注意的点 ## 收获 首先这是一次很好的时间节点，准备材料的过程中，我静下来思考自己最近一年的成长，工作中的亮点，以及接下来急需补强的点。 同时，这也是一次能展现自我能力的机会，因为我当时是一次公司大老板作为评委的答辩，有一次能和高层交流的机会，当我按照自己的节奏顺利的做完答辩，我感觉变得更自信了，同时老板提的一些问题也可以更好的指导我们接下来的工作。 另外通过职级答辩，我更明确了下一个职级的要求，以及公司对人的要求，这让我的方向感更加明确。 ## 可能遇到的问题 这里总结下我发现的一些容易出现的问题： 1. 分不清职级答辩和OKR review的区别，这种通常是一些小组长会犯的， 如果是OKR review，更多展示的是团队的成果，但是职级答辩的时候，更多强调的是人的作用，也就是你的作用，你在这些项目的过程中扮演了什么角色，怎么帮助你们小组拿到了更好的成绩 2. 技术细节太多了，甚至没有关注做事情真正的价值和赋能，同时为了讲一些旁枝末节的点，花费了大量的篇幅。我觉得首先要有价值意识，才更容易做正确的事情，不至于偏离方向，在这种场合，别人不是做你这个系统的，也没有那么多背景知识，怎么用有限的时间让大家感知到你的努力和付出，我的建议是需要讲清楚这件事情的价值。 3. 关键指标没有给出或者给的不好，给出的一些佐证成绩的指标经不起推敲，我们强调指标，但也绝不是随便找一些数字放到PPT中就OK了。你选什么指标，也间接反应了你看重什么东西，反应出你看问题的层次，所以一定要慎重的去梳理你的指标，这件事情其实应该是平时做的，到这个场合直接拿来用就可以了。 4. 选取的案例过于重复，体现不出来案例的差异性，也展现不出来能力的全面性，只能看出熟练度。另外案例中没能很好的区分什么是问题，什么是挑战 ## 技巧 这里说一下我的一些技巧，其实和做分享的技巧如出一辙，一些经常做分享的小伙伴这种场合就占优了 1. 做好时间控制，控制时间是对评委的尊重，也是你平时工作中的一个重要技能。这种场合通常有一些时间提醒，比如最后5分钟提醒，我们就应该用好这些时间节点，用来控制自己的节奏。大家可以先录着听一遍，然后记住你10分钟应该讲到哪里，最后5分钟应该讲到哪里，然后按照现场的提示调整自己的速度，当然，这同时需要我们的PPT足够精炼，不然到时候最后5分钟还有10页没讲完，你疯狂加速也没有用了 2. 注重和评委的眼神交流，不要照着PPT念，这个场合的评委不会很多，有些眼神交流你就能知道对方对什么更感兴趣，可以多讲一些，也可以在最后提问的环节多补充一些 3....