2301_77818583的博客

原创 一线管理者不能是专业线的“逃兵”

下半场聊到了技术，就明显的“底气不足”，回答也多是侃侃而谈，经常说出“最近手生”，“大概是这样，具体不太了解”，“有些细节没注意过”，“只是听说过这个概念，具体没了解过”。而且还有一点，X1技术一般，往往对技术的关注度也少，这会给一线RD带来很不好的传导：领导不看重技术，那我也得在技术以外多发发力。画外音：有人说，X1技术不好不代表团队内没有技术好的人，我想反问一句，X1技术弱靠什么识别招揽技术好的人（靠运气吗？很常见的一种现象，X1技术一般，团队内高职级的大牛也少见，X1技术强，团队内技术强的也多。

原创 如何提高思考的效率

不妨先想想是什么阻碍了思考的效率，我认为是“无效发散”和“混乱反复”，本质上都是思维的“随机游走”

原创 数据团队如何提升影响力

原创 知其然知其所以然——浅谈数据库底层技术

姓名年龄性别身高体重张三18男18080李四20男17070以上面表格为数据表，一般来说，同一行的数据在存储介质中连续存储，称为行式存储。如图同一列的数据在存储介质中连续存储，称为列式存储。如图OLAP场景中，首先要存储大量的数据，可能是数十上百亿，其次在查询时经常从数据库中提取相当多的行，但只提取一部分列。针对OLAP的查询场景，行存储需要一行行的扫描数据，再选取需要的字段进行数据提取。

原创 技术管理者的核心能力在哪？

我的答案是如果你能做好上面几点，那么写与不写不是那么重要，如果你渐渐发现对于技术的掌控力越来越小、技术评审越来越插不上话、对于新的技术越来越不了解、每次技术沟通下属都要给你解释的越来越多，那么我建议还是保持一定的开发量和技术熟练度。技术管理者大部分是“学而优则仕”，毕竟也是从一线技术人员走过来的，过程中也积累的丰富的经验，在技术方案的选择上能够有一定指导，在工作质量要有把关，对于项目风险也要有一定预判。做不做要从两个方面来说，一个是技术上能不能做，另一个是业务上或者组织定位等非技术因素上应不应该做。

原创 多团队下SLA约定问题

比如，恰好有一天甲和乙都是正常时间产出，丙从3点30分开始启动，但是数据出现故障，延迟了55分钟，最终5点25分完成，没有打破SLA。丁由于启动晚了，正好和其他高优任务挤在一起，导致抢不到资源，比平时2小时的时间延迟了10分钟，所以是7点35分产出，正好打破了承诺的SLA。丁实际6点30分完成，对外承诺是7点30分。丁说，那我按7点30分启动算，任务需要2个小时，预留buffer一小时，可以承诺10点30完成。丙说，那我按5点30分启动算，任务需要个小时，预留buffer一小时，可以承诺7点30分完成。

原创 深入分析数据倾斜出现的原因与优化

目录数据倾斜发生时的现象数据倾斜发生的场景shuffle倾斜一、数据倾斜发生的原理二、数据倾斜的解决方案解决方案一：将reduce join转为map join解决方案二：过滤少数导致倾斜的key解决方案三：两阶段聚合（局部聚合+全局聚合）解决方案四：使用随机前缀和扩容RDD进行join输入倾斜一、数据倾斜发生的原理二、数据倾斜的解决方案膨胀倾斜一、数据倾斜发生的原理二、数据倾斜的解决方案数据倾斜发生时的现象绝大多数task执行得都非常

原创 离线计算和存储成本的基本概念和优化技巧

CU是计算单元（computer unit）的简称，离线计算1 CU=（1 vcores(虚拟cpu核心=0.64物理cpu核心)，2.25G内存）。CU是一个状态值，代表某一时刻申请或分配的资源量，对于提交到yarn上的一个任务，每分钟会做一次采样，记录采样时刻资源的使用量并用采样值代表这一分钟该任务使用的资源量。

