电商数据分析-03-电商数据采集

本文涉及的产品
数据管理 DMS,安全协同 3个实例 3个月
推荐场景:
学生管理系统数据库
简介: 电商数据分析-03-电商数据采集

参考

最最最全数据仓库建设指南,速速收藏!!

第1章 数据仓库概念

数据仓库规划

1.1 数仓搭建

我们这里所说的数据仓库,是基于大数据体系的,里面包含标签类目,区别于传统的数据仓库。下面我们来将这张图分解,逐个做简要分析。

一、前期调研

调研是数仓搭建的基础,根据建设目标,我们将调研分为三类:业务调研、业务系统调研、业务数据调研。

业务调研内容:

项目承载的业务是什么,业务的特征和性质

当前的业务流程,有真实流程表格和报告最好,用一个实例的方式来展示整个业务流程

业务专业术语、产品资料、规则算法、逻辑条件等资料

关注用户对流程中存在的问题和痛点描述、以及期望

业务系统调研内容:

清楚了解项目有哪些系统,每个系统对接人,重点系统详细介绍功能和交互

整体系统架构,调用规模,子系统交互方式,并发和吞吐量目标

系统技术选型和系统当前技术难点

数据调研内容:

可提供的数据

数据源类型、环境、数据规模

数据接口方式:文件接口、数据库接口、web service接口等

数据目录,数据字段类型、字典、字段含义、使用场景

数据在业务系统中流向等

二、数据建模

数据建模是数仓搭建的灵魂,是数据存储、组织关系设计的蓝图。

分层架构是对数据进行逻辑上的梳理,按照不同来源、不同使用目的、不同颗粒度等进行区分,使数据使用者在使用数据的时候更方便和容易理解,使数据管理者在管理数据的时候更高效和具有条理。我们推荐的分层架构是:

维度建模是Kimball在《数据仓库工具箱》中所倡导的数据建模方法,也是目前在大数据场景下我们推荐使用的建模方法。因为维度建模以分析决策的需求出发来构建模型,构建的数据模型为分析需求服务,因此它重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能。

维度建模的核心步骤如下:

选择业务过程:对业务生命周期中的活动过程进行分析

声明粒度:选择事实表的数据粒度

维度设计:确定维度字段,确定维度表的信息

事实设计:基于粒度和维度,将业务过程度量

设计原则:

易用性:冗余存储换性能,公共计算下沉,明细汇总并存

高内聚低耦合:核心与扩展分离,业务过程合并,考虑产出时间

数据隔离:业务与数据系统隔离,建设与使用隔离

一致性:业务口径一致,主要实体一致,命名规范一致

中性原则:弱业务属性,数据驱动

三、标签类目

标签,是数据资产的逻辑载体。数据资产,指的是能够给业务带来经济效益的数据。所以,标签类目的建设在整个数据中心的建设过程中具有核心地位。

标签的设计需要结合数据情况和业务需求,因为标签值就是数据字段值,同时标签是要服务于业务的,需要具备业务意义。假如,标签的设计仅基于业务方以往的经验得出,那么最终开发出来的标签值可能会失去标签的使用意义,比如值档次分布不均、有值的覆盖率低等。

基于标签开发方式,我们将标签分为以下三类:

基础标签:直接对应的业务表字段,如性别、城市等

统计标签:标签定义含有常规的统计逻辑,开发时需要通过简易规则进行加工,如年增长率、月平均收益率等

算法标签:标签定义含有复杂的统计逻辑,开发时需要通过算法模型进行加工,如企业信用分、预测年销量等

基于标签应用场景,我们将标签分为以下二类:

后台标签:开发场景下,面向开发人员,不涉及业务场景,聚焦标签设计、开发、管理。

前台标签:应用场景下,面向业务人员,结合业务场景,聚焦对后台标签的直接使用或组合使用。

