我毕业了之后是在通信公司，从一个软件工程师开始做，做一些基本的系统运维工作，熟悉整个通信行业的业务模型。
因为我们通信行业主要是移动、联通、电信，他们模型其实都是比较通用的。当时是有一家国际上大的咨询公司，统一做的一套标准的通信三户模型。然后基于这些模型，我们熟悉的一些计费系统、CRM 客户关系管理系统等日常的运维工作。
三户模型即客户、 用户和帐户，来源于etom的模型。三户模型在电信行业成为建设 运营支撑系统 普遍运用的模型，三户模型也是根据营销模型转向“以客户为中心”理念而产生的结果，客户的需求成为支撑系统信息模型不断趋于完善的主要驱动力。
后期我慢慢地转到经营分析组，主要是给集团和我们省级仓库去做一些指标数据和数据挖掘工作。从开发工程师切入，逐渐接触到的一些更深层的业务、架构、模型。这块模型不仅说是我们数据仓库模型开发这个概念，还有一些我们通信行业的特有的模型概念，更加贴业务。
慢慢我自己也做了大概有三年左右的Oracle(甲骨文公司)的DBA 。因为当时是想在这一块加强一下，当时觉得既然想从事技术，肯定要选择一个方向，那么要加强一下。我个人也比较喜欢数据库，所以当时做了3年多的专职的DBA ，主要是从事专门Oracle的日常备份恢复升级，包括各类版本的切换、日常的补丁、优化等。
DBA : 数据库管理员 （Database Administrator，简称DBA）
我觉得这个工作好像看上去可能跟我现在从事的数据仓库建模工程师好像没有那么大关系，但是我觉得它是一个很好的技术基础。因为对你后期的职业的发展方向，不仅是对于数据建模工程师，这些基础对其他的职业方向选择是一个特别棒的积累。
后期我个人从DBA出来了之后，基本上从事数据仓库建模的架构、设计的工作。因为一般在项目上，整个项目的架构还有核心的ETL流的搭配都是我来做。这些环境部署完成之后，会有其他同事接手整个项目的详细的开发工作。
ETL，是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。
因为一些工作就比较的常规了，然后我就负责整个项目的调度、进程工作。最近这几年的话基本上就是设计整个数据仓库、某一个集市的架构的设计，包括业务的设计，技术的选型、部署的方案，甚至后期的运维的一些工作。
第一，我自己是一个对工作比较有自己想法的人，我在做一件事情之前，会尽量去多看一些东西，多去想一下，我未来几年，3年或者5年左右想去往哪一个方向，在考虑这个问题的时候，我会结合目前的一些主流的技术去做一个判断。
第二，我自己擅长哪些，比较喜欢哪一个方面。我会结合这2点去挑一个或者两个方向，但不会太多，就是一到两个方向。其实我们在工作上没有那么多的时间去积累去学习，因为毕竟我们是工作嘛，不可能像学校一样去学习的，更多的时间是你在选定一个方向或者目标之后，在你的业余的时间，在你的那个方向上多做一些功课，做一些准备。这样的话你在工作上如果说有那么一个机会，你才抓得住。像我其实刚才说在工作进行转变的时候，就遇到了这样的机会。
其实机会对每个人都很公平，因为他是摆在大家面前的，不是专为我准备的，只不过机会回来了之后，刚好我觉得我可以试一下，那我就抓住这个机会，那就像我当时做DBA，其实也是我是自己学很长时间，但是确实操作经验没有那么多，那会儿也是项目上有一个这么个决策，是需要有一个人来承担这个工作。但是项目组其他的人觉得这块好像跟我们之前的工作也不太相干，好像也不是那么的喜欢，所以就都不愿意做。
所以我说那我来试试吧，当时也刚好需要很长一段时间，就从一个普通的软件开发工程师就做DBA，然后慢慢做出来觉得还挺喜欢的。各方面这种工作、职业大概就坚持做3年多
我职业的这种转变，一方面是遇到的机会，当然最主要的是自己要想清楚，一旦先想清楚，要做好相应的准备，因为我们知道机会是明年回来，是明天会来。但是来了你如果抓不住，恐怕就要下一次了，但是下一次就不知道是什么时候。
从这个工作内容来说，其实7、8年前的数据仓库的建模工程师和现在的这种建模工程师，内容差别还挺大的。因为在7、8年前作为一个数据建模工程师，他的工作内容还蛮多的，除了要去承担一些这种技术层面的架构选型，业务逻辑层面的优化、本地化以外，还要承担大量的开发工作。
并不是说我把方案选定了，落地了有一个本地化之后，我的工作就基本上算告一段落，并不是这样。他要承担后期项目落地的工作，就是说他参与到整个数仓项目的设计，包括需求调研、确认、开发和部署。
但是现在因为现在这种行业的细分、工作也在细分。他把这个数据仓库建设的工作分了很多细分的东西。比如说按照他的流程分为需求工程师，他只负责需求的收集和确认，那么模型会分模型的设计工程师，也就是我们现在说的所谓的数据仓库建模工程师，他主要涉及这个模型在落地到某一家具体的公司或者是某一个行业的时候，他的模型到底要怎么优化，怎么去剪裁，出于一个很详细能落地的一个方案。这个方案落地完了之后，他的主要工作基本上算告一段落，后期会把这个模型或者方案提交给我们的开发人员，包括ETL流程，他可能也不参与过多的设计和开发。后期主要是我们的一些开发人员去参照他的这个模型方案去实现去落地。
所以我觉得结合到我的经验，我感觉从个人的发展角度，应该更多的参与到整个流程的处理。数据仓库模型的建设过程不是说仅局限于做需求，需求收集完我的工作就完了，或者说我只是拿一个方案就跟我没有关系了。
这样其实对于一个数据仓库工程师来讲，很难去承担一个建模、一个架构师的工作。
对这一块儿工作内容我建议，如果在做建模工程师的同学可以在项目上主动地去承担项目分给你的工作以外的其他的的工作。
因为它更像是一个流水线，他要打通整个流程。如果你这个流程始终只停留在某一个环节的话，其实你很难对整个数据仓库项目有一个全面的、直观的了解，那你也就很难成长为一个真正的所谓的数据仓库建模工程师。
建模工程师是数据仓库开发过程中的一个中间环节，是数据仓库开发工作的细分，建模工程师是专做模型的优化和落地以及方案实现，相当于似我们之前很流行的那种顾问的角色。
如果从数据建模工程师这个角度去看的话，把需求往业务系统去考虑，首先我们这个数据仓库或者集市范围在哪里，这个要由我们去和甲方沟通，框出一个大致的范围，以及明确我们整个企业哪一些业务。
比如以银行为例，银行会有比如说传统的这种存贷款业务、信贷业务、卡的业务，包括信用卡、储蓄卡，可能还有一些其他的金融类业务，比如债券等。那你现在建了这个数据仓库、集市、或者叫比较流行数据湖的概念，他到底含在哪些业务，这个推广一旦确定了这个范围之后，我们的数据仓库建模工程师就要基于这个范围去和相应的业务系统去沟通他的业务。
因为每个业务系统在我们数据仓库建设之前就已经成型，而且已经运行很多年了。他有自己的标准的业务模型，每一个业务都有自己的业务模型。我们数据仓库建模工程师必须要去了解。这个时候他了解基于这个业务模型之后，抽象出来属于那个业务系统的一些物理模型、概念模型和逻辑模型。
这个时候便于我们进行需求的收集整理，以及我们接口，甚至数据仓库业务系统的一个映射。因为这里边会涉及到两个概念，一个是业务系统的模型，还有是我们数据仓库的模型。这两个模型很相似的，有可能差异度很大。
当要把应用系统的数据纳入到数据仓库模型里面，涉及到一个两个模型的融合的问题。那么这个怎么融合？这就是数据仓库建模工程师主要做的一个工作，或者说他的一个价值体现在这里，这是一个非常重要的地方。
如果我们从数据开发这个环节说的话，比如说我如果是作为项目组中的一个核心的数据仓库的开发员的，首先我介入到这个项目之后，我要了解你的需求，非常明确的一个需求说明书要给我是，因为这是我在开发过程中要参考的一个文档。
比如说我要设计某个流程，某个业务逻辑处理，我要写一些代码，那么这个代码他其实就是我们业务需求上的一个转换实现。那么需求就是我的一个参照，这是第一点需求说明书。
第二点，我要了解数据仓库模型工程师最终设计出来的这个模型方案，方案其实我可以说他给我拿过来，他最终落地就是一个业务系统到数据仓库系统映射的一个方案，就是我们的一些表映射、一些业务规则的映射。这个方案我作为一个开发工程师一定要拿到，这是第二点。
第三，我要知道我们项目组整体的开发语言开发工具，开发环境。开发工具可能是一些市面上比较流行的、主流的开源或者闭源的商务工具。环境也要看是我们国产化的环境，或者是其他的一些环境，还包括我们的数据库环境、主机环境、ETL工具。
这个我作为一个数据开发工程师，我都要知道。有了这些基础之后，你还要给我提供一些开发环境、测试环境、生产环境，方便我进行一系列各自工作的开展，大概是这么一些。
以前的平台相对来说比较单一，而且基本上处于被国外的几个平台就垄断，也就不存在所谓的平台管理。
也就不需要这种基于平台的数据产品经理把控这一块工作。但是现在是这种基于大数据平台也好，或者MPP架构的这种平台也好，越来越多的厂家，你当做平台的时候，这几家平台他的兼容性关系非常大，因为它是类似于一个套件，你的套件要考虑到向上游进入、向下游进入，那上游我们说的可能更多的是报表展示工具，像下游可能是ETL工具，一些语言的选择。
MPP架构，是一种列式存储格式，比较有代表性的是HBASE 和Teradata两种列式存储平台
这个时候确实是需要有一个面向平台的，而且他了解多平台的这样一个数据经理去把控一些技术选型问题，包括给企业提供一些建议。比如说企业涉及到一个选型，比如说是这种可能是涉及到一个迁移。因为最近几年比较流行概念就是国产化。
那么这个国产化就涉及到你公司企业现有的这种布局，仓库平台不选择国产的平台，还是选择一个国外的平台。国内的平台有那么三五个，你选择哪一款更合适，更要结合有数据面向平台的这种推进。他去了解了之后，综合我们企业自身的特点，去提供一个比较合适的解决方案。
相当于目前工作的越来越细分，越垂直，然后其他衍生的岗位就更细了，也导致了两个问题。
第一项目组会比较臃肿，本来这个事可能就一个人到两个人就可以完成，但是现在可能需要3到4个人，而且单从时间上你会更长，这是第一个情况。
第二，他会让一个人在某一块做得很深，因为他只都是一块，但是会导致另外一个负面的问题，他只懂这一块，这一块向上向下，因为他不负责，所以他也不会顾及整个流程当中，他甚至对于他的上游都不关心，因为他上游可能就是另外一个同事在负责了，跟他们工作上没有交集，那这就会导致我们这种工作上的这种交集的部分会有一些到底是你来做还是我来做不清楚的情况。
如果说这种衔接不好的话，会给项目造成一些很负面的影响。
把这个数据仓库建模工程师理解为这个数据仓库建设期的一个枢纽，所有的需求、模型，包括业务系统模型都会流到他这里，由他进行整理，最后输出一个属于仓库的建设模型方案，然后再由他形成的这个落地的模型的建设方案去提交给我们开发人员，开发人员才能依据这个东西进行后续开发和测试和上线。
在有些在具体项目上，有的时候，建模工程师的这个角色，可能就是由某个平台的数据产品经理来承担，但是也要看情况，因为类似银行或者是四大行、中信这种体量太大，不可能说由数据产品经理去承担一个建模工程师的角色，只能说去向建模工程师去索要一些方案，当然是要经过建模工程师落地之后的东西，他去整理出一些他这个角色要输出的一些东西。
中国太大了，他其实也分城市不同级别，像北上广深这种一线城市，大数据的岗位的热度已经过去了，毕竟不是做那么热了，更多的是一些算法工程师或者搞神经网络的这种更往前一步的这种工程师更热门。
比如说你是数学专业的，你对算法有非常多的研究，一些神经网络上也有一些研究。像这种岗位在北上广深的需求大于大数据开发。但是对于二三线的省会城市，我了解到的，像新疆、甘肃这种西北的城市的大数据平台，甚至都没有建设的很好，那我还是比较如果说在那些城市的同学，去从事他自己公司的开发岗位，其实还挺有前途。
大数据开发工程师，首先他也分不同的内容。如果你是在大学学的这种软件工程的专业，那基本上是语言类C或者C++，那基本是大数据平台的开发工程师。像说我刚刚做一些接口，比如说举个简单的例子，这种大型的电商他每天的每秒钟的数据都是几个G、几百个G每秒钟。这时候对于这种几秒，每秒钟几一个G这种大数据量、超大数据量的这种处理能力，像我们这种一般的传统数据工程师因为他们没有那个能力，我觉得他的产品这时候需要我们一些基于大数据平台的和大数据平台语言的这种平台工程师去开发，去为这种每秒几个G上百G的数据接口做处理。
如果你是这种专业毕业的，那我觉得更好的去，比如说现在从事这种java开发前端工程师，他也可以很好的去转型，是大数据开发工程师的岗位。因为大数据平台开发供应商的语言和java的语言类速度是非常高，大概百分之七八十都相似，他不需要重新学习，这样相对门槛比较低，就是一个很基础的技术转型。
而且如果你去二三线城市的省会，这种项目很好，既包括通信或者金融，还有一个方向，刚才说是大数据开发工程师的方向，就是我们的大数据仓库的架构师。因为现在大数据平台对于像我刚才说的国内的那种二三线省会城市，处于选型或者优化过程中，这个是涉及到我再去给我的企业公司进行一个大数据平台的选型的时候，我到底选择国产的还是国外的一些更多的产品。像国外的产品，更成熟，但运维的成本也更高。
那么你选择国内的这种大A品牌的，相对来说成本要低得多。但是国内的产品因为我用过很多像国内的一些比较成熟的产品，他的产品相对来说不那么成熟，兼容性好不那么好。
那么你会觉得好像我花得很低的成本就部署一个更好的一个大数据平台，国内的是未来的这个维护成本也很高，你需要一个比较好的自身的团队来维护这个平台。这时候我们说基于这种考虑，就需要有一个从事大数据平台架构这么一个人来同时给你结合企业自身的数据信息化的特点，国内国外的这种大数据平台产品的选型、环境的部署、运维这块工作。
因为以前来讲的话，国外的这种产品在成熟度比较高，基本上部署完之后，后期的运维成本比较低。但是现在我们说产品平台太多了，他的成熟度相对降低了，这就导致你一定要有一个人或者是一个运维组会专门做整个大数据平台的部署，运维的工作性能调优等等。
关注微信