阳江网站建设推广公司电话,中国电子商务公司排名,电子商务网站建设的难点,xyz域名做网站好么参考
最最最全数据仓库建设指南#xff0c;速速收藏#xff01;#xff01; 第1章 数据仓库概念
数据仓库规划 1.1 数仓搭建 我们这里所说的数据仓库#xff0c;是基于大数据体系的#xff0c;里面包含标签类目#xff0c;区别于传统的数据仓库。下面我们来将这张图分解…参考
最最最全数据仓库建设指南速速收藏 第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数据采集传输FlumeKafkaSqoopLogstashDataX 2数据存储MysqlHDFSHBaseRedisMongoDB 3数据计算HiveTezSparkFlinkStorm 4数据查询PrestoKylinImpalaDruid 5数据可视化EchartsSupersetQuickBIDataV 6任务调度Azkaban、Oozie 7集群监控Zabbix 8元数据管理Atlas
2.2.2 系统数据流程设计 2.2.3 框架版本选型
如何选择Apache/CDH/HDP版本 1Apache运维麻烦组件间兼容性需要自己调研。一般大厂使用技术实力雄厚有专业的运维人员 2CDH国内使用最多的版本但CM不开源今年开始要收费一个节点1万美金 3HDP开源开源进行二次开发但是没有CDH稳定国内使用较少目前被CDH收购 2.2.4 服务器选型
服务器选择物理机还是云主机 1物理机 1128G内存20核物理CPU40线程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 100G1G1024MB1MB1024KB 3半年内不扩容服务器来算100G * 180天 18T 1T1024G 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 启动 启动数据记录应用的启动信息。 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, -- 设备idos: iOS 13.2.9, -- 操作系统uid: 485, -- 会员idvc: v2.1.134 -- app版本号},
actions: [ --动作(事件) {action_id: favor_add, --动作iditem: 3, --目标iditem_type: sku_id, --目标类型ts: 1585744376605 --动作时间戳}],displays: [{displayType: query, -- 曝光类型item: 3, -- 曝光对象iditem_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, -- 目标iditem_type: sku_id, -- 目标类型last_page_id: login, -- 上页类型page_id: good_detail, -- 页面IDsourceType: 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, --广告页IDopen_ad_ms: 3449, -- 广告总共播放时间open_ad_skip_ms: 1989 -- 用户跳过广告时点},
err:{ --错误
error_code: 1234, --错误码msg: *********** --错误信息
},ts: 1585744304000
}3.2.3 埋点数据上报时机
埋点数据上报时机包括两种方式。 方式一在离开该页面时上传在这个页面产生的所有数据页面、事件、曝光、错误等。优点批处理减少了服务器接收数据压力。缺点不是特别及时。 方式二每个事件、动作、错误等产生后立即发送。优点响应及时。缺点对服务器接收数据压力比较大。 数据采集模块