随着大量的标签产生,为了更好的管理和使用,我们需要将标签进行分类。所有的事物都可以归类于三类对象:人、物、关系,所以我们可以对标签按照人、物、关系来划分一级类目,再按照业务特性对每个一级类目进行二级、三级的拆分,通常我们建议将标签类目划分到三级。

四、开发实施

经过前期调研、数据建模、标签设计之后,接着会进入到开发阶段,开发实施的关键环节由以下几部分组成:

同步汇聚

清洗加工

测试校验

调度配置

发布上线

工欲善其事,必先利其器。一个好的开发工具对开发进度、成本、质量等具有举足轻重的影响。目前市面上很多开源,如Kettle、Azkaban、Hue等多多少少具有部分功能,但是要形成一个从端到端的数据自动化生产,需要将多个开源工具进行组合并通过复杂甚至人工方式进行衔接,整个过程复杂、低效和可靠性低。数栖云一站式离线开发平台,就是为了解决上述问题而生的。

开发落地,规范先行,遵守一套标准规范是整个开发质量和效率的保障。该套数据开发规范应该具备以下几个核心内容:

公共规范

层次调用约定

数据类型规范

数据冗余拆分

空值处理原则

刷新周期标识

增量全量标识

生命周期管理

ODS层模型开发规范

ODS层架构

数据同步及处理规范

数据同步方式

数据清洗规范

命名规范

表命名规范

任务命名规范

DW层模型开发规范

通过工具+规范,促使我们的开发实施快速做好。

五、治理维护

随着调度作业和数据量的增长,管理和维护会成为一项重要任务。

数据管理的范围很大,贯穿数据采集、应用和价值实现等整个生命周期全过程。所谓的数据管理就是通过对数据的生命周期的管理,提高数据资产质量,促进数据在“内增值,外增效”两方面的价值表现。数据管理的核心内容为:

数据标准管理

数据模型管理

元数据管理

主数据管理

数据质量管理

数据安全管理

数据监控是数据质量的保障,会根据数据质量规则制定监控策略,当触发规则时能够自动通知到相关人。基础的数据质量监控维度有以下几部分:

完整性
    特定完整性:必须有值的字段中,不允许为空
    条件完整性:根据条件字段值必须始终存在
唯一性
    特定唯一性:字段必须唯一
    条件唯一性:根据业务条件,字段值必须唯一
有效性
    范围有效性:字段值必须在指定的范围内取值
    日期有效性:字段是日期的时候取值必须是有效的
    形式有效性:字段值必须和指定的格式一致
一致性
    参照一致性:数据或业务具有参照关系的时候,必须保持其一致性
    数据一致性:数据采集、加工或迁移后,前后的数据必须保持一致性
准确性
    逻辑正确性:业务逻辑之间的正确性
    计算正确性:复合指标计算的结果应符合原始数据和计算逻辑的要求
    状态正确性:要维护好数据的产生、收集和更新周期

当出现数据异常后,需要快速的进行恢复。基于异常和修复场景,有以下几种数据运维方式:

平台环境问题引起的异常
    重跑:当环境问题解决后,重新调度作业,对当天的数据进行修复
    重跑下游:当环境问题解决后,重新调度某一个工作流节点的作业及其下游,对当天该作业及其下游的数据进行修复
业务逻辑变更或代码 bug 引起的异常
    补数据:对应作业代码更新并重新发布到生产后,重新生成异常时间段内的该作业数据
    补下游:对应作业代码更新并重新发布到生产后,重新生成异常时间段内的该作业及其下游的数据
其他
    终止:终止正在被执行的作业

数据安全主要是保障数据不被窃取、破坏和滥用,包括核心数据和隐私数据,以及确保数据系统的安全可靠运行。需要构建系统层面、数据层面和服务层面的数据安全框架,从技术保障、管理保障、过程保障和运行保障多维度保障大数据应用和数据安全。

系统层面
    技术架构
    网络传输
    租户隔离
    权限管理
