SQL BOY，自保秘籍！

导读：SQL BOY，一定要保护好自己！谁还不是个宝宝？数据开发工作碎碎念，也可以说是浅薄的经验之谈，欢迎批评指正。

F00.前言

数据开发、数据研发、数仓开发，大同小异，都是与数据打交道，具体的说都是与数仓打交道，大数据开发也是数据的存储、引擎、架构、组织与应用，今天主要是工作中一些碎碎念与大家分享。

F01.架构师思维

既然都离不开数仓，我们可重点聊几点数仓的事情。对于数仓，工程师人人都是架构师。没有架构思维，相信数仓开发也做不好。数仓开发本身就是一个思想、方法论作为基建的工作，基建不牢，地动山摇。那也只能是漂浮在半空中的开发工程师。

所以，数开（数据开发、数据研发、数仓开发，下同）首先具体的能力就是全局把控数仓建设。从数据存储、数据集成、数据开发、到数据应用；从大数据引擎、数据平台（工具链）、调度系统、到BI看板、OLAP、ad-hoc、用户画像、推荐系统；从数据探查、数据质量、数据治理、元数据管理、到数据服务、OneData、指标体系、数据内容建设。宏观的把控才不至于执行上的跑偏，更不会选择职业方向的飘忽不定。

F02.薪资待遇

从待遇上看，数开依然是roi较高的方向。这是趋势，也是时代给予我们的馈赠与福利，哪怕自动化、平台化、0代码甚嚣尘上。据读者多年工作经验观察，传统行业base 30k说明你已非常优秀，互联网行业，尤其一些大厂，45k说明你已非常优秀Plus，行业佼佼者。当然这都是说的月base薪资，如果有股票、或M岗，这个另说。

F03.数据服务意识

数据服务与内容建设。突出强调一点，数据服务意识，虽然数据服务形态有很多，BI看板、报表、OLAP、ad-hoc、临时取数、App分析、ABtest、标签服务、数据API等等，但重点主要是意识，一定要有强烈的数据质量、和数据安全意识。这是建立其他部门信任与真正实现数据价值的必要前提。

平台化、工具链也对我们提出的新挑战。提升我们跨部门协作、沟通的能力，也是对自身软能力的一种提升，可能还会反哺到我们的日常生活。这一点，存在即合理，接受就是了。还有谈一点模型优化，核心与扩展模型分离。这点很重要，可以记小本本上。

F04.数据探查/调研

数据源，主要是要熟悉客户端埋点全链路、服务端埋点探查追踪、db数据的binlog的生成解析与集成。尤其是接到一个需求或主题域模型设计之前，如何数据探查（数据调研、数据摸底），可以从以下几点展开：

• 1.量级。如果是埋点数据，这个可直接推测是否重复上报或少上报，如果是db数据，这个可有效评估数据集成是增全量的抽取策略（建议db数据统一走binlog）。

• 2.schema。字段含义、业务描述，枚举值解释，空置率、单位等。特别注意一点，json、struct等复杂数据类型的结构、key等。

• 3.主键。db数据主键一般没有问题，服务端埋点上报的数据需要格外注意。

• 4.一致性。如供给侧与消费侧的一致、B端与C端的一致。

以上都建议配置到数据治理DQC里，每天自动化监控，充分保障数据质量与及时发现问题止损、降低数据故障风险。

F05.建模理念

小插曲，工作中经常会遇到一些不顺心的事情，如与同事、leader建模理念与思想不合，也可能是企业文化不合、性格不合，这在工作中很常见也很正常，不必有心理负担。如果工作中遇到了，几种处理方式可以参考。

• 1.平心。晓之以情，动之以理。

• 2.上卷。德不配位，取而代之。

• 3.中空。心有乾坤，敷衍于事。

• 4.下沉。决不惯着，跳槽离职。

当然圈子真的很小，说不定哪一天又是同事了，最好还是要冷静处理，争取最佳方式。

F06.实时数仓

实时数仓 曾经看到一篇文章，对实时数仓的观点是“不一定会，但一定要了解“，持赞同态度。尤其大厂，会有专门的实时开发团队，会和离线开发团队分开。术业专攻，是有道理的，专业的同学做专业的事情，不然数据也不会分出这么多分支方向。如果小厂，还是要会的，也是没办法，不得不会，小厂一般要求一专多能，恨不得你啥都会，一个人就是一个团队。

点个关注，一起进步。↓