简单的个人信息

面试官，你好，我是王道伟，84年10月出生，07年毕业于浙江理工大学。做了9年的JAVA研发之后，16年10月我从微易的技术部转入刚成立的大数据团队，开始从事数据研发工作。所以，数仓相关的工作经历至今是有3年半的时间。

第一段经历

16年10月到18年6月在微易大数据团队期间，重点做了3个项目。

  1. 自建埋点和流量分析 2. 用户画像系统 3. “去赚钱”SKU排序改造

  2. 模型分层：ODS-pdw-app

  3. 5台emr集群，后来扩展到9台，用azkaban做任务调度

数据技术层面的问题，我在微易基本都接触了，

日志采集、数据同步（数据漂移、增量改全量、缓慢变化维）、离线用的hive和spark（了解MR原理和性能优化），用azkaban进行调度，实时用到了flink、数据服务（用presto提供数据查询服务）、数据挖掘用到了spark机器学习的包主要是用到kmeans聚类，工作内容和学习的技能都非常充实，唯独缺了一个：从0到1的搭建数仓

大数据团队的主要合作伙伴是用户运营部，他们关注的是用户活跃和价值转化。第一个重大的项目，就是和他们一起推动了公司的自建埋点。我作为技术架构的负责人，负责调研并提出了整体技术方案，和APP前端、日志服务后端共同完成方案落地。数据方面，我负责开发了APP内各渠道订单转化率的相关报表。

第二个重大项目是用户画像，主要的合作伙伴是BI团队，他们产出了用户生命周期分析报告，解决了用户指标的时间周期问题，然后他们定义好用户属性、指标和相应的统计口径，我负责开发相应的维表和汇总表。画像系统需要和营销系统打通，所以画像的存储方案也经过了3个版本的迭代。

做完这2个项目之后，具有里程碑性质的项目基本是做完了，所以我和BI团队中的一个小伙伴自驱的做了一个实验性项目：“去赚钱”SKU排序改造

三个项目：第一个是自建埋点以及流量分析，作为数据的最终使用者，我需要保证app前端、日志服务后端的方案落地和数据入库。第二个是用户画像服务，BI团队负责主题域内容，比如用户维表、统计指标的定义，我负责搞定ETL和存储方案；第三个是“去赚钱”SKU排序改造

第一段总结

18年7月初我正式从微易离职，结束了差不多2年半的微易生涯。在微易，我从JAVA研发转型到数据研发，掌握了数仓建模、ETL开发、数据产品研发的技能。

– 从职业发展角度来看，我需要在数据研发的某个领域深挖下去，比如数仓建模。

– 我跳槽去了政采云这家公司，他们数仓团队也是初创，需要搭建一个新的数仓。

第二段经历是在政采云，主要是独立搭建了数仓

18年7月加入政采云之后，通过一个月的熟悉，我了解到日常数据开发的现状，2个人负责日常数据提取需求，在阿里云的数加平台上进行开发，没有数仓分层和建模、没有ETL监控和统计。

为了解决这些问题，我提出了命名为纵横以治天下的治理方案，将数仓设计为ods-cdm（dim+trans+snapshot）-dws-app的4层架构，每一层都会有一个虚拟任务节点来汇集该层的任务数和完成时间。

确立完数仓分层设计之后，就是建模和开发过程，包含报表梳理、需求分析、业务调研、顶层设计和详细设计，最后是物理设计和模型开发，产出了一系列的ETL任务和配套文档

在阿里云odps、也就是dataworks上开发的，技术上没有接触到新的内容，把建模方法论给建立起来了。

接下来，就是需求分析和业务调研阶段，邀请产品和开发演示系统功能，了解各个系统的业务流程；将之前开发的报表分类梳理，整理出整体的数据需求。因为之前的rds是在政务云上，和阿里云数加是网络隔离的，因此需要额外做数据传输工作。而在政务云上新发布的数加2.0版本，和rds是连通的，因此数仓是数加2.0上开发。

第二段总结

19年1月完成数仓的建设，后续的1个多月，将之前的报表需求进行了迁移。回顾下我在政采云的9个月，最大的成就就是通过学习和实践，确立了建模方法论

– 除此之外，个人的成长途径不是很清晰，团队规模也没有成长。

– 所以我跳槽去了大搜车

第三段经历是在大搜车

19年Q2

我入职大搜车的前3个月，有人员离职、转岗、工作职责调整等原因，我接手了5个人的工作内容。