数据层面
    数据评估:对数据来源、用途、合法性等进行评估
    数据脱敏:对隐私数据进行脱敏处理
    数据权限:根据数据使用者的不同角色和需求,开放不同权限
    血缘追溯:建立数据血缘关系,可追溯数据生产的来龙去脉
    下载限制:限制数据结果集的下载条数,防止数据外泄
服务层面
    应用监控:监控数据使用端、使用次数、使用流量等
    接口管理:生产和管理数据输出接口
    数据脱敏
六、数据应用

给业务赋能,是数据价值的最终体现,也就是我们讲的数据业务化。数据业务化的方向有两种:业务优化和业务创新。在数据业务化的过程中,为了更方便的服务于上层应用,我们先将数据形成服务接口,然后让业务应用直接调用服务接口,即形成 数据服务化+服务业务化。

如何通过已有的 产品 + 方法论 + 最佳实践 去完成一个业务优化和业务创新呢?这里有一张完整的图,帮助你更快的理解全过程。

项目需求及架构设计

2.1 项目需求分析

1)项目需求

    (1)用户行为数据采集平台搭建

    (2)业务数据采集平台搭建

    (3)数据仓库维度建模

    (4)分析,设备、会员、商品、地区、活动等电商核心主题,统计的报表指标近100个,完全对比中型公司

    (5)采用即席查询工具,随时进行指标分析

    (6)对集群性能进行监控,发生异常需要报警

    (7)元数据管理

    (8)质量监控

2)思考

    (1)项目技术如何选型

    (2)框架版本如何选型(Apache、CDH、HDP)

    (3)服务器使用物理机还是云主机

    (4)如何确认集群规模(假设每台服务器8T硬盘)

2.2 项目框架

2.2.1 技术选型

技术选型主要考虑因素:数据量大小、业务需求、行业内经验、技术成熟度、开发维护成本、总成本预算

  1)数据采集传输:Flume,Kafka,Sqoop,Logstash,DataX

  2)数据存储:Mysql,HDFS,HBase,Redis,MongoDB

  3)数据计算:Hive,Tez,Spark,Flink,Storm

  4)数据查询:Presto,Kylin,Impala,Druid

  5)数据可视化:Echarts,Superset,QuickBI,DataV

  6)任务调度:Azkaban、Oozie

  7)集群监控:Zabbix

  8)元数据管理:Atlas

2.2.2 系统数据流程设计

2.2.3 框架版本选型

如何选择Apache/CDH/HDP版本?

(1)Apache:运维麻烦,组件间兼容性需要自己调研。(一般大厂使用,技术实力雄厚,有专业的运维人员)

(2)CDH:国内使用最多的版本,但CM不开源,今年开始要收费,一个节点1万美金

(3)HDP:开源,开源进行二次开发,但是没有CDH稳定,国内使用较少,目前被CDH收购

2.2.4 服务器选型

服务器选择物理机还是云主机

1)物理机:

(1)128G内存,20核物理CPU,40线程,8THDD核2TSSD硬盘,戴尔品牌,单台报价4W出头,一般寿命在5年左右

(2)需要专业的运维人员,平均每月1W,电费、网络、散热、机房等等开销

2)云主机

(1)以阿里云为例,差不多相同配置,每年5W

(2)很多运维工作由阿里云完成,运维相对轻松

3)企业选择

(1)金融有钱公司和阿里没有直接冲突的公司选择阿里云

(2)中小公司、为了融资上市,选择阿里云,拉到融资后再购买物理机

(3)有长期打算,资金比较足,选择物理机

2.2.5 集群资源规划设计

1)如何确定集群规模?(假设每台服务器8T磁盘,128G内存)

(1)每天日活跃用户100万,每人一天平均100条:100万 * 100条 = 1亿条

(2)每条日志1k左右,每天1亿条:100000000 / 1024 / 1024 = 100G(1G=1024MB,1MB=1024KB)

(3)半年内不扩容服务器来算:100G * 180天 = 18T (1T=1024G)

