数仓技术架构&采集同步

1 数据同步工具

datax

也有集群模式了，现在性能应该还好。

sqoop

就是调度了map任务
集群加机器了记得要在数据库那边加入白名单

Flume

几十上百台日志服务器的话，直接往hdfs上写也不现实，一般会做两层flume，第二层放个三两台再往hdfs写。
一般会后面布kafka，实时离线都从kafka消费，保证数据统一。

注意下inuseprefix就是文件在写但是没写好的时候，加上 这个 点 的前缀，隐藏掉，不然hive查的时候，本来在这个tmp文件查到数了，后面你这个文件又没了，就报错。
再一个就是设置下文件的切断时间，大小，不然来一条就存一个，很多小文件，之前的经验也是设置一个小时或者128MB双重切割的。

2 调度系统

Oozie

与hadoop、hive、spark有版本依赖关系，注意jar包冲突
可以时间触发，还可以数据触发

azkaban在报警、失败重启方面比oozie差一些

oozie的封装

也可以写shell命令上传jar包，运行spark任务

3 数据通道案例

flume-kafka-实时计算 这个玩意能实时？

4 数据采集与同步

业务数据已经有了，不用太操心；行为数据，埋点、采集策略还是得关注

4.1 行为数据埋点设计

4.1.1 方法

pc端一般用cookieid(存在cookie里的一个标识数据)来标识客户，清cookie就没了。

cid是全局唯一的，pc手机pad啥的都算上，uid在表里是可以重复的，就是多屏用户的打通
c1上登录了u1，后面u2也用这个设备了，那这个cid就要变成c2，只要没有新的uid登录进来，再后面是c2登录进来或者没有登录态的就都算到c2的行为，保证行为有归属。

webh5抓浏览信息方便，app抓设备信息方便

推荐服务端采集，前端行为拿不到的话可以js请求后台

打通行为和业务：一般就是通过cust_no关联，完了再去相应的时间去找，很不方便。
==>搞一个类似session_id的东西，在行为数据和业务数据里面都有，这样就好关联了。

4.1.2 案例

需求：

格式：

搞一个pageid，在app搞不到url的时候用的，wifi位置啥的也都带着，如果只有app启动的时候上报一次，那后面变化了就抓不到了。

1 启动事件：app安装、使用列表，通讯录，设备位置信息等

2 列表页：
普通的就抓下url相关和设备相关，如果涉及到曝光计费的话，还要加上曝光产品，这里也分ajax和分页两种情况。
这里的事件类型应该是view

分页的：

ajax

3 详情页
详情页分click事件和view事件，点击了页面是不一定会加载的，从这里也能一定程度优化产品。
内容里面有商品id、商家id、点了什么位置等

详情浏览：

4 主页
主页主要考虑sourceid，看下用户是怎么来的，通过什么渠道来的，对公司的渠道推广业务有影响的。
app也是有source的，比如营销短信里的短链接=>h5=>app

5 banner位的点击：
这块关注的是点了什么位置(第几个)，目的地是哪个url

4.2 埋点数据上报采集

这里处理的地方一边推到kafka，同时也要在本地写文件，保证数据不会丢失。
另一种方案就是先写flume再推kafka，这样就是牺牲了一些实时性能。

4.3 数仓数据处理

4.3.1 落地hive ods表设计

分启动事件和普通行为事件

4.3.2 bdw层，用户标识体系，多屏数据打通，数据降维

用cid关联那张映射表，补充一下uid为空的数据，存入bdw层，_i表示incre每日增量。

降维：
=>在推送到kafka之前，如果可能的话，java程序里面就提前处理一些公用的字段，比如ip解析成省市区，
=>agent解析成相应的字段再发kafka

关于页面访问时长的计算：同用户同session相邻页面访问时间差

4.3.3 edw层，通用统计计算，公用数据层

做一些能满足日常需求的轻聚合的表，比如用户会话页面级别的统计等
有需要可以在这里适当降维，就是加进来一些维度信息

4.3.4 实时计算这边能用到的，就落地存储

4.4 业务数据

4.4.1 埋点

唯一自增id，有创建和修改时间，

4.4.2 同步策略