- 数据采集平台
日志采集系统：是通过埋点来收集用户行为信息 存储在上日志文件
业务系统数据库：统计通过捕获交易事务重要事件的细节，建立活动记录 如：用户喜欢、在线时间离线时间、下单、支付等业务交互 存在mysql上
爬虫系统：是一种按照一定的规则，自动地抓取万维网信息的程序或者脚本、传统爬虫从一个或若干初始网页的URL开始，获得初始网页上的URL，再不断从当前页面上抽取新的URL放入队列，直到满足系统的一定停止条件、一般来说是一些小公司(它没有大公司的那些数据，也想用所以就用爬虫拿别人的)
数据来源：通过前端埋点来获取用户的行为日志(停留,搜索,双击,单机等操作)
通过用户来对使用我们能电商平台的时候,进行的业务交互(下单,支付,加购等)
埋点：
代码埋点是通过调用埋点SDK函数，在需要埋点的业务逻辑功能位置调用接口，上报埋点数据。例如，我们对页面中的某个按钮埋点后，当这个按钮被点击时，可以在这个按钮对应的 OnClick 函数里面调用SDK提供的数据发送接口，来发送数据。
可视化埋点只需要研发人员集成采集 SDK，不需要写埋点代码，业务人员就可以通过访问分析平台的“圈选”功能，来“圈”出需要对用户行为进行捕捉的控件，并对该事件进行命名。圈选完毕后，这些配置会同步到各个用户的终端上，由采集 SDK 按照圈选的配置自动进行用户行为数据的采集和发送。
全埋点是通过在产品中嵌入SDK，前端自动采集页面上的全部用户行为事件，上报埋点数据，相当于做了一个统一的埋点。然后再通过界面配置哪些数据需要在系统里面进行分析。
使用的组件：Flime Kafka Sqoop
flume的设计宗旨是向hadoop集群批量导入基于事件的海量数据。
采集数据：
日志数据：通过flume的断点续传来获取我们得到的用户行为数据,拉取到kafka中,这里其实也可以直接拉取到kafka中,但是太麻烦了,flume可以直接获取数据,简单易用,通过kafka的特性来对数据进行削峰,解耦,然后通过kafka+flume来对数据直接拉渠道hdfs上,也就是缓冲层
业务数据：通过sqoop的命令,直接拉取到hdfs上,指定lzo压缩,到hdfs为缓冲层
采集数据为什么要用flume+kafka
一般使用Flume+Kafka架构都是希望完成实时流式的日志处理，后面再连接上Flink/Storm/Spark Streaming等流式实时处理技术，从而完成日志实时解析的目标。
1. 生产环境中，往往是读取日志进行分析，而这往往是多数据源的，如果Kafka构建多个生产者使用文件流的方式向主题写入数据再供消费者消费的话，无疑非常的不方便。
2. 如果Flume直接对接实时计算框架，当数据采集速度大于数据处理速度，很容易发生数据堆积或者数据丢失，而kafka可以当做一个消息缓存队列，从广义上理解，把它当做一个数据库，可以存放一段时间的数据。有很好的缓冲效果，可以起到一个消峰的作用。
3. Kafka属于中间件，一个明显的优势就是使各层解耦，使得出错时不会干扰其他组件。
因此数据从数据源到flume再到Kafka时，数据一方面可以同步到HDFS做离线计算，另一方面可以做实时计算，可实现数据多分发。
Flume用什么Source
- ExecSource：不安全，可能会丢数据！
- SpoolingDirSource：可以读取一个目录下的文件，读取过程中要保证目录是封闭的，即在读取过程中不能往目录追加日志，这样肯定不行，因为在生产环境中日志数据是源源不断生成的。
- TailDirSource：接近实时读取指定文件或者目录！所以使用此Source！
为什么用KafkaChannel
优点： 基于kafka的副本功能，提供了高可用性！event被存储在kafka中！即便agent挂掉或broker挂掉，依然可以让sink从channel中读取数据！
为什么要用MySql存储业务数据
主要原因：
1.数据量大，在进行DDL时，几乎是毁灭级别的，虽然现在online DDL在逐渐完善，但仍有没办法进行online的操作，开销很大，由于业务需求，为表增加列，往往是不可避免的，虽然可以用预留字段的方式一定程度上规避这个问题，但不可能为每张表都预留字段，预留字段也不可能无限多
2.随着数据量的增长，索引的效率会越来越低(如insert的场景，insert当然和索引有关系，之后再单独写一篇文章吧)，这个问题即使在Oracle上也是尤其明显的；
3.备份恢复难，几千万甚至上亿的表，备份与恢复的时间都会非常长，在出现异常需要恢复时业务恢复时间变得不可控。越来越多的用户意识到了这个问题，开始去使用分布式关系型数据库，目前仍然被讨论的比较多的是开源代表MyCAT，以及阿里云DRDS。
MySql并发承载能力大 能存储大量关系型数据的存储能力
（单表超过1亿，MySQL也可以正常存储，并出色的完成查询，我们的生产环境是验证过的(表1.8亿，列很少，结构非常稳定，没有DDL),但单个MySQL确实不推荐存储海量数据，建议单表500W-1000W）
DRDS(阿里): 数据分片、平滑扩容分布式、MySQL执行引擎
为什么选择Sqoop
通常基于三个方面的考虑：
1、它可以高效、可控地利用资源，可以通过调整任务数来控制任务的并发度。另外它还可以配置数据库的访问时间等等。
2、它可以自动的完成数据类型映射与转换。我们往往导入的数据是有类型的，它可以自动根据数据库中的类型转换到 Hadoop 中，当然用户也可以自定义它们之间的映射关系。
3、它支持多种数据库，比如，Mysql、Oracle和PostgreSQL等等数据库。
为什么不用Datax：他不支持分布式
二、清洗
通过ETL放入数据仓库
ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程
可以用任何的编程语言去开发完成
三、数据仓库
数据仓库是一个面向主题的、集成的、稳定的、反映历史变化的各个数据(包括历史数据和当前数据)的中央储存系统，其应当提供数据的存储、管理和分析功能
面向主题：数据仓库侧重于数据分析工作，所以数据仓库中的数据是按照一定的主题进行组织和存储。
集成：对原有分散的数据库数据经过系统加工、整理，消除源数据中的不一致性。
稳定：数据进入数据仓库以后只需要定期的加载、刷新，不需要频繁修改。
反映历史变化：出于决策的需要，数据仓库中的数据都要标明时间属性。通过这些数据信息，对企业的发展历程和未来趋势做出定量分析预测。
数据仓库能为数据挖掘、多维分析、决策支持、报表等系统和应用提供一致的、准确的、易用的数据
数据仓库包括对数据的：清洗、转义、分类、重组、合并、统计等等
数据库与数据仓库的区别，实际上就是OLTP与OLAP的区别。
操作型处理，叫联机事务处理OLTP（On-Line Transaction Processing），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发的支持用户数等问题。传统的数据库作为数据管理的主要手段，主要用于操作型处理。
分析型处理，叫联机分 析处理OLAP（On-Line Analytical Processing），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
为什么要数仓分层
1.隔离原始数据 2.复杂问题简单化 3.减少重复开发
企业价值链
每家机构都有一个关键业务过程组成的潜在价值链，这个价值链确定机构主体活动的自然逻辑流程。数据仓库建设就是围绕着价值链建立一致化的维度和事实。
数据仓库构成
基础：调度系统，数据管理、数据监控
数据流：数据采集---数据传输（同步、转换）---数据研发（ETL）
数据采集--数据传输--实时计算（流计算）
辅助功能：元数据管理 权限 血缘 成本管理
规范：数据仓库规则，表名规则，字段规范
应用：数据产品，分析、算法，ABtest，用户画像，数据分析，数据挖掘，搜索
数仓架构的原则：
1、底层业务的数据驱动为导向同时结合业务需求驱动
2、便于数据分析
屏蔽底层复杂业务
简单、完整、集成的将数据暴露给分析层
3、底层业务变动与上层需求变动对模型冲击最小化
业务系统变化影响削弱在基础数据层（资金订单改造）
结合自上而下的建设方法削弱需求变动对模型的影响
数据水平层次清晰化
3、高内聚松耦合
主题之内或各个完整意义的系统内数据的高内聚
主题之间或各个完整意义的系统间数据的松耦合
4、构建仓库基础数据层
使得底层业务数据整合工作与上层应用开发工作相隔离，为仓库大规模开发奠定基础
仓库层次更加清晰，对外暴露数据更加统一
数仓模型不只是考虑如何设计和实现功能，设计原则应该从访问性能、数据成本、使用成本、数据质量、扩展性来考虑。
一致的维度和事实是数据仓库的基石。
事实表：官方定义是：发生在某个时间点上的一个事件
发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。从最低的粒度级别来看，事实表行对应一个度量事件。可以理解为：在现实中发生的一次操作型事件
事实表存放用来描述业务的大量数据,包含了与各维度表相关联的外键.
事务表实表的一行，对应空间或时间上某点的度量事实。既记录业务系统中的事务行明细数据，比如典型的表有下单明细表、推单明细表、支付明细表等，基本每一个表对应一个典型的事件类型，这类表记录了业务最明细的数据。
特征: 在事实表里没有存放实际的内容，他是一堆主键的集合，这些ID分别能对应到维度表中的一条记录。
优点：1）业务直观，在做业务的时候，这种表特别方便，直接能对到业务中。
2）使用方便，写sql的时候很方便
缺点：数据冗余巨大，真的很大，在几亿的用户规模下，他的订单行为会很恐怖、粒度僵硬，什么都写死了，这张表的可复用性太低
事实表根据粒度划分
事务粒度事实表:记录事务层面的事实,保存的是最原子的数据,也称"原子事实表".事务事实表中的数据在事务事件发生后产生,数据的粒度通常是每个事务一条记录.一旦事务被提交,事实表数据被插入,数据就不再进行更改,其更新方式为增量更新.用户可以通过事务事实表对事务行为进行特别详细的分析.
面向事务的，其粒度是每一行对应一个事务，它是最细粒度的事实表
周期快照粒度事实表:周期快照事实表以具有规律性的、可预见的时间间隔来记录事实.周期快照事实表的日期维度通常是记录时间段的终止日,记录的事实是这个时间段内一些聚集事实值.通常比事务事实表的粒度要粗,是在事务事实表之上建立的聚集表.周期快照事实表的维度个数比事务事实表要少,但是记录的事实要比事务事实表多.事实表的数据一旦插入即不能更改,其更新方式为增量更新.
按照良好的时间周期间隔(每天，每月)来捕捉业务活动的执行情况，一旦装入事实表就不会再去更新，它是事务事实表的补充，而非替代品
累计快照事实表:累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度,它通常具有多个日期字段,用来记录整个生命周期中的关键时间点.还会有一个用于指示最后更新日期的附加日期字段.周期快照事实表记录的确定的周期的数据,而累积快照事实表记录不确定的周期的数据.
用于描述业务过程中某个不确定时间跨度里的活动，它随着业务活动的发生会不断的更新。
根据用途划分 :
原子事实表:是保存较细粒度数据的事实表.
聚集事实表:是原子事实表上的汇总数据,也称为汇总事实表.
合并事实表:是指将位于不同事实表中处于相同粒度的事实进行组合建模而成的一种事实表,它的维度是两个或多个事实表的相同维度的集合.合并事实表的粒度可以是原子粒度也可以是聚集粒度.
维度表：每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，维度表行的描述环境应与事实表行完全对应。
维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。
维度表中存放着详细的数据信息信息
优点：1）数据冗余小（因为很多具体的信息都存在相应的维度表中了，比如客户信息就只有一份）
2）结构清晰（表结构一目了然）
3）便于做OLAP分析（数据分析用起来会很方便）
缺点：1）增加使用成本，比如查询时要关联多张表
2）数据不一致，比如用户发起购买行为的时候的数据，和我们维度表里面存放的数据不一致
常用的维度表
(1) 时间维度表:描述星型模式中记录的事件所发生的时间,具有所需的最低级别的时间粒度.
(2) 地理维度表:描述位置信息的数据,如国家、省份、城市、区县、邮编等.
(3) 产品维度表:描述产品及其属性.
(4) 人员维度表:描述人员相关的信息,如销售人员、市场人员、开发人员等.
(5) 范围维度表:描述分段数据的信息,如高级、中级、低级等.
其他维度表
杂项维：如果每个属性值都很少，可以把这些维度的组合起来生成一个维度表。
支架维：如果维度之间是一对多的关系或区别于原维度的多个描述性维度属性，可以建雪花型支架维度。
多值维度桥接维：如果二个维度表是多对多的关系，可以使用多值维度设计。
微型维：一个大型维有些属性变化比较频繁，把这些属性单独生成一个微型维度表。
缩小维：它是维度表的一个子集或部分属性。
手工维护的维表：有些数据不在业务系统里，需要业务用户手工维护的维度表。
范式：（反范式化）
范式可以理解为设计一张数据表的表结构，符合的标准级别、规范和要求。
一些约束、规范、规则 来优化数据库表的设计和存储，这些规则就称为范式
第一范式：是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
原子性：表中每列不可再拆分。
第二范式：是指每个表必须有主关键字(Primary key),其他数据元素与主关键字一一对应。
它的规则是要求数据表里的所有非主属性都要和该数据表的主键有完全依赖关系；如果有哪些非主属性只和主键的一部份有关的话，它就不符合第二范式。
不产生局部依赖，一张表只描述一件事情
第三范式：就是指表中的所有数据元素不但要能唯一地被主关键字所标识,而且它们之间还必须相互独立,不存在其他的函数关系。
不产生传递依赖，表中每一列都直接依赖于主键。而不是通过其它列间接依赖于主键。
目前业界范式有：第一范式(1NF)、第二 范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。
反范式化：
由于数据库的三大范式和数据库的性能有时是矛盾的。没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。
过程
ODS:原始数据 引入层
这些数据未经处理，是最原始的数据。在逻辑层面上，这些数据都是以二维表的形式存储。
也起到备份的作用，数据采用lzo压缩，减少磁盘存储空间，100G数据可以压缩到10G
创建分区表，防止后续的全表扫描，在企业中大量使用分区表
（分区表将数据组织成分区，主要可以提高数据的查询速度。
如果把一年或者一个月的日志文件存放在一个表下，那么数据量会非常的大，当查询这个表中某一天的日志文件的时候，查询速度还非常的慢，这时候可以采用分区表的方式，把这个表根据时间点再划分为小表。这样划分后，查询某一个时间点的日志文件就会快很多，因为这是不需要进行全表扫描。）
创建外部表，在企业开发中，除了自己用的临时表，创建内部表外，绝大多场景都是创建外部表
DWD:明细数据、维度建模 明细数据层 (DWD是以业务过程为驱动)
是业务层与数据仓库的隔离层 事实表（事实模型，又称事实逻辑表）作为数据仓库维度建模的核心，紧紧围绕着业务过程进行设计
DWB:基础数据层
存储的是客观数据，一般用作中间层，可以认为是大量指标的数据层。
DIM 维度层
建立一致数据分析维表，可以降低数据计算口径和算法不统一风险。以维度作为建模驱动，基于每个维度的业务含义，通过定义维度及维度主键，添加维度属性、关联维度等定义计算逻辑和雪花模型，完成属性定义的过程并建立一致的数据分析维表。
(之后的DWS层,DWT层和ADS层都是以需求为驱动,和维度建模已经没有关系)
DWS层和DWT层都是建宽表,按照主题去建表.主题相当于观察问题的角度.对应着维度表
DWS:汇总数据、按天汇总 汇总数据层
汇总数据层以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求构建公共粒度的汇总表。汇总数据层的一个表通常会对应一个统计粒度（维度或维度组合）及该粒度下若干派生指标
DWT:汇总数据、累计汇总 累积型全量表
DWT层统计的是不同主题的累积数据
DWT层将DWS层每日聚合的数据进行积累，DWT层不是分区表，是一个累计型全量表，并且数据来源于DWS层
累计全量表：查询要改动的旧数据，查询新增和变化的新数据，新旧关联，以新换旧，导入覆盖
ADS:应用数据层
个性化维度汇总层，对于不是特别通用的统计维度数据会放在这一层中，这里计算只有自身业务才会关注的维度和指标。
对电商系统各大主题指标分别进行分析。
统计一些uv、pv、ip
PV(访问量)
即Page View，页面浏览量或点击量，用户每次刷新即被计算一次。指某站点总共有被浏览多少个页面，它是重复累计的，同一个页面被重复浏览也被计入PV。
UV(独立访客)
即Unique Visitor，独立访客是指某站点被多少台电脑访问过，以用户电脑的Cookie作为统计依据。
00:00-24:00内相同的客户端只被计算一次。
IP(独立IP)
即Internet Protocol，独立IP是指访问过某站点的IP总数，以用户的IP地址作为统计依据。00:00-24:00内相同IP地址只被计算一次。
使用的组件：Hadoop
数据存储：MySql HDFS HBase
数据计算：Hive Spark Tez
数据查询：Presto Kylin
任务调度：Azkaban
集群监控：Zabbix
元数据管理：Atlas
四、数据可视化
报表系统：是帮助用户用来展现自己输入数据，更多时候是将数据库中的数据，以客户想要的方式展现出来(格式化展示出来)
用户画像：前缀（这个人）
行为标签：近期活跃的应用、近期去过的场景
属性标签：性别、年龄层次、消费水平、职业、喜欢在什么时候买东西…
场景标签：机场、电影院、或者买的什么商品（女装、西服、电脑….）
兴趣标签：购物、教育、影音、游戏、金融…..
定制化标签：就是领导为用户的一些特殊行为制定的标签
推荐系统：推荐系统根据用户行为信息进行推荐，找到用户感兴趣的物品
里面有很多推荐算子
机器学习：从范围上来说，机器学习跟模式识别，统计学习，数据挖掘是类似的，同时，机器学习与其他领域的处理技术的结合，形成了计算机视觉、语音识别、自然语言处理等交叉学科
机器学习是一种能够赋予机器学习的能力以此让它完成直接编程无法完成的功能的方法。但从实践的意义上来说，机器学习是一种通过利用数据，训练出模型，然后使用模型预测的一种方法
机器学习方法是计算机利用已有的数据(经验)，得出了某种模型(迟到的规律)并利用此模型预测未来(是否迟到)的一种方法。
风控系统：风险控制 风险控制是指风险管理者采取各种措施和方法,消灭或减少风险事件发生的各种可能性,或风险控制者减少风险事件发生时造成的损失。
使用的组件：Supersot
扫一扫
1986
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