(4)保存3个副本:18T * 3 = 54T

(5)预留20%~30%Buf :54T / 0.7 = 77T

(6)服务器数量:77 / 8 = 10台(每台8个T)

2)若考虑数仓分层,数据采用压缩,则需要重新进行计算

3)测试集群服务器规划

数据生成模块

3.1 目标数据

我们要收集和分析的数据主要包括页面数据、事件数据、曝光数据、启动数据和错误数据。

3.1.1 页面

页面数据主要记录一个页面的用户访问情况,包括访问时间、停留时间、页面路径等信息。

  

1)所有页面id如下

home(“首页”),

category(“分类页”),

discovery(“发现页”),

top_n(“热门排行”),

favor(“收藏页”),

search(“搜索页”),

good_list(“商品列表页”),

good_detail(“商品详情”),

good_spec(“商品规格”),

comment(“评价”),

comment_done(“评价完成”),

comment_list(“评价列表”),

cart(“购物车”),

trade(“下单结算”),

payment(“支付页面”),

payment_done(“支付完成”),

orders_all(“全部订单”),

orders_unpaid(“订单待支付”),

orders_undelivered(“订单待发货”),

orders_unreceipted(“订单待收货”),

orders_wait_comment(“订单待评价”),

mine(“我的”),

activity(“活动”),

login(“登录”),

register(“注册”);

2)所有页面对象类型如下:

sku_id(“商品skuId”),

keyword(“搜索关键词”),

sku_ids(“多个商品skuId”),

activity_id(“活动id”),

coupon_id(“购物券id”);

3)所有来源类型如下:

promotion(“商品推广”),

recommend(“算法推荐商品”),

query(“查询结果商品”),

activity(“促销活动”);

3.1.2 事件

事件数据主要记录应用内一个具体操作行为,包括操作类型、操作对象、操作对象描述等信息。

1)所有动作类型如下:

favor_add(“添加收藏”),

favor_canel(“取消收藏”),

cart_add(“添加购物车”),

cart_remove(“删除购物车”),

cart_add_num(“增加购物车商品数量”),

cart_minus_num(“减少购物车商品数量”),

trade_add_address(“增加收货地址”),

get_coupon(“领取优惠券”);

注:对于下单、支付等业务数据,可从业务数据库获取。

2)所有动作目标类型如下:

sku_id(“商品”),

coupon_id(“购物券”);

3.1.3 曝光

曝光数据主要记录页面所曝光的内容,包括曝光对象,曝光类型等信息。

1)所有曝光类型如下:

promotion(“商品推广”),

recommend(“算法推荐商品”),

query(“查询结果商品”),

activity(“促销活动”);

2)所有曝光对象类型如下:

sku_id(“商品skuId”),

activity_id(“活动id”);

3.1.4 启动

启动数据记录应用的启动信息。

image.png

1)所有启动入口类型如下:

icon(“图标”),

notification(“通知”),

install(“安装后启动”);

3.1.5 错误

错误数据记录应用使用过程中的错误信息,包括错误编号及错误信息。

3.2数据埋点

3.2.1 主流埋点方式(了解)

目前主流的埋点方式,有代码埋点(前端/后端)、可视化埋点、全埋点三种。

代码埋点

代码埋点是通过调用埋点SDK函数,在需要埋点的业务逻辑功能位置调用接口,上报埋点数据。例如,我们对页面中的某个按钮埋点后,当这个按钮被点击时,可以在这个按钮对应的 OnClick 函数里面调用SDK提供的数据发送接口,来发送数据。

可视化埋点:

可视化埋点只需要研发人员集成采集 SDK,不需要写埋点代码,业务人员就可以通过访问分析平台的“圈选”功能,来“圈”出需要对用户行为进行捕捉的控件,并对该事件进行命名。圈选完毕后,这些配置会同步到各个用户的终端上,由采集 SDK 按照圈选的配置自动进行用户行为数据的采集和发送。

全埋点:

