接着6.4.2 往下看
3. 上游数据ETL异常或失败导致标签加工失败
这种失败原因比第2条失败原因更难发现。当上游数据已经加工完毕，写表落仓后，即使在HDFS商查找上游文件的写入时间
也不会发现问题。此时可通过横向对比该上游表近期每日的数据量来发现是否存在问题。
例如：
对于按日期分区的订单信息表dw.order_fact，可通过命令 “select data_date, count(*) from dw.order_fact where data_date>='20180701' and data_date<='20180707'
来看近几日的标签量是否存在较大的波动。当发现昨日数据量下降较多时，即有可能是中上游数据加工异常导致的标签问题。
4.标签脚本逻辑导致数据加工失败
这种情况也是可能引起错误的原因之一。标签上线前期ETL作业正常，但随着时间的推移，积攒的问题最终会爆发出来。这里举一个开发过程中遇到的问题来进行详解。
我们知道一个用户（userid)可能在多个设备上登录，同一个设备（cookieid)商可能登陆过多个用户，即userid 和 cookieid 为多对多关系。在某次开发需要从cookieid关联到userid，获取userid的状态标签时，忽略了这两个维度之间的多对多关系，未加条件限制。
初始化标签数据时，脚本执行后跑出“看似合乎逻辑”的数据。但ETL 作业调度两天后，这种直接多对多关联的错误逻辑，引起了数据膨胀，造成作业执行失败。
因此，在排查问题时同样要检查开发标签的逻辑是否存在BUG。
注：
第二章内容
互联网相关企业在建立用户画像时，一般除了基于用户维度（userid)建立一套用户标签体系外，还会基于用户设备维度（cookieid)建立相应的标签体系。
基于cookieid维度的标签应用也很容易理解，当用户没有登录账户而访问设备时，也可以基于用户在设备上的行为对该设备推送相关的广告、产品和服务。建立用户标签可以分为统计类、规则类和机器学习挖掘类。
建立画像标签时，画像表里。用户的每个标签都插入到相应的分区下面，但是对于每个用户来说，打在他身上的全部标签存储在不同的分区下面。为了方便分析和查询，需要将用户身上的标签做聚合处理。标签汇聚后将一个每个用户身上的全量标签汇聚到一个字段中，表结构设计如下：
Create Table `dw.userprofile_user_label_map_all`(
`userid` string COMMENT `userid`,
`userlabels` map<string,string> COMMENT `tagsmap`,)
COMMENT `userid 用户标签汇聚`
Partitioned by (`data_date` string COMMENT `数据日期`）
如果userid 和 cookieid 是1对1关系，cross join 会少很多，但是如果两个数值之间是多对多关系，相信相差会比较大。
参考这里：
https://www.toutiao.com/article/7053625857465713188
t1 cross join t2 ，hive sql 里面 cross join 的含义，另外t1.tag_id <> t2.tag_id 表示用表t1的tag.id（疾病种类） 和 表 t2的tag_id（科室种类） 进行正交
下文解释了cross join,用a表的所有队列 笛卡尔积 b 表的所有队列。参考：
https://www.sqlshack.com/sql-cross-join-with-examples/ （深度一点的解释好像都是外文的，哎，老外更爱分享）
cross join 要把第一个表的相关列 a 和 第二张表的相关列 b 都要做一次组合，这样生成的表列数会是 count(a)*count(b)，这样如果把user_Id 和 cookie_id 做cross_join ，数据的确会指数级增长。
开发某个用户的标签时，需要从多个维度标签表获取数据[书本page40,图1]，这些维度如果都按照cookie_id来做，会有错误，并且数据过大的问题。应该是需要基于拉链表，找到cookie_id 最新和用户的映射关系，来判断是不是同一个用户。[本书page42,图2]
基于cookie_id 和 基于user_id 查到的数据，如果直接cross_join,数据量会很大，这个时候可能要关注去重的问题。有些场景，cookie_id 可能不是一个user_id。（单设备登录多账号情况）
图1
图2
5.线上业务变动导致原有标签加工逻辑失败
这种问题虽然不常见，但发生时也会引起标签数据的波动。
例如：通过正则表达式解析网页链接来获取用户访问页面对应的商品品类，在这种场景中，当线上业务变动时会导致原有的链接改变，而正则表达式是固定的，从而导致不能解析变动后的链接。
对于这种情况应尽量避免，需要运营方在上线新的链接前通知标签开发人员。
6. 本章小结
如果说在数据开发日常工作中什么最重要，那一定就是维护调度流的稳定性了。数据稳定性有了保障，体用到服务层的数据的质量才有保障。
本章介绍了如何使用开源ETL工具Airflow 进行画像相关任务的调度工作及出现问题时的排查方法，通过数据预警机制保障每天的数据产出、提供的服务的可靠性。
,