原创 数仓设计中的存算分离

0.灵魂拷问数仓同学每天都在做表，但有没有想过一个问题，计算过程往往是不能节省的，但你是因为什么把某个计算结果落一张表，而某些计算结果不落表呢（只是中间过程），是因为“感觉应该落一张吗？1.云计算中的存算分离存算分离这个概念一开始是出自大数据和云计算，随着云原生的发展被提及的原来越多。早期在大数据和云计算环境中，存储服务和计算服务在集群中是混合部署的（存算耦合架构）。这样设计的原因也很简单，计算存储放一块可以避免很大的网络IO开销。

原创 【基本功】视图在数仓中的作用

反向依赖的存在对下游很痛，对推下游的人也很痛，所以在架构设计中的一些场景应该尽量避免。其实不使用视图也有其他的方案可以既分发又节省存储，比如表中有分发的字段，根据字段的不同值分发给不同的垂直业务，权限控制可以使用河图的行级权限管理。这种情况下使用视图，既可以完成标准化的工作，还可以很好的节省存储空间，同时也能提升任务执行的速度，是一种比较好的方法。由于base层的建模一般还是3NF建模，而业务系统一般也是标准3NF建模，很多时候base层的表只做了标准化的工作（甚至连标准化都没有）。可以应用在以下场景中。

原创 大数据的小文件优化指引

如果结果文件的平均大小小于hive.merge.mapfiles设置的值，则额外启动一轮job进行小文件的合并，合并后的期望文件大小由max(hive.merge.size.per.task, hive.merge.smallfiles.avgsize)来决定。此时也需要在结果写入到hdfs之后启动一轮额外的任务来合并小文件，方法是使用distribute by 把相同分区的数据分发到相同的task中，如果一个分区用一个task会处理较多的数据，可以把一个分区散列成多个task来处理。

原创 【基本功】hive表的分区字段设计

这种情况一般是新手可能会发生，在创建数据表的分区字段时，选择了一个可变的字段，每天这个字段的值发生变化则需要重新计算这条数据并归属新的分区。这种情况一般发生在海量数据下，一个表的分区字段可能无法把数据均匀的散列，这样会导致有的分区下数据量大，有的分区下数据量小。然而分区字段设计的不合理，也会引起一些危害，常见的危害有分区太多引起的小文件类问题和分区不合理引起的计算开销大的问题。另一方面，一个表有多个分区，可以有多个任务同时写入不同的分区，开发上可以逻辑解耦，计算上可以加速执行。

原创 SparkUI超详细解释（7）——Debug

如果想看一个任务在不同时间点占用的executor数量，应该看numExistingExecutors数量，需要注意的是executor数量并不能等同于CU的用量，一方面是一个executor可能占用更多内存换算成CU会占用更多的CU，还可能是一个executor会占用多个core（通过设置spark.executor.cores）也会占用更多的CU。为方便用户查看任务执行期间申请的Executor数量，Spark UI增加了Debug页面。

原创 SparkUI超详细解释（6）——SQL

DAG图，以图形的形式展示了整个作业的执行过程，每个色块代表了一种算子，WholeStageCodeGen是用动态代码生成的方式把几个算子转换成java函数，提升计算效率。在spark2.x可以通过coordinatorid来关联，spark3可以勾选stageid，也可用用过WholeStageCodeGen后面的数字来关联。sql页面的列表页罗列了提交到spark的所有sql，所有设置的参数，以及所有的创建临时函数的语句。1.如何从stage的DAG图关联到SQL的DAG图。有关SQL页面的自问自答。

原创 SparkUI超详细解释（5）——Executors

executors页面展示了executor和driver的一些统计信息和明细信息，汇总信息包括内存、磁盘、cpu的使用量，任务执行时间、GC时间，成功、失败、完成的task数量，以及输入输出的数据量等内容。需要注意的是，这个页面中显示的内存使用和executor状态信息都是瞬时值，任务在执行过程中会一直变化，任务执行结束内存指标都会清零。executor和driver并不是物理上的机器，而是宿主在机器上的跑在jvm上的进程，这点从address也可以看出（机器名+端口号）