全埋点是通过在产品中嵌入SDK,前端自动采集页面上的全部用户行为事件,上报埋点数据,相当于做了一个统一的埋点。然后再通过界面配置哪些数据需要在系统里面进行分析。

3.2.2 埋点数据日志结构

们的日志结构大致可分为两类,一是普通页面埋点日志,二是启动日志。

普通页面日志结构如下,每条日志包含了,当前页面的页面信息,所有事件(动作)、所有曝光信息以及错误信息。除此之外,还包含了一系列公共信息,包括设备信息,地理位置,应用信息等,即下边的common字段。

1)普通页面埋点日志格式

{
  "common": {                  -- 公共信息
    "ar": "230000",              -- 地区编码
    "ba": "iPhone",              -- 手机品牌
    "ch": "Appstore",            -- 渠道
    "is_new": "1",--是否首日使用,首次使用的当日,该字段值为1,过了24:00,该字段置为0。
    "md": "iPhone 8",            -- 手机型号
    "mid": "YXfhjAYH6As2z9Iq", -- 设备id
    "os": "iOS 13.2.9",          -- 操作系统
    "uid": "485",                 -- 会员id
    "vc": "v2.1.134"             -- app版本号
  },
"actions": [                     --动作(事件)  
    {
      "action_id": "favor_add",   --动作id
      "item": "3",                   --目标id
      "item_type": "sku_id",       --目标类型
      "ts": 1585744376605           --动作时间戳
    }
  ],
  "displays": [
    {
      "displayType": "query",        -- 曝光类型
      "item": "3",                     -- 曝光对象id
      "item_type": "sku_id",         -- 曝光对象类型
      "order": 1,                      --出现顺序
      "pos_id": 2                      --曝光位置
    },
    {
      "displayType": "promotion",
      "item": "6",
      "item_type": "sku_id",
      "order": 2, 
      "pos_id": 1
    },
    {
      "displayType": "promotion",
      "item": "9",
      "item_type": "sku_id",
      "order": 3, 
      "pos_id": 3
    },
    {
      "displayType": "recommend",
      "item": "6",
      "item_type": "sku_id",
      "order": 4, 
      "pos_id": 2
    },
    {
      "displayType": "query ",
      "item": "6",
      "item_type": "sku_id",
      "order": 5, 
      "pos_id": 1
    }
  ],
  "page": {                       --页面信息
    "during_time": 7648,        -- 持续时间毫秒
    "item": "3",                  -- 目标id
    "item_type": "sku_id",      -- 目标类型
    "last_page_id": "login",    -- 上页类型
    "page_id": "good_detail",   -- 页面ID
    "sourceType": "promotion"   -- 来源类型
  },
"err":{                     --错误
"error_code": "1234",      --错误码
    "msg": "***********"       --错误信息
},
  "ts": 1585744374423  --跳入时间戳
}

2)启动日志格式(启动日志结构相对简单,主要包含公共信息,启动信息和错误信息)

{
  "common": {
    "ar": "370000",
    "ba": "Honor",
    "ch": "wandoujia",
    "is_new": "1",
    "md": "Honor 20s",
    "mid": "eQF5boERMJFOujcp",
    "os": "Android 11.0",
    "uid": "76",
    "vc": "v2.1.134"
  },
  "start": {   
    "entry": "icon",         --icon手机图标  notice 通知   install 安装后启动
    "loading_time": 18803,  --启动加载时间
    "open_ad_id": 7,        --广告页ID
    "open_ad_ms": 3449,    -- 广告总共播放时间
    "open_ad_skip_ms": 1989   --  用户跳过广告时点
  },
"err":{                     --错误
"error_code": "1234",      --错误码
    "msg": "***********"       --错误信息
},
  "ts": 1585744304000
}
3.2.3 埋点数据上报时机

埋点数据上报时机包括两种方式。

方式一,在离开该页面时,上传在这个页面产生的所有数据(页面、事件、曝光、错误等)。优点,批处理,减少了服务器接收数据压力。缺点,不是特别及时。