另外，为了了解每个人的工作日程，我设计了一套日报、周报模板还有团建活动，带动团队成员去分享各自的工作内容和日常想法，希望能解决团队缺失工作协同的问题。

到了Q3

经过3个月的熟悉，我就开始思考如何重构数仓，持续到现在。

重构与主题域、数仓构建模式的关系：

我负责带领4位同学做画像服务的重构项目。首先，我对4位成员分别做了面试，了解他们的工作经历和专业技能，主要是了解他们对数仓的认知程度。实际上，团队成员对数仓的理论知识了解的比较少，虽然都开发过画像相关的表，但是都停留在把需求方给出的统计口径通过sql开发出来的程度。基于对画像服务和团队成员的了解，我把Q3的目标定为2个：1是项目目标，完成重构项目；2是团队目标，带领团队实践建模方法论，做到初步掌握。

画像，对很多应用方来说，意味着可以全貌的去看待和分析一个主体对象，比如用户、商家。对我们数仓来说，画像是什么？我首先需要的，是为小伙伴们解答这个问题。

然后是具体的工作任务，我产出了画像技术架构文档（人车店主题域的开发，画像是主题域的一个子集），从数仓层面上对画像系统进行了说明，保证团队达成统一的认知。然后，我设计了主维度、业务线子画像的文档模板，将4个画像分派到每个人，指导他们对指标和任务链路进行梳理。

因为，原来的模型表改造工作量巨大，我们团队只能对汇总层的模型进行简化，拆分、整合等等

19年Q4，背景很复杂：

  1. 原来的画像重构小组虽然已经初步掌握了数仓的相关知识，但是长久以来缺少业务相关知识和模型文档的情况下接手日常需求和模型维护工作，实在难以胜任
  2. 需求排期和交付都没有相应的规范，出现过需求少做、需求反复、需求交付了无人接收等等情况
  3. 任务多人力少、额外沟通较多，耗时耗力

通过JIRA进行需求管理，规定每个阶段各方的职责和交付物，保证需求交付有序进行

后续又增加了2个职责：

  1. 为后续应用迁移做准备，对当前应用进行梳理
  2. 对当前的任务和表进行权限管控，建立业务线集市

20年Q1 对接新模型

受疫情影响，整体需求量有所减少、而且新模型也逐步有产出，考虑在这个季度开始对接新的模型，做一些试点需求。但是从模型文档来看，离我的要求有些差异。

  1. 质量无法保证、数据源治理没有解决
  2. 没有顶层设计文档，对业务过程和维度进行描述和定义，粒度描述不规范、度量不清晰、维度的自然键未申明、维度层次也没有说明
讲智云迁移，比较合适
  1. 三范式建模
  2. 面向主题进行迁移

做了3年多的数仓开发，和之前的JAVA研发相比，我觉得日常工作更细碎繁琐，团队内的小鲜肉有时候会因为工作内容和我吐槽，也会开玩笑的问我，他们是不是合格的sqlboy和工具人。我和他们分享自己这3年的工作经历和感悟，每个阶段都是需要完成自己的成长任务，这些日常工作的过程中，有没有在踏踏实实的实践自己所学的数仓理论和方法，在解决这些问题的过程中是不是提升了自己对数仓的认知。我觉得有很多人对数仓这份职业有错误的判断。

数仓建模方法论

  1. 数仓是什么？

    4特征：面向主题、集成、稳定、随时间变化的数据集合

    1目标：用于支持管理决策过程，所以数仓的一个原则是，以业务和需求为中心

  2. 模型是什么？

    一种知识形式，它对知识进行有选择的简化和有目的的结构化

  3. 所以数仓建模，就是在数仓中存储知识

  4. 数仓建模方法论是什么？如何在数仓中保存知识？

    理论上：

    1是从0到1的建立数仓，项目的形式

    ​ 需求分析->需求文档

    ​ 建模设计 - 4步骤 选择业务过程、申明粒度、确认维度、确认度量

    ​ 产出顶层设计文档、详细设计文档、物理设计文档

    实践上：

    2是接手之前的模型和文档，做迁移、重构或是日常维护

    ​ 面向的是文档和sql，sql如何和维度模型建立关系？

我是如何指导他们的

  1. 开书目，了解基本的数仓理论
  2. 分享编程经验和技巧
  3. 思维锻炼：
    • 从sql中梳理出顶层设计问题，再反推需求文档；模型答疑的情况
    • 详细设计，而不做ETL开发：负责业务线的同学短期内有较多需求的情况下，会按此执行
    • 业务开发给的sql和ER模型可能不是很合适：案例就是，工单模型的梳理