数据开发方法论

由于公司数据平台对ETL开发工具做了比较好的封装，较大程度上面提升了开发效率，数据开发同学的主要工作集中在写SQL，疲于应付各种各样庞大的业务需求。不少同学认为做数据开发没技术含量，技术上面没提升，久而久之产生厌烦感。

个人认为造成这种想法的主要原因是：

• 通过ETL方式解决一个点的需求，没有站在一个全局的角度来思考问题，建设数据，没有任何沉淀和反思。
• 对数据开发没有一个清晰地定位，其实建设数据是一件非常有挑战的工作。

面临的问题

数据仓库是一种体系结构，首先摆在我们面前的问题：

• 如何高效理解业务，将复杂业务用简单的模型来表示(建模)，最终落地点是数据仓库或者数据集市里面一张张表以及上层的一系列指标(如何分层，如何提高数据复用率等等)。
• 最佳的数据组织方式能高效地应对业务变更，更加灵活、高质量的支撑业务需求(你在建设仓库还是数据坟墓？)。

而这一切都需要较好的方法论来支撑，如何建设好是值得思考的。

端正态度

比较好的态度是：以解决问题为出发点来做数据开发。

• 系统开发和数据开发的目的都是为了解决问题，本质上是一样的，都面临着各种各样难以解决的问题，要认识到能建设好数据仓库是相当不容易的(数据重复建设、不一致、数据不完整、不易于理解等等)，难度比低于做好一个系统
• 建设数据仓库过程中也是非常需要采用工程方法来提升效率的，所以仓库建设和系统开发并不矛盾，应该积极寻找结合点，提升效率，而不能陷入疲于应付需求的泥潭。
• 后台或者平台开发和数据开发能力模型应该是不一样的，数据开发更加考验一个人的综合能力。
• 衡量一个工程师是否合格，最终落地点应该是 ”工作能力“

能力模型

个人认为：

• 数据处理以及建模能力，在这两方面应该做到足够的技术广度以及深度。
• 业务理解以及抽象思维、总结能力、问题到本质。
• 其他软素质比如沟通能力

要做好一个数据开发需要更加全面的素质。

一些方法论

如何快速理解业务

抽象思维

通常情况下，业务方会给出一大堆的指标或者一系列的需求，反正看起来比较复杂，这个时候要抽象思维

• 复杂—>简单，不要过度在意细节，抓住需求的本质，关键点，站在整体的高度来理解需求。
• 简单->复杂， 系统化，全面性，分解业务。

引入模型

任何复杂的业务都可以用一些简单的模型来表示，引入模型有助于我们快速分解需求，比如引入流量漏斗模型，围绕流量无非是分析：转化率、跳出率、停留时长等指标，而流量漏斗，即用户行为相对是稳定的，围绕这个漏斗的上下文(维度)可能会变化，这是我们重点需要关注的，再比如分析新老客户质量是引入客户忠诚度模型等，总之引入模型有助于我们理解需求，分解业务。

关于埋点

能在后台实现的尽量在业务后台服务埋点，尽量不依赖客户端，因为在客户端埋点可维护性比较差，且不灵活，统计效果依赖客户端发版。

关于模型选择

首先还要明确一点，数据仓库是面向分析的，所以一般情况下倾向于建设直观易于理解使用的数据，常用的关系模型以及维度模型区别在于划分世界的方式不一样：一个是实体关系，一个是维度模型，但都可以实现范式。

关系模型

将客观世界划分成关系与实体，数据仓库由一系列的关系以及实体组成，严格遵守3nf范式，数据一致性比较强，冗余度低。

通过参照完整性来保证一致性，采用关系模型生成的数据仓库往往成蜘蛛网结构，可读性差，不容易入手，对于非仓库建设人员要使用数据仓库中的数据成本是非常高的。

维度建模

维度建模方式将客户世界分解成事实和维度，建模过程的一大部分工作体现在抽取维度以及事实，相对来说更加直观，容易理解，在业务变更较为频繁的场景可以更加有效地覆盖业务需求。

数据仓库由一系列的事实表以及维度表组成，事实表与维表之间呈星型连接，事实表之间又通过特定维度联系，形成雪花结构。

3NF范式

3nf在第一范式原子性、第二范式不存在部分依赖基础上加入消除传递依赖，其目的是降低数据冗余度，提高数据一致性。关系模型有时候也被称为范式建模，但是这种说法是不太严谨的。因为关系模型好维度建模生成的表都可以符合3nf范式。