方式二,每个事件、动作、错误等,产生后,立即发送。优点,响应及时。缺点,对服务器接收数据压力比较大。

数据采集模块

相关实践学习
数据库实验室挑战任务-初级任务
本场景介绍如何开通属于你的免费云数据库,在RDS-MySQL中完成对学生成绩的详情查询,执行指定类型SQL。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
3月前
|
存储 大数据 数据库
电商数据分析-02-电商业务介绍及表结构
电商数据分析-02-电商业务介绍及表结构
|
4月前
|
SQL 分布式计算 数据可视化
Spark SQL案例【电商购买数据分析】
Spark SQL案例【电商购买数据分析】
|
2月前
|
数据采集 数据挖掘 API
主流电商平台数据采集API接口|【Python爬虫+数据分析】采集电商平台数据信息采集
随着电商平台的兴起,越来越多的人开始在网上购物。而对于电商平台来说,商品信息、价格、评论等数据是非常重要的。因此,抓取电商平台的商品信息、价格、评论等数据成为了一项非常有价值的工作。本文将介绍如何使用Python编写爬虫程序,抓取电商平台的商品信息、价格、评论等数据。 当然,如果是电商企业,跨境电商企业,ERP系统搭建,我们经常需要采集的平台多,数据量大,要求数据稳定供应,有并发需求,那就需要通过接入电商API数据采集接口,封装好的数据采集接口更方便稳定高效数据采集。
|
1天前
|
供应链 搜索推荐 数据挖掘
Pandas实战案例:电商数据分析的实践与挑战
【4月更文挑战第16天】本文通过一个电商数据分析案例展示了Pandas在处理销售数据、用户行为分析及商品销售趋势预测中的应用。在数据准备与清洗阶段,Pandas用于处理缺失值、重复值。接着,通过用户购买行为和商品销售趋势分析,构建用户画像并预测销售趋势。实践中遇到的大数据量和数据多样性挑战,通过分布式计算和数据标准化解决。未来将继续深入研究Pandas与其他先进技术的结合,提升决策支持能力。
|
3月前
|
供应链 UED
电商数据分析-01-电商数据分析指标
电商数据分析-01-电商数据分析指标
|
5月前
|
数据采集 分布式计算 数据挖掘
80 网站点击流数据分析案例(数据采集功能)
80 网站点击流数据分析案例(数据采集功能)
24 0
|
机器学习/深度学习 数据采集 数据可视化
数据分析案例-基于随机森林模型探究电商网站推销商品的影响因素
数据分析案例-基于随机森林模型探究电商网站推销商品的影响因素
673 0
数据分析案例-基于随机森林模型探究电商网站推销商品的影响因素
|
监控 搜索推荐 算法
电商数据分析常用业务指标整理(共72个)
电商数据分析常用业务指标整理(共72个)
|
存储 Cloud Native 数据可视化
体验有奖 | 3步玩转云原生数仓AnalyticDB MySQL电商行业数据分析场景
本活动提供AnalyticDB MySQL和数据管理DMS环境,通过一个模拟的电商行业数据分析场景,完成创建数据仓库、开启ETL任务和数据可视化报表开发3个实验步骤,体验一次完整的数据仓库开发过程,完成体验的用户即有机会获得精美礼品一份!
389 0
体验有奖 | 3步玩转云原生数仓AnalyticDB MySQL电商行业数据分析场景
|
SQL 分布式计算 大数据
【转载】阿里云MVP Meetup 《云数据·大计算:海量日志数据分析与应用》之《数据采集:日志数据上传》篇
本手册为阿里云MVP Meetup Workshop《云计算·大数据:海量日志数据分析与应用》的《数据采集:日志数据上传》篇而准备。主要为保障各位学员在workshop当天能够顺畅进行动手实操,那么本节为学员掌握阿里云数据采集的操作和使用。
2799 0