原创 storage memory是什么意思，如何计算得出的

但是查看GC日志发现，oldgen的内存大小是固定的，但是eden、from和to的大小是动态变化的。storage memory，虽然名字看起来是存储内存的大小，但实际上由于spark1.6之后已经实现了统一内存管理（即执行内存和存储内存使用同一个统一内存），所以storage memory实际上是统一内存的大小，是sparkSQL中我们设置spark.executor.memory和spark.memory.fraction，在jvm中能够被用来计算和存储的内存。可以说是一点都不差！

原创 SparkUI超详细解释（4）——Environment

的参数设置，可以在该页面查看（某些参数是xt默认提交，有些是集群默认设置，有些是spark hbo的自动调整等，都会和xt模板里人工设置的参数有所不同）。”，比如参数的“=”两边有空格，都会造成设置的参数不生效），所以当实际执行结果和预期不符时在这个页面check下是有必要的。有些特殊情况要注意，比如下图在设置spark.sql.shuffle.partitions参数时不小心少打一个s变成了一个错误的不存在的参数，在Environment页面依然能够看到这个参数，但实际上参数是不生效的。

原创 SparkUI超详细解释（3）——Storage

比如我们经常写的with xxx as是把一段逻辑封装成一个虚拟表，但是真正在计算时，多次引用会多次触发这段逻辑计算，所以只是写起来精简，但执行上并没有一次运行多次复用。有时我们使用create [temporary] table来固话一段逻辑的结果也可以实现类似的效果，只不过cache table大多在内存中，访问速度会非常快，非常适合内存中的迭代计算。具体含义可以看下面的截图，大致分为内存对象、内存和磁盘、内存序列化、内存和磁盘序列化、磁盘、双副本、堆外内存。有关storage页面的自问自答。

原创 SparkUI超详细解释（2）——Stages

推测的原因是这个stage对应的是以下面的代码，上下两个shuffle的key相同又有一次union all，所以可以放在一个stage中，虽然task数量是4000，但是上面的shuffle数据是分在2000个task中，下面的是另一个2000task中，并不会两者合在一起hash到4000个task中。”下的一些指标上，也可以看到相关信息，或更具体的说明。task的时间线，以条形图+不同颜色的方式描述了各个task的不同动作下的耗时，鼠标浮动到某个条形图上，可以看到该task具体的各项时间。

原创 SparkUI超详细解释（1）——Jobs

当遇到action算子时就会划分出一个新的job，action算子常见的有reduce、collect、count等，作者并没有找到和sql关键字的对应关系，笼统的说需要落盘存储的一般都是action算子。该时间不是所有job的执行时间之和（有并行的job，job与job之间也有时间间隔），也不是最后一个job的结束时间。可以，常见的如多个表join，每读一个表可能是一个job，多个表就是多个job，可以并行执行（前提是资源足够）job的划分没有太多的意义，可以不必关注，关注stage的划分更有意义。

原创 【基本功】Spark常用参数详解

官网文档永远是最好的指导手册。

原创 【基本功】数仓为什么要分层

在此之前我们都是默认讨论进行逻辑的操作，如果对于任务2的结果进行持久化，以后基于任务2有多个下游逻辑都不用从逻辑1开始计算，一次计算多次使用，节省了计算资源。因此很自然的就会想到，把一整段逻辑拆分成多个小逻辑，并把几个相近的逻辑组合成一个任务，这样就把大任务拆分成了多个小任务。很显然，所有的目标数据集都是由最原始的数据源经过一次性的加工产生，没有中间过程，就是不分层的状态。明确职责，明确开发的先后顺序，让不同的开发人员开发思路更加统一，以便不同的人员可以更好的协作，真正出现问题也更好的定位到哪一层。