让数据库简简单单地 for you

一、数据是怎么产生、传递、应用的

1.大概框架

2.框架细度

1）第1层：业务库产生数据

执行人：后端的开发rd哥哥们

具体执行操作：通过app端、微信等应用端（用户或者教练产生的活跃、消费等行为），以及我们自己公司内部的运营后台（运营自己填的东西，比如课程类型，运营是需要在运营后台配置的），rd就会把这些行为进行分库，比如分为用户库，订单库，教练库，这一层非常重要，因为直接性的也决定了，我们数仓的ods最底层的建设（ods后面讲），而目前我们数仓就败在这一层的；但这一层产生的数据是100%准确的，因为无加工。

主要应用语言：一般情况下是mysql，且如果数据底层建设的好的话，数据分析师不需要和这一层打交道对接的。

2）第2层：数仓数据库

执行人：数仓这边

具体执行操作：数仓会有个四层建设；白话文就是可以分为三部分也够了。第一层就是ods层，就是直接从第1层复制过来，表和数据（只是，这个时候很多大数据公司都用了hive sql，小部分公司是sql server，我们公司就是sql server，但是当数据量达到一定体量的时候，用sql server是不足以支持业务的，后期可能我们也会转移到hive sql）； 然后数据仓库的第二层，中间层就是将ods的源始数据，进行向上聚合，可以理解为ods层本来做一个需求需要用到五六张表，而中间层就只需要用到一两张表；然后就是第三层，应用层。是直接让数据分析用的一层，dw层。需要结合业务，并且根据数据量来看是要做增量表还是全量表；简单来说，就是业务性和时间性比较强的一层，数据分析师可以用，并且一个好的仓库建设好，数据分析师其实只需要用到这一层的表。只有当着一层的表，数据分析发现有问题或者缺数据，反馈到仓库，让仓库再去查，这个dw的表来源于第二层的什么表，然后第二层的表又来源于第一层的什么表，如果数仓这边觉得他们ods拉取没有任何问题，也不是数据库崩溃等问题，他们就会直接找开发，去看看是不是开发那边bug了（找开发这个流程吧，除非在一个很强的数仓团队，否则数据分析师还是要参与，因为仓库普遍不懂业务）。

主要应用语言：目前我们用的是sql server；后期，我感觉会顺应hive sql

3）第3层：数据应用

执行人：数据分析师

具体执行操作：最终目标，当然只需要用dw的表；

主要用用语言：目前我们用的是sql server；后期，我感觉会顺应hive sql

附：

那么业务开发怎么收集到上面说的两方面的数据的呢？

1）app、移动的数据

收集这部分数据主要靠埋点。一般大公司会靠后端开发去写代码埋点，比如看一个用户登录，购买等一系列行为，他每到一个页面，每发生一次购买成功行为，都是一个埋点记录。一般购卡成功，登录成功失败这种的属于后端埋点；而一般用户的浏览、点击行为都是前端埋点；

但是，我们创业型公司一般都是买的服务，我们目前用的growing io来记录，收集sdk来看数据，时间和人工成本少。但是可操作性差。这部分数据，目前我也还没有参与，所以具体我们公司是什么样的还不太了解。

2）运营配置后台

这个就比较简单，因为后台就是我们自己的，所以底层数据，就会直接记录，也完全可以理解为后端埋点。

但是目前，这一块我们公司坑比较多，后端业务那边的表乱，比如运营一添加个课程类别，后端这边的表变了，但是没有同步给仓库，仓库那边就不知道，数仓这边就不会有添加的这个课程类别，从而导致我们分析师取出的数据有问题