精华内容
下载资源
问答
  • 大数据产品设计案例

    2018-10-28 23:07:53
    大数据产品架构及其在教育、医疗、交通、政府等各行业的解决方案进行了讲解。
  • 很多人都看过不同类型的书,也接触过很多有关大数据方面的文章,但都是很零散不成系统,对自己也没有起到多大的作用,所以作者第一时间,带大家从整体体系思路上,了解大数据产品设计架构和技术策略。...

    如何做好大数据产品设计架构和技术策略?

    作者经过研发多个大数据产品,将自己形成关于大数据知识体系的干货分享出来,希望给大家能够快速建立起大数据产品的体系思路,让大家系统性学习和了解有关大数据的设计架构。

    很多人都看过不同类型的书,也接触过很多有关大数据方面的文章,但都是很零散不成系统,对自己也没有起到多大的作用,所以作者第一时间,带大家从整体体系思路上,了解大数据产品设计架构和技术策略。

    大数据产品,从系统性和体系思路上来做,主要分为五步:

    针对前端不同渠道进行数据埋点,然后根据不同渠道的采集多维数据,也就是做大数据的第一步,没有全量数据,何谈大数据分析;

    第二步,基于采集回来的多维度数据,采用ETL对其各类数据进行结构化处理及加载;

    然后第三步,对于ETL处理后的标准化结构数据,建立数据存储管理子系统,归集到底层数据仓库,这一步很关键,基于数据仓库,对其内部数据分解成基础的同类数据集市;

    然后基于归集分解的不同数据集市,利用各类R函数包对其数据集进行数据建模和各类算法设计,里面算法是需要自己设计,个别算法可以用R函数,这个过程产品和运营参与最多;这一步做好了,也是很多公司用户画像系统的底层。

    最后根据建立的各类数据模型及算法,结合前端不同渠道不同业务特征,根据渠道触点自动匹配后端模型自动展现用户个性化产品和服务。

    建立系统性数据采集指标体系

    建立数据采集分析指标体系是形成营销数据集市的基础,也是营销数据集市覆盖用户行为数据广度和深度的前提,数据采集分析体系要包含用户全活动行为触点数据,用户结构化相关数据及非结构化相关数据,根据数据分析指标体系才能归类汇总形成筛选用户条件的属性和属性值,也是发现新的营销事件的基础。

    构建营销数据指标分析模型,完善升级数据指标采集,依托用户全流程行为触点,建立用户行为消费特征和个体属性,从用户行为分析、商业经营数据分析、营销数据分析三个维度,形成用户行为特征分析模型。用户维度数据指标是不同维度分析要素与用户全生命周期轨迹各触点的二维交叉得出。

    目前做大数据平台的公司,大多数采集的数据指标和输出的可视化报表,都存在几个关键问题:

    • 采集的数据都是以渠道、日期、地区统计,无法定位到具体每个用户;
    • 计算统计出的数据都是规模数据,针对规模数据进行挖掘分析,无法支持;
    • 数据无法支撑系统做用户获客、留存、营销推送使用;

    所以,要使系统采集的数据指标能够支持平台前端的个性化行为分析,必须围绕用户为主线来进行画像设计,在初期可视化报表成果基础上,将统计出来的不同规模数据,细分定位到每个用户,使每个数据都有一个用户归属。

    将分散无序的统计数据,在依据用户来衔接起来,在现有产品界面上,每个统计数据都增加一个标签,点击标签,可以展示对应每个用户的行为数据,同时可以链接到其他统计数据页面。

    由此可以推导出,以用户为主线来建立数据采集指标维度:用户身份信息、用户社会生活信息、用户资产信息、用户行为偏好信息、用户购物偏好、用户价值、用户反馈、用户忠诚度等多个维度,依据建立的采集数据维度,可以细分到数据指标或数据属性项。

    ① 用户身份信息维度

    性别,年龄,星座,居住城市,活跃区域,证件信息,学历,收入,健康等。

    ② 用户社会生活信息维度

    行业,职业,是否有孩子,孩子年龄,车辆,住房性质,通信情况,流量使用情况……

    ③ 用户行为偏好信息

    是否有网购行为,风险敏感度,价格敏感度,品牌敏感度,收益敏感度,产品偏好,渠道偏好……

    ④ 用户购物偏好信息

    品类偏好,产品偏好,购物频次,浏览偏好,营销广告喜好,购物时间偏好,单次购物最高金额……

    ⑤ 用户反馈信息维度

    用户参与的活动,参与的讨论,收藏的产品,购买过的商品,推荐过的产品,评论过的产品……

    基于采集回来的多维度数据,采用ETL对其各类数据进行结构化处理及加载

    数据补缺:对空数据、缺失数据进行数据补缺操作,无法处理的做标记。

    数据替换:对无效数据进行数据的替换。

    格式规范化:将源数据抽取的数据格式转换成为便于进入仓库处理的目标数据格式。

    主外键约束:通过建立主外键约束,对非法数据进行数据替换或导出到错误文件重新处理。

    数据合并:多用表关联实现(每个字段加索引,保证关联查询的效率)

    数据拆分:按一定规则进行数据拆分

    行列互换、排序/修改序号、去除重复记录

    数据处理层 由 hadoop集群 组成 , Hadoop集群从数据采集源读取业务数据,通过并行计算完成业务数据的处理逻辑,将数据筛选归并形成目标数据。

    数据建模、用户画像及特征算法

    提取与营销相关的客户、产品、服务数据,采用聚类分析和关联分析方法搭建数据模型,通过用户规则属性配置、规则模板配置、用户画像打标签,形成用户数据规则集,利用规则引擎实现营销推送和条件触发的实时营销推送,同步到前端渠道交互平台来执行营销规则,并将营销执行效果信息实时返回到大数据系统。

    根据前端用户不同个性化行为,自动匹配规则并触发推送内容

    根据用户全流程活动行为轨迹,分析用户与线上渠道与线下渠道接触的所有行为触点,对营销用户打标签,形成用户行为画像,基于用户画像提炼汇总营销筛选规则属性及属性值,最终形成细分用户群体的条件。每个用户属性对应多个不同属性值,属性值可根据不同活动个性化进行配置,支持用户黑白名单的管理功能。

    可以预先配置好基于不同用户身份特性的活动规则和模型,当前端用户来触发配置好的营销事件,数据系统根据匹配度最高的原则来实时自动推送营销规则,并通过实时推送功能来配置推送的活动内容、优惠信息和产品信息等,同时汇总前端反馈回的效果数据,对推送规则和内容进行优化调整。

    大数据系统结合客户营销系统在现有用户画像、用户属性打标签、客户和营销规则配置推送、同类型用户特性归集分库模型基础上,未来将逐步扩展机器深度学习功能,通过系统自动搜集分析前端用户实时变化数据,依据建设的机器深度学习函数模型,自动计算匹配用户需求的函数参数和对应规则,营销系统根据计算出的规则模型,实时自动推送高度匹配的营销活动和内容信息。

    机器自学习模型算法是未来大数据系统深度学习的核心,通过系统大量采样训练,多次数据验证和参数调整,才能最终确定相对精准的函数因子和参数值,从而可以根据前端用户产生的实时行为数据,系统可自动计算对应的营销规则和推荐模型。

    大数据系统在深度自学习外,未来将通过逐步开放合作理念,对接外部第三方平台,扩展客户数据范围和行为触点,尽可能覆盖用户线上线下全生命周期行为轨迹,掌握用户各行为触点数据,扩大客户数据集市和事件库,才能深层次挖掘客户全方位需求,结合机器自学习功能,从根本上提升产品销售能力和客户全方位体验感知。


    本文作者:刘永平

    来源:51CTO

    展开全文
  • 大数据应用型产品设计方法 及行业案例 目录 第一节 认识大数据 第二节 大数据产品生态链 第三节 大数据应用产品规划设计方法 第四节 电力行业大数据产品案例 第一节 认识大数据 大数据的定义及特点 大数据价值体现 ...
  • EDITED BY CHENYU * 移动互联网产品设计 移动互联网产品设计课程 Mobile Internet Product Design 主讲教师 陈煜 移动通信技术专业教学资源库 深圳信息职业技术学院电子与通信学院 大数据技术的概述 目录 01 大数据...
  • 大数据应用型产品设计方法及行业案例介绍大数据应用型产品设计方法及行业案例介绍大数据应用型产品设计方法及行业案例介绍大数据应用型产品设计方法及行业案例介绍大数据应用型产品设计方法及行业案例介绍大数据应用...
  • 常见的大数据平台架构设计思路

    千次阅读 2020-02-16 21:17:15
    近年来,随着IT技术与大数据、机器学习、算法方向的不断发展,越来越多的企业都意识到了数据存在的价值,将数据作为自身宝贵的资产进行管理,利用大数据和机器学习能力去挖掘、识别、利用数据资产。...

    近年来,随着IT技术与大数据、机器学习、算法方向的不断发展,越来越多的企业都意识到了数据存在的价值,将数据作为自身宝贵的资产进行管理,利用大数据和机器学习能力去挖掘、识别、利用数据资产。如果缺乏有效的数据整体架构设计或者部分能力缺失,会导致业务层难以直接利用大数据大数据,大数据和业务产生了巨大的鸿沟,这道鸿沟的出现导致企业在使用大数据的过程中出现数据不可知、需求难实现、数据难共享等一系列问题,本文介绍了一些数据平台设计思路来帮助业务减少数据开发中的痛点和难点。

    本文主要包括以下几个章节:

    1. 本文第一部分介绍一下大数据基础组件和相关知识。

    2. 第二部分会介绍lambda架构和kappa架构。

    3. 第三部分会介绍lambda和kappa架构模式下的一般大数据架构

    4. 第四部分介绍裸露的数据架构体系下数据端到端难点以及痛点。

    5. 第五部分介绍优秀的大数据架构整体设计

    6. 从第五部分以后都是在介绍通过各种数据平台和组件将这些大数据组件结合起来打造一套高效、易用的数据平台来提高业务系统效能,让业务开发不在畏惧复杂的数据开发组件,无需关注底层实现,只需要会使用SQL就可以完成一站式开发,完成数据回流,让大数据不再是数据工程师才有的技能。

    一、大数据技术栈

    大数据整体流程涉及很多模块,每一个模块都比较复杂,下图列出这些模块和组件以及他们的功能特性,后续会有专题去详细介绍相关模块领域知识,例如数据采集、数据传输、实时计算、离线计算、大数据储存等相关模块。

    二、lambda架构和kappa架构

    目前基本上所有的大数据架构都是基于lambda和kappa架构,不同公司在这两个架构模式上设计出符合该公司的数据体系架构。lambda 架构使开发人员能够构建大规模分布式数据处理系统。它具有很好的灵活性和可扩展性,也对硬件故障和人为失误有很好的容错性,关于lambda架构可以在网上搜到很多相关文章。而kappa架构解决了lambda架构存在的两套数据加工体系,从而带来的各种成本问题,这也是目前流批一体化研究方向,很多企业已经开始使用这种更为先进的架构。

    Lambda架构

    Kappa架构

    三、kappa架构和lambda架构下的大数据架构

    目前各大公司基本上都是使用kappa架构或者lambda架构模式,这两种模式下大数据整体架构在早期发展阶段可能是下面这样的:

    四、数据端到端痛点

    虽然上述架构看起来将多种大数据组件串联起来实行了一体化管理,但是接触过数据开发的人会感受比较强烈,这样的裸露架构业务数据开发需要关注很多基础工具的使用,实际数据开发中存在很多痛点与难点,具体表现在下面一些方面。

    1. 缺乏一套数据开发IDE来管理整个数据开发环节,长远的流程无法管理起来。

    2. 没有产生标准数据建模体系,导致不同数据工程师对指标理解不同计算口径有误。

    3. 大数据组件开发要求高,普通业务去直接使用Hbase、ES等技术组件会产生各种问题。

    4. 基本上每个公司大数据团队都会很复杂,涉及到很多环节,遇到问题难以定位难以找到对应负责人。

    5. 难以打破数据孤岛,跨团队跨部门数据难以共享,互相不清楚对方有什么数据。

    6. 需要维护两套计算模型批计算和流计算,难以上手开发,需要提供一套流批统一的SQL。

    7. 缺乏公司层面的元数据体系规划,同一条数据实时和离线难以复用计算,每次开发任务都要各种梳理。

    基本上大多数公司在数据平台治理上和提供开放能力上都存在上述问题和痛点。在复杂的数据架构下,对于数据适用方来说,每一个环节的不清晰或者一个功能的不友好,都会让复杂链路变更更加复杂起来。想要解决这些痛点,就需要精心打磨每一个环节,将上面技术组件无缝衔接起来,让业务从端到端使用数据就像写SQL查询数据库一样简单。

    五、优秀的大数据整体架构设计

    提供多种平台以及工具来助力数据平台:多种数据源的数据采集平台、一键数据同步平台、数据质量和建模平台、元数据体系、数据统一访问平台、实时和离线计算平台、资源调度平台、一站式开发IDE。

    六、元数据-大数据体系基石

    元数据是打通数据源、数据仓库、数据应用,记录了数据从产生到消费的完整链路。元数据包含静态的表、列、分区信息(也就是MetaStore)。动态的任务、表依赖映射关系;数据仓库的模型定义、数据生命周期;以及ETL任务调度信息、输入输出等元数据是数据管理、数据内容、数据应用的基础。例如可以利用元数据构建任务、表、列、用户之间的数据图谱;构建任务DAG依赖关系,编排任务执行序列;构建任务画像,进行任务质量治理;提供个人或BU的资产管理、计算资源消耗概览等。

    可以认为整个大数据数据流动都是依靠元数据来管理的,没有一套完整的元数据设计,就会出现上面的数据难以追踪、权限难以把控、资源难以管理、数据难以共享等等问题。

    很多公司都是依靠hive来管理元数据,但是个人认为在发展一定阶段还是需要自己去建设元数据平台来匹配相关的架构。

    关于元数据可以参考饿了么一些实战:

    https://www.jianshu.com/p/f60b2111e414

    七、流批一体化计算

    如果维护两套计算引擎例如离线计算Spark和实时计算Flink,那么会对使用者造成极大困扰,既需要学习流计算知识也需要批计算领域知识。如果实时用Flink离线用Spark或者Hadoop,可以开发一套自定义的DSL描述语言去匹配不同计算引擎语法,上层使用者无需关注底层具体的执行细节,只需要掌握一门DSL语言,就可以完成Spark和Hadoop以及Flink等等计算引擎的接入。

    八、实时与离线ETL平台

    ETL 即 Extract-Transform-Load,用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程。ETL 一词较常用在数据仓库,但其对象并不限于数据仓库。一般而言ETL平台在数据清洗、数据格式转换、数据补全、数据质量管理等方面有很重要作用。作为重要的数据清洗中间层,一般而言ETL最起码要具备下面几个功能:

    1. 支持多种数据源,例如消息系统、文件系统等

    2. 支持多种算子,过滤、分割、转换、输出、查询数据源补全等算子能力

    3. 支持动态变更逻辑,例如上述算子通过动态jar方式提交可以做到不停服发布变更。

    九、智能统一查询平台

    大多数数据查询都是由需求驱动,一个需求开发一个或者几个接口,编写接口文档,开放给业务方调用,这种模式在大数据体系下存在很多问题:

    1. 这种架构简单,但接口粒度很粗,灵活性不高,扩展性差,复用率低.随着业务需求的增加,接口的数量大幅增加,维护成本高企。

    2. 同时,开发效率不高,这对于海量的数据体系显然会造成大量重复开发,难以做到数据和逻辑复用,严重降低业务适用方体验。

    3. 如果没有统一的查询平台直接将Hbase等库暴露给业务,后续的数据权限运维管理也会比较难,接入大数据组件对于业务适用方同样很痛苦,稍有不慎就会出现各种问题。

    通过一套智能查询解决上述大数据查询痛点问题

    十、数仓建模规范体系

    随着业务复杂度和数据规模上升,混乱的数据调用和拷贝,重复建设带来的资源浪费,数据指标定义不同而带来的歧义、数据使用门槛越来越高。以笔者见证实际业务埋点和数仓使用为例,同一个商品名称有些表字段是good_id,有些叫spu_id,还有很多其他命名,对于想利用这些数据人会造成极大困扰。因此没有一套完整的大数据建模体系,会给数据治理带来极大困难,具体表现在下面几个方面:

    1. 数据标准不一致,即使是同样的命名,但定义口径却不一致。例如,仅uv这样一个指标,就有十几种定义。带来的问题是:都是uv,我要用哪个?都是uv,为什么数据却不一样?

    2. 造成巨大研发成本,每个工程师都需要从头到尾了解研发流程的每个细节,对同样的“坑”每个人都会重新踩一遍,对研发人员的时间和精力成本造成浪费。这也是目标笔者遇到的困扰,想去实际开发提取数据太难。

    3. 没有统一的规范标准管理,造成了重复计算等资源浪费。而数据表的层次、粒度不清晰,也使得重复存储严重。

    因此大数据开发和数仓表设计必须要坚持设计原则,数据平台可以开发平台来约束不合理的设计,例如阿里巴巴的OneData体。一般而言,数据开发要经过按照下面的指导方针进行:

    有兴趣的可以参考阿里巴巴的OneData设计体系。

    十一、一键集成平台

    很简单的就能将各种各式数据一键采集到数据平台,通过数据传输平台将数据无缝衔接到ETL平台。ETL通过和元数据平台打通,规范Schema定义,然后将数据转换、分流流入到实时与离线计算平台,后续任何针对该数据离线和实时处理,只需要申请元数据表权限就可以开发任务完成计算。数据采集支持多种各式数据来源,例如binlog、日志采集、前端埋点、kafka消息队列等

    十二、数据开发IDE-高效的端到端工具

    高效的数据开发一站式解决工具,通过IDE可以完成实时计算与离线计算任务开发,将上述平台全部打通提供一站式解决方案。数据开发IDE提供数据集成、数据开发、数据管理、数据质量和数据服务等全方位的产品服务,一站式开发管理的界面,通过数据IDE完成对数据进行传输、转换和集成等操作。从不同的数据存储引入数据,并进行转化和开发,最后将处理好的数据同步至其他数据系统。通过高效率的大数据开发IDE,基本上让大数据工程师可以屏蔽掉各种痛点,将上述多种平台能力结合起来,让大数据开发可以向写SQL一样简单。

    关于数据开发工具可以参考阿里云的DataWorks。

    解决端到端难点还需要其他若干能力辅助,这里就不再叙述,有兴趣的同学可以自行研究。

    十三、其他

    完整的数据体系研发还包括告警与监控中心、资源调度中心、资源计算隔离、数据质量检测、一站式数据加工体系,这里就不再继续讨论了。

    猜你喜欢

    1、60TB 数据量的作业从 Hive 迁移到 Spark 在 Facebook 的实践

    2、Apache Hadoop 3.x 最新状态以及升级指南

    3、爱奇艺大数据实时分析平台的建设与实践

    4、Apache Kylin 在一点资讯的实践

    过往记忆大数据微信群,请添加微信:fangzhen0219,备注【进群】

    展开全文
  • 智慧方案
  • 大数据可视化平台产品设计方案
  • 大数据可视化产品设计方案详解,对大数据产品架构及其在教育、医疗、交通、政府等各行业的解决方案进行了讲解。
  • 大数据应用产品规划设计方法及应用
  • 而我们如果想要去测试这样的产品就要对分布式计算的原理有个清晰的认知并且也要熟悉分布式计算框架的使用来针对各种ETL场景设计不同的测试数据。 而一般来说我们需要从以下两个角度来进行测试。ETL能兼容各种不同的...
  • 大数据产品介绍

    千次阅读 2019-06-17 09:48:56
    大数据时代下的大数据产品多样复杂,本文主要将大数据背景下的产品做个简单的介绍。

    elasticsearch
    elasticsearch 简称ES : 分布式可扩展去中心化的实时搜索和分析引擎
    去中心化:即无主节点,对外部来说,无论你访问的是哪个节点,都是和整个集群在互信。它的主节点是可以通过选举产生的。
    特点:分布式实时文件存储,并将每一个字段都编入索引,使其可以被搜索;可以扩展到上百台服务器,处理PB级别的结构化或非结构化数据。
    存储:Elasticsearch是面向文档型数据库,一条数据是一个文档,用JSON格式存储。
    搜索:ES的一切设计是为了检索快速响应。使用倒排索引的设计方式,为每一列都建立索引。虽然会牺牲插入和更新的效率,但ES的核心是查询。

    shards : 索引分片。将一个大的索引分成多个分片,分布到不同节点上,构成分布式搜索。只能在索引创建前指定,其后不可更改。
    replicas :副本。 1、提高容错性 2、查询时可以负载均衡。
    recovery : 数据重新分布。 新增或减少节点的时候,会recovery

    click house MPP架构的支持向量化引擎的列式存储
    1、完备的DBMS功能:DML、DDL、DCL、权限控制、
    2、列存储与数据压缩 :列存储只需扫描需要的列,而无须整表扫描,返回所需的列。压缩减少网络传输。
    3、向量化执行引擎:消除程序中的循环,用多指令【cpu的寄存器指令集】的方式并发执行,代替循环。属于数据级并发;其与多线程【线程级并发】联合使用,加快访问速度。
    4、分布式存储:既支持分区 ( 纵向扩展,利用多线程原理 ),也支持分片 ( 横向扩展,利用分布式原理 )。计算时移动计算比移动数据要高效的多的多。
    5、多主架构:访问任何一个节点都是对等的,且可以天然避免单点故障。

    MPP与分布式 https://blog.csdn.net/qq_33876553/article/details/108728204?utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.search_more&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.search_more
    1、(关键字:非共享、单点、扩展性低)MPP是传统数仓常见的架构,将单机数据库节点组成集群提升性能。集群各节点使用非共享架构,每个节点有独立的存储和内存,各自独立运行,节点间数据通过专用网络传输,直至所有节点计算完再汇总统计结果数据。有良好的C一致性、A可靠性、P分区容错性。支持分布式事物,但单点问题会拖慢整体运行效率,集群规模增大,单点慢效率越易发,扩展性也受到一定影响。
    2、(关键字:整体、单节点对外提供服务)MPP单个节点无法对外提供服务,只能作为一个整体去提供对外服务。而分布式各节点实现场地自治,可以独立运行局部应用。
    3、(关键字:共享、自治、高吞吐高延迟、易扩展)分布式:数据在集群中是全局透明共享的,每个节点计算资源自治,存储资源共享组成公共数据存储系统,高吞吐但也有较高延迟。因为共享存储,因此扩展性极强,也非常适合处理非结构化、半结构化数据。
    4、在数据量较低的情况下,MPP更合适,但当数据规模达到一定量级的时候,分布式的吞吐量优势就明显了。

    Kafk高吞吐量的分布式发布订阅消息系统 受zookeeper管理
    Kafka的特性:

    • 高吞吐量、低延迟:kafka每秒可以处理几十万条消息,它的延迟最低只有几毫秒,每个topic可以分多个partition, consumer group 对partition进行consume操作。
    • 可扩展性:kafka集群支持热扩展
    • 持久性、可靠性:消息被持久化到本地磁盘,并且支持数据备份防止数据丢失
    • 容错性:允许集群中节点失败(若副本数量为n,则允许n-1个节点失败)
    • 高并发:支持数千个客户端同时读写
    • kafka消息传输策略: 生产者可以request.required.acks来设置消息发布的准确性。
    • acks = 0: 生产者只要消息发布成功就算消息传输完成,可能会丢失数据,性能最快。
    • acks = 1:生产者发布消息后,只要Master确认收到消息就算投递成功,其他的Slave都是通过fetcher去同步的,所以kafka是异步写,主备切换可能丢数据。性能折中。
    • acks = -1:生产者发布消息后,只有当Master和所有Slave都接收到消息时,才算成功,延时取决于最慢的机器。强一致,不会丢数据,性能最慢。

    Redis: 高性能的key-value数据库。
    原子性:要么都成功,要么都失败;同时基于原子性也可以支持到事务,使用MULTI和EXEC指令包起来支持事务。
    基于内存: Redis运行在内存中但是可以持久化到磁盘。
    性能极高: Redis能读的速度可以达到100000次/s,写的速度是80000次/s 。
    缓存雪崩:缓存同时大面积失效 – 分散key失效时间、限流、
    穿透: 请求不存在的key。布隆过滤器,将所有可能存在的key哈希到一个大的bitmap中,将一定不存在的key拦截。或将不存在的数据返回为空,放入缓存,保持短时间内存在。
    3、内存淘汰机制: 随机、ttl、最近最少使用(时间线)、最不经常使用(频率)

    hive 基于Hadoop的一个数据仓库工具
    1、hive本身不做数据存储,数据存放在hdfs上,对于表来说则是hdfs上的一个预定义好的额目录。hive不支持对数据的修改和增加。
    2、hiveQL是一种类sql,最终会转化为Hadoop的MapReduce任务。学习成本低,通过类sql实现mr任务,使逻辑可读性增强。
    3、hive适用于离线的大数据分析统计,有很高的延迟,在任务的提交和调度的时候都有很大的开销。所以几百MB的数据不适于用hive分析统计。
    hive特性
    ● 支持创建索引,优化数据查询。
    ● 不同的存储类型,例如,纯文本文件、HBase 中的文件。
    ● 将元数据保存在关系数据库中,大大减少了在查询过程中执行语义检查的时间。
    ● 可以直接使用存储在Hadoop 文件系统中的数据。
    ● 内置大量用户函数UDF 来操作时间、字符串和其他的数据挖掘工具,支持用户扩展UDF 函数来完成内置函数无法实现的操作。
    ● 类SQL 的查询方式,将SQL 查询转换为MapReduce 的job 在Hadoop集群上执行。

    spark 基于内存的计算。
    **使用场景:**可以支持交互式查询(Spark SQL)、批处理、流计算(Spark Streaming)、图计算(GraphX)、机器学习(Spark MLlib)。
    通用性:spark不同处理不同类型的数据可以在一个应用中无缝使用,统一的解决方案有效减少开发、减少维护的人力成本和部署平台的物力成本。
    **兼容性:**spark主要运行在Hadoop上,可以支持Hadoop的hive、hbase和Cassandra等主要数据格式。所以Hadoop上只需安装spark即可使用这些功能,无需数据格式的迁移。
    应用
    Yahoo将Spark用在Audience Expansion中的应用,进行点击预测和即席查询等
    淘宝技术团队使用了Spark来解决多次迭代的机器学习算法、高计算复杂度的算法等。应用于内容推荐、社区发现等
    腾讯大数据精准推荐借助Spark快速迭代的优势,实现了在“数据实时采集、算法实时训练、系统实时预测”的全流程实时并行高维算法,最终成功应用于广点通pCTR投放系统上。
    优酷土豆将Spark应用于视频推荐(图计算)、广告业务,主要实现机器学习、图计算等迭代计算。

    flink: 流处理 基于内存的,也可定制化内存计算,避免oom错误
    特点:
    1、内存计算,也可定制化内存来避免内存溢出错误。
    2、高吞吐、低延迟
    3、支持窗口
    4、Exactly once语义保证
    flink最主要两点: 窗口和Exactly once
    1、有界流 处理有界流等待所有数据到达即可计算,这点没什么可说的。
    2、无界流 处理无界流需要用到窗口,窗口可以是时间(每10秒钟)、条数(每100条)、session等。在无界流达到上述窗口期时启动一次计算,如count等。
    3、Exactly once 如果有节点失败,flink会从最近的一份快照开始重放数据来保证数据不丢失,而且它还会保证数据不会重复计算。

    storm: 流处理。

    hbase: bigtable 基于Hadoop的列式存储,时间戳记录。
    HBase是一种Hadoop数据库,经常被描述为一种稀疏的,分布式的,持久化的,多维有序映射,它基于行键、列键和时间戳建立索引,是一个可以随机访问的存储和检索数据的平台
    HBase使用场景和成功案例
    互联网搜索问题:爬虫收集网页,存储到BigTable里,MapReduce计算作业扫描全表生成搜索索引,从BigTable中查询搜索结果,展示给用户。
    抓取增量数据:例如,抓取监控指标,抓取用户交互数据,遥测技术,定向投放广告等
    内容服务
    信息交互
    数据中台
    数据中台是指通过数据技术,对海量数据进行采集、计算、存储、加工,同时统一标准和口径。
    数据中台建设的基础还是数据仓库和数据中心,并且在数仓模型的设计上也是一脉传承,之所以我们现在处处推崇数据中台建设及应用,一个是因为数据中台确实有过人之处,另一个是这套模型在阿里体现了巨大的应用价值。
    数据中台能力
    数据资产管理 数据质量管理 数据模型管理 构建标签体系
    数据应用规划及实现
    数据中台策略的基本理念是,将所有的数据汇聚到数据中台,以后的每个数据应用(无论是指标和分析类的,还是画像类和大数据类的)统统从数据中台获取数据,如果数据中台没有,那么数据中台就负责把数据找来,如果数据中台找不来,就说明当前真没有这个数据,数据应用也就无从展开。
    数据中台构成
    数据仓库 大数据中间件 数据资产管理

    展开全文
  • dmp大数据平台设计方案
  • 阿里巴巴 大数据产品设计体系与方法 阿里巴巴大数据UED 明确业务目标 WHAT 做什么 WHEN&WHERE 场景是什么? WHO 用户是谁 WHY 为什么这么做 HOW 怎么做 T型设计模型 横向链路 经营链路体验链路分析链路服务链路 纵 ...
  • 大数据平台架构设计

    千次阅读 2021-02-18 14:34:46
    大数据架构 大数据架构,如下图: 1、通过ETL工具将数据源抽取到HDFS存储; 2、通过Hive清洗、处理和计算原始数据; 3、Hive清洗处理后的结果,如果是面向海量数据随机查询场景的可存入Hbase; 4、数据应用从...

     

    大数据架构

    大数据架构,如下图:

    1、通过ETL工具将数据源抽取到HDFS存储;

    2、通过Hive清洗、处理和计算原始数据;

    3、Hive清洗处理后的结果,如果是面向海量数据随机查询场景的可存入Hbase;

    4、数据应用从HBase查询数据;

          

           大数据架构实例1,如下图:

    大数据架构实例2,如下图:

    大数据架构实例3,如下图:

    大数据架构实例4,如下图:

    大数据架构实例5:

    大数据架构实例6:

    一、场景

    1.数据源主要为 Mysql,希望实时同步 Mysql 数据到大数据集群中(肯定是越快越好)。

    2目前每日 20 亿数据,可预见的一段时间后的规模是 100 亿每日以上。

    3.能快速地查到最新的数据,这里包含两部分含义:从 Mysql 到大数据集群的速度快、从大数据集群中查询的速度要快。

    二、方案选型

    遇到这个场景的时候,根据经验我们主要考虑下面两个点:数据抽取引擎和存储引擎。

    数据抽取引擎

    这里我们主要考虑两种方案:

    1.Sqoop 定时抽取 Mysql 数据到 HDFS 中,可以每天全量抽取一份,也可以隔段时间就抽取一份变更的数据。

    2.Canal 监听 Mysql 的 binlog 日志,相当于是 Mysql 有一条数据久变动,我们就抽取一条数据过来。

    优缺点的对比也很明显:

    1.Sqoop 相对比较通用一些,不管是 Mysql 还是 PostgreSql都可以用,而且很成熟。但是实时性较差,每次相当于是启动一个 MR 的任务。

    2.Canal 速度很快,但是只能监听 Mysql 的日志。

    存储引擎

    存储引擎主要考虑 HDFS、Hbase 和 ES。

    一般情况下,HDFS 我们尽量都会保存一份。主要纠结的就是 Hbase 和 ES。本来最初是想用 Hbase 来作为实时查询的,但是由于考虑到会有实时检索的需求,就暂定为ES

    三、方案设计

    最终,我们使用了下面的方案。

    1.使用 Canal 来实时监听 Mysql 的数据变动

    2.使用 Kafka 作为消息中间件,主要是为了屏蔽数据源的各种变动。比如以后即使用 Flume 了,我们架构也不用大变

    3.数据落地,有一份都会落地 HDFS,这里使用 Spark Streaming,算是准实时落地,而且方便加入处理逻辑。在 落地 ES 的时候可以使用 Spark Streaming,也可以使用 Logstach,这个影响不大

     

    Hive和Hbase

    Hive主要解决海量数据的清洗、处理和计算的问题。严格来说Hive不是数据库,它通过元数据来描述Hdfs上的结构化文本数据,就是定义一张表来描述HDFS上的结构化文本,包括各列数据名称、数据类型等,方便处理数据。当前很多SQL ON Hadoop的计算引擎均用的是hive元数据,如Spark SQL、Impala。

    Hive会将SQL翻译为Mapreduce来处理数据,适用于离线的批量数据计算,但仅限于查找和分析,而不是更新、增加和删除。它的底层是MapReduce,MapReduce在实时计算上性能很差。它的做法是把数据文件加载进来作为一个hive内部表或者外部表,让你觉得你的sql操作的是传统的表。但Hive使用load data操作的时候,不管是外部表还是内部表,如果源数据存在于HDFS层,都是数据的移动,即源数据从HDFS存储路径移动到Hive数据仓库默认路径。

    Hadoop是hive和hbase的基础,hive依赖hadoop,而hbase仅依赖hadoop的hdfs模块。

    Hive适用于离线数据的分析,操作的是通用格式的(如通用的日志文件)、被hadoop管理的数据文件,它支持类sql,比编写MapReduce的java代码来的更加方便,它的定位是数据仓库,存储和分析历史数据
    hbase适用于实时计算,采用列式结构的nosql,操作的是自己生成的特殊格式的HFile、被hadoop管理的数据文件,它的定位是数据库,或者叫DBMS

    Hive可以直接操作hdfs中的文件作为它的表的数据,也可以使用hbase数据库作为它的表.

     

    Hbase主要用于海量明细数据(十亿、百亿)的随机实时查询的问题,如日志明细、交易清单、轨迹行为等。

    Hbase基于hdfs实现对分布式数据文件的管理,比如增删改查。也就是说,hbase只是利用hadoop的hdfs帮助其管理数据的持久化文件(HFile),它跟MapReduce没任何关系。hbase的优势在于实时计算,所有实时数据都直接存入hbase中,客户端通过API直接访问hbase,实现实时计算。由于它使用的是nosql,或者说是列式结构,从而提高了查找性能,使其能运用于大数据场景,这是它跟MapReduce的区别。

    在Hbase中日志即数据,数据就是日志,他们是一体化的。为什么这么说了,因为Hbase的更新时插入一行,删除也是插入一行,然后打上删除标记,则不就是日志吗?

         在Hbase中,有Memory Store,还有Store File,其实每个Memory Store和每个Store File就是对每个列族附加上一个B+树(有点像Oracle的索引组织表,数据和索引是一体化的), 也就是图的下面是列族,上面是B+树,当进行数据的查询时,首先会在内存中memory store的B+树中查找,如果找不到,再到Store File中去找。

         如果找的行的数据分散在好几个列族中,那怎么把行的数据找全呢?那就需要找好几个B+树,这样效率就比较低了。所以尽量让每次insert的一行的列族都是稀疏的,只在某一个列族上有值,其他列族没有值,

    一,索引不同造成行为的差异。Hbase只能建立一个主键索引,而且之后的数据查询也只能基于该索引进行简单的key-value查询;但是Oracle可以建立任意索引,也可以按照任意列进行数据查询。

    二,Hbase适合大量插入同时又有读的情况,读一般为key-value查询大数据、高并发正合Hbase的胃口

    ,Hbase的瓶颈是硬盘传输速度,Oracle的瓶颈是硬盘寻道时间。Hbase都是大量往硬盘上写数据(没有delete、update,都是insert),即使是读数据,也是优先MemStore,所以硬盘传输速度成为其瓶颈;而Oracle由于具有随机访问特性(select、update等),所以硬盘寻道时间成为其瓶颈,而寻道时间主要由转速决定。

    四,Hbase很适合寻找按照时间排序top n的场景。Hbase数据都具有时间戳(Hbase默认就有时间戳)

           五Hbase的优缺点:

    1 列的可以动态增加,并且列为空就不存储数据,节省存储空间.

    2 Hbase自动切分数据,使得数据存储自动具有水平scalability.

    3 Hbase可以提供高并发读写操作的支持

    4 不能支持条件查询,只支持按照Row key来查询.

    5 暂时不能支持Master server的故障切换,当Master宕机后,整个存储系统就会挂掉.

    6另外,由于在Hbase中,同一个列里面数据格式比较接近,或者长度相近,从而可以对数据进行大幅度的压缩,结果就是节省了硬盘空间,也减少了IO。

    1.数据类型,HBase只有简单的字符类型,所有的类型都是交由用户自己处理,它只保存字符串。而关系数据库有丰富的类型和存储方式。

    2.数据操作:HBase只有很简单的插入、查询、删除、清空等操作,表和表之间是分离的,没有复杂的表和表之间的关系,而传统数据库通常有各式各样的函数和连接操作。 

    3.存储模式:HBase是基于列存储的,每个列族都由几个文件保存,不同的列族的文件时分离的。而传统的关系型数据库是基于表格结构和行模式保存的

    4.数据维护,HBase的更新操作不应该叫更新,它实际上是插入了新的数据,而传统数据库是替换修改

    5.可伸缩性,Hbase这类分布式数据库就是为了这个目的而开发出来的,所以它能够轻松增加或减少硬件的数量,并且对错误的兼容性比较高。而传统数据库通常需要增加中间层才能实现类似的功能

     

    Flume和Kafka

    Flume基于agent思路架构,设计了3个组件source、channel、sink。source面向各种形式的数据源提供数据源对接与数据采集功能,以event格式将数据发送给channel。channel提供数据缓冲能力,保证数据传输的事务性和安全性,channel接收source发送过来的event数据并缓冲起来,直到被sink消费掉为止。Sink对接各种形式的数据存储,把数据存储起来,或者再次对接source形成传递接力。

    Flume通过内置种类丰富的source提供强大的数据源对接与数据采集能力,通过channel提供了微弱的数据缓冲能力,并保证数据传递的事务性与安全性,通过内置的拦截器,可以对流经数据进行过滤和屏蔽,具有微弱的计算能力。

    Flume中event的相关概念:Flume的核心是把数据从数据源(source)收集过来,在将收集到的数据送到指定的目的地(sink)。为了保证输送的过程一定成功,在送到目的地(sink)之前,会先缓存数据(channel),待数据真正到达目的地(sink)后,Flume再删除自己缓存的数据。

    在整个数据的传输的过程中,流动的是event,即事务保证是在event级别进行的。那么什么是event呢?Event将传输的数据进行封装,是Flume传输数据的基本单位,如果是文本文件,通常是一行记录。Event也是事务的基本单位。Event从source,流向channel,再到sink,本身为一个字节数组,并可携带headers(头信息)信息。Event代表着一个数据的最小完整单元,从外部数据源来,向外部的目的地去。 

    Flume之所以这么神奇,是源于它自身的一个设计,这个设计就是agent。Agent本身是一个Java进程,运行在日志收集节点——所谓日志收集节点就是服务器节点。 Agent里面包含3个核心的组件:source、channel和sink,类似生产者、仓库、消费者的架构。

    Source:source组件是专门用来收集数据的,可以处理各种类型、各种格式的日志数据,包括avro、thrift、exec、jms、spooling directory、netcat、sequence generator、syslog、http、legacy、自定义。 

    Channel:source组件把数据收集来以后,临时存放在channel中,即channel组件在agent中是专门用来存放临时数据的——对采集到的数据进行简单的缓存,可以存放在memory、jdbc、file等等。 

    Sink:sink组件是用于把数据发送到目的地的组件,目的地包括hdfs、logger、avro、thrift、ipc、file、null、Hbase、solr、自定义。

    Flume的核心就是一个agent,这个agent对外有两个进行交互的地方,一个是接受数据输入的source,一个是数据输出的sink,sink负责将数据发送到外部指定的目的地。source接收到数据之后,将数据发送给channel,chanel作为一个数据缓冲区会临时存放这些数据,随后sink会将channel中的数据发送到指定的地方,例如HDFS等。注意:只有在sink将channel中的数据成功发送出去之后,channel才会将临时数据进行删除,这种机制保证了数据传输的可靠性与安全性。

    Kafka基于分布式高可用的borker提供强大的数据缓冲能力,producer对接数据源采集数据,并将数据发送到broker上,数据就在borker上缓存下来(从这个角度看borker很像数据库),直到sink消费完数据为止。

    Kafka基于分布式架构提供高容错功能,基于offset记录已经处理过的数据,消息写入topic有顺序,consumer记录自己的offset,topic数据存储在分区上,分区有副本,分布在不同节点上.

    Kafka提供consumer group概念。某些topic拥有数百万甚至数千万的消息量,如果仅仅靠单个消费者消费,那么消费速度会非常慢,所以我们需要使用消费组功能,同一个消费组的多个消费者就能分布到多个物理机器上以加速消费。每个消费者组都会有一个独一无二的消费者组id来标记自己。每一个消费者group可能有一个或者多个消费者,对于当前消费组来说,topic中每条数据只要被消费组内任何一个消费者消费一次,那么这条数据就可以认定被当前消费组消费成功。消费组有如下三个特征:

    1、每个消费组有一个或者多个消费者。

    2、每个消费组拥有一个唯一性的标识id。

    3、消费组在消费topic的时候,topic的每个partition只能分配给一个消费者。

    Kafka的producer和consumer通常需要定制,所以对接各种数据源不灵活、不方便。

    所以,在生产环境中,一般将Flume和Kafka搭配使用,Flume采集kafka缓冲,来完成实时流式的数据处理。

           1、生产环境中,往往是读取日志进行分析,而这往往是多数据源的,如果Kafka构建多个生产者使用文件流的方式向主题写入数据再供消费者消费的话,无疑非常的不方便。

           2、如果Flume直接对接实时计算框架,当数据采集速度大于数据处理速度,很容易发生数据堆积或者数据丢失,而kafka可以当做一个消息缓存队列,从广义上理解,把它当做一个数据库,可以存放一段时间的数据。

           3、Kafka属于中间件,一个明显的优势就是使各层解耦,使得出错时不会干扰其他组件。

           4、Kafka与Flume都可以通过配置保证数据不丢失。但是,Flume不会复制消息,因此即使使用可靠的文件渠道,当Flume进程宕机后,你就无法访问这些消息了(当然Flume进程重启,从磁盘上恢复之前状态后,可以继续对消息进行处理)。因此如果对 HA高可用性具有很高要求,我们建议Kafka;

           另外Flume常用的场景是:直接将数据写入存储,如hadoop或habase中。Flume对HDFS/HBase具有更好的优化,同时它也集成了Hadoop安全组件。如果数据需要被多个应用程序处理,我们建议Kafka;如果数据主要是用于Hadoop,我们建议Flume;

           另外如果希望将Kafka上的数据导入Hadoop,可以启动一个内置Kafka源与Hadoop槽的Flume进程。这样就不需要去实现自定义的消费者,同时还可以得到Flume对HDFS/HBase优化带来的好处。

          

           Kafka为什么能做到高吞吐

    Kafka虽然是基于磁盘做的数据存储,但却具有高性能、高吞吐、低延时的特点,其吞吐量动辄几万、几十上百万。Kafka是将消息记录持久化到本地磁盘中的,一般人会认为磁盘读写性能差,可能会对Kafka性能如何保证提出质疑。实际上不管是内存还是磁盘,快或慢关键在于寻址的方式,磁盘分为顺序读写与随机读写,内存也一样分为顺序读写与随机读写。基于磁盘的随机读写确实很慢,但磁盘的顺序读写性能却很高,一般而言要高出磁盘随机读写三个数量级,一些情况下磁盘顺序读写性能甚至要高于内存随机读写。

    磁盘的顺序读写是磁盘使用模式中最有规律的,并且操作系统也对这种模式做了大量优化,Kafka就是使用了磁盘顺序读写来提升的性能。Kafka的message是不断追加到本地磁盘文件末尾的,而不是随机的写入,这使得Kafka写入吞吐量得到了显著提升 。

    Kafka利用了操作系统本身的Page Cache,就是利用操作系统自身的内存而不是JVM空间内存。    相比于使用JVM或in-memory cache等数据结构,利用操作系统的Page Cache更加简单可靠。首先,操作系统层面的缓存利用率会更高,因为存储的都是紧凑的字节结构而不是独立的对象。其次,操作系统本身也对于Page Cache做了大量优化,提供了 write-behind、read-ahead以及flush等多种机制。再者,即使服务进程重启,系统缓存依然不会消失,避免了in-process cache重建缓存的过程。

          通过操作系统的Page Cache,Kafka的读写操作基本上是基于内存的,读写速度得到了极大的提升。 

     linux操作系统 “零拷贝” 机制使用了sendfile方法, 允许操作系统将数据从Page Cache 直接发送到网络,只需要最后一步的copy操作将数据复制到 NIC 缓冲区, 这样避免重新复制数据 。

    通过这种 “零拷贝” 的机制,Page Cache 结合 sendfile 方法,Kafka消费端的性能也大幅提升。这也是为什么有时候消费端在不断消费数据时,我们并没有看到磁盘io比较高,此刻正是操作系统缓存在提供数据。

    零拷贝并非指一次拷贝都没有,而是避免了在内核空间和用户空间之间的拷贝。

    Kafka的message是按topic分类存储的,topic中的数据又是按照一个一个的partition即分区存储到不同broker节点。每个partition对应了操作系统上的一个文件夹,partition实际上又是按照segment分段存储的。这也非常符合分布式系统分区分桶的设计思想。

          通过这种分区分段的设计,Kafka的message消息实际上是分布式存储在一个一个小的segment中的,每次文件操作也是直接操作的segment。为了进一步的查询优化,Kafka又默认为分段后数据文件建立了索引文件,就是文件系统上.index文件。这种分区分段+索引的设计,不仅提升了数据读取的效率,同时也提高了数据操作并行度。

    Kafka数据读写也是批量的而不是单条的。除了利用底层的技术外,Kafka还在应用程序层面提供了一些手段来提升性能。最明显的就是使用批次。在向Kafka写入数据时,可以启用批次写入,这样可以避免在网络上频繁传输单个消息带来的延迟和带宽开销。假设网络带宽为10MB/S,一次性传输10MB的消息比传输1KB的消息10000万次显然要快得多。

          在很多情况下,系统的瓶颈不是CPU或磁盘,而是网络IO,对于需要在广域网上数据中心之间发送消息的数据流水线尤其如此。进行数据压缩会消耗少量CPU资源,不过对于kafka而言,网络IO更应该需要考虑。如果每个消息都压缩,但是压缩率相对很低,所以Kafka使用了批量压缩,即将多个消息一起压缩而不是单个消息压缩

    Kafka允许使用递归的消息集合,批量的消息可以通过压缩的形式传输并且在日志中也可以保持压缩格式,直到被消费者解压缩。Kafka支持多种压缩协议,包括Gzip和Snappy压缩协议。Kafka速度的秘诀在于,它把所有的消息都变成一个批量的文件,并且进行合理的批量压缩,减少网络IO损耗,通过mmap提高I/O速度,写入数据的时候由于单个Partion是末尾添加所以速度最优;读取数据的时候配合sendfile直接暴力输出。

     

    ETL

    Ketlle优劣分析总结:

    免费开源:基于java的免费开源的软件,对商业用户也没有限制

    易配置:可以在Window、Linux、Unix上运行,绿色无需安装,数据抽取高效稳定

    不同数据库:ETL工具集,它允许你管理来自不同数据库的数据

    两种脚本文件:transformation和job,transformation完成针对数据的基础转换,job则完成整个工作流的控制

    图形界面设计:通过图形界面设计实现做什么业务,无需写代码去实现

    定时功能:在Job下的start模块,有一个定时功能,可以每日,每周等方式进行定时

    Kettle家族目前包括4个产品:Spoon、Pan、CHEF、Kitchen。

    SPOON:允许你通过图形界面来设计ETL转换过程(Transformation),Spoon有丰富的Steps可以组装开发出满足多种复杂应用场景的数据集成作业,方便实现全量、增量数据同步。缺点是通过定时运行,实时性相对较差。

    PAN:允许你批量运行由Spoon设计的ETL转换 (例如一个时间调度器)。Pan是后台执行程序,没有图形界面

    CHEF:允许你创建任务(Job)。 任务通过允许每个转换,任务,脚本等等,更有利于自动化更新数据仓库的复杂工作。任务通过允许每个转换,任务,脚本等等。任务将会被检查,看看是否正确地运行了

    KITCHEN:允许你批量使用由Chef设计的任务 (例如一个时间调度器)。KITCHEN也是一个后台运行的程序

    适用场景:数据量及增量不大,业务规则变化较快,要求可视化操作,对技术人员的技术门槛要求低。

    Sqoop优劣分析总结:

    主要用于在HADOOP(Hive)与传统的数据库(mysql、postgresql...)间进行数据的传递。

    数据吞吐量大:依赖hadoop集群可进行大批量数据集成。

    操作有技术要求:sqoop操作没有可视化设计器,对使用人员有较专业的技术要求。

    多种交互方式:命令行,web UI,rest API。

    部署不方便:sqoop依赖大数据集群,使用sqoop要求数据传输的源要与大数据集群的所有节点能进行通信。

    适用场景:适用于能与大数据集群直接通信的关系数据库间的大批量数据传输。

    Flume优劣分析总结:

    分布式:flume分布式集群部署,扩展性好。

    可靠性好: 当节点出现故障时,日志能够被传送到其他节点上而不会丢失。

    易用性:flume配置使用较繁琐,对使用人员专业技术要求非常高。

    实时采集:flume采集流模式进行数据实时采集。

    适用场景:适用于日志文件实时采集。

    Canal优劣分析总结:

    很多大型的互联网项目生产环境中使用,包括阿里、美团等都有广泛的应用,是一个非常成熟的数据库同步方案,基础的使用只需要进行简单的配置即可。

    DataX优劣分析总结:

    阿里开源软件异构数据源离线同步工具,致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。

    易用性:没有界面,以执行脚本方式运行,对使用人员技术要求较高。

    性能:数据抽取性能高。

    部署:可独立部署

    适用场景:在异构数据库/文件系统之间高速交换数据。

     

    Flume是一个海量日志采集、聚合和传输的系统,支持在日志系统中定制各类数据发送方,用于收集数据。同时,Flume提供对数据进行简单处理,并写到各种数据接受方的能力。Flume以流方式处理数据,可作为代理持续运行。当新的数据可用时,Flume能够立即获取数据并输出至目标,这样就可以在很大程度上解决实时性问题。

    Flume是最初只是一个日志收集器,但随着flume-ng-sql-source插件的出现,使得Flume从关系数据库采集数据成为可能。下面简单介绍Flume,并详细说明如何配置Flume将MySQL表数据准实时抽取到HDFS。

    利用Flume采集关系数据库表数据最大的优点是配置简单,不用编程,Flume只要在flume.conf文件中配置source、channel及sink的相关属性,已经没什么难度了。再有该方案采用普通SQL轮询的方式实现,具有通用性,适用于所有关系库数据源。

    这种方案的缺点与其优点一样突出,主要体现在以下几方面。 

    1. 在源库上执行了查询,具有入侵性。
    2. 通过轮询的方式实现增量,只能做到准实时,而且轮询间隔越短,对源库的影响越大。
    3. 只能识别新增数据,检测不到删除与更新。
    4. 要求源库必须有用于表示增量的字段。

     

    Sqoop是一款开源的工具,主要用于在Hadoop(Hive)与传统的数据库(mysql、postgresql...)间进行数据的传递,可以将一个关系型数据库中的数据导进到Hadoop的HDFS中,也可以将HDFS的数据导进到关系型数据库中。Sqoop专为大数据批量传输设计,能够分割数据集并创建Hadoop任务来处理每个区块。通过导入导出命令加配套参数控制操作。

    使用Sqoop抽取从MySQL数据库增量抽取数据到HDFS,这种方式只需要很少量的配置即可完成数据抽取任务,但缺点同样明显,那就是实时性。Sqoop使用MapReduce读写数据,而MapReduce是为了批处理场景设计的,目标是大吞吐量,并不太关心低延时问题。就像实验中所做的,每天定时增量抽取数据一次。

    Sqoop导入:导入工具从RDBMS到HDFS导入单个表。表中的每一行被视为HDFS的记录。所有记录被存储在文本文件的文本数据或者在Avro和序列文件的二进制数据。

    Sqoop导出:导出工具从HDFS导出一组文件到一个RDBMS。作为输入到Sqoop文件包含记录,这被称为在表中的行。那些被读取并解析成一组记录和分隔使用用户指定的分隔符。     

    Sqoop支持全量数据导入和增量数据导入(增量数据导入分两种,一是基于递增列的增量数据导入(Append方式)。二是基于时间列的增量数据导入(LastModified方式)),同时可以指定数据是否以并发形式导入。

    (1)、Append方式

     

    (2)、LastModified方式

     

    命令简单示例:

     

     

    Canal是阿里巴巴旗下的一款开源项目,纯Java开发。基于数据库增量日志解析,提供增量数据实时订阅和消费,目前主要支持了MySQL,也支持mariaDB。很多大型的互联网项目生产环境中使用,包括阿里、美团等都有广泛的应用,是一个非常成熟的数据库同步方案,基础的使用只需要进行简单的配置即可。当前的 canal 支持源端 MySQL 版本包括 5.1.x , 5.5.x , 5.6.x , 5.7.x , 8.0.x.。

     

    Canal是通过模拟成为mysql 的slave的方式,监听mysql 的binlog日志来获取数据,binlog设置为row模式以后,不仅能获取到执行的每一个增删改的脚本,同时还能获取到修改前和修改后的数据,基于这个特性,canal就能高性能的获取到mysql数据数据的变更。

     

    DataX是阿里巴巴集团内被广泛使用的离线数据同步工具/平台,实现包括 MySQL、Oracle、HDFS、Hive、OceanBase、HBase、OTS、ODPS 等各种异构数据源之间高效的数据同步功能。DataX采用了框架 + 插件的模式,目前已开源,代码托管在github。从应用的模式,DataX更适合ELT模式。步骤:操作简单通常只需要两步;创建作业的配置文件(json格式配置reader,writer);启动执行配置作业。

     

    Job:一道数据同步作业

    Splitter:作业切分模块,将一个大任务与分解成多个可以并发的小任务.

    Sub-job:数据同步作业切分后的小任务

    Reader(Loader):数据读入模块,负责运行切分后的小任务,将数据从源头装载入

    DataXStorage:Reader和Writer通过Storage交换数据

    Writer(Dumper):数据写出模块,负责将数据从DataX导入至目的数据地

    DataX框架内部通过双缓冲队列、线程池封装等技术,集中处理了高速数据交换遇到的问题,提供简单的接口与插件交互,插件分为Reader和Writer两类,基于框架提供的插件接口,可以十分便捷的开发出需要的插件。缺乏对增量更新的内置支持,因为DataX的灵活架构,可以通过shell脚本等方式方便实现增量同步。

    DataX本身作为离线数据同步框架,采用Framework + plugin架构构建。将数据源读取和写入抽象成为Reader+Writer插件,纳入到整个同步框架中。

    目前已到datax3.0框架设计:

     

    datax使用示例,核心就是编写json配置文件job:

     

     

     

    数据集成加载策略,按类型可包括快照、流水、增量、全量、拉链等。

    SQL是最好的语言,各种join、嵌套/标量子查询,强大的分析/窗口函数,正则表达式,层次查询,扩展分组,MODEL,递归with,多维分析,排列组合,行列互转,json解析,执行计划,四大类型(dql、dml、ddl、dcl)等。

    SQLjoin , left/rignt/full join,每一个join都是暗藏韵理,on和where也不容小觑。

     

    分析函数 简捷高效,4类30+个分析/窗口函数最全总结。

     

    SQL开发规范和 执行计划 也需要每个erl·er在实际实践中不断加强、提炼、升级。

     

     

    SQL分析函数

    分析函数主要分为四类:

            1.聚合分析函数

            2.排名分析函数

            3.数学分析函数

            4.行比较分析函数

    一.聚合分析函数

    SUM       :该函数计算组中表达式的累积和
    COUNT   :对一组内发生的事情进行累积计数
    MIN        :在一个组中的数据窗口中查找表达式的最小值
    MAX       :在一个组中的数据窗口中查找表达式的最大值
    AVG        :用于计算一个组和数据窗口内表达式的平均值。

    二.排名分析函数

    ROW_NUMBER :-- 正常排序[1,2,3,4] -- 必须有order_by
    RANK                :-- 跳跃排序[1,2,2,4] -- 必须有order_by
    DENSE_RANK   :-- 密集排序[1,2,2,3] -- 必须有order_by
    FIRST                :从DENSE_RANK返回的集合中取出排在最前面的一个值的行
    LAST                 :从DENSE_RANK返回的集合中取出排在最后面的一个值的行
    FIRST_VALUE    :返回组中数据窗口的第一个值
    LAST_VALUE     :返回组中数据窗口的最后一个值。

    row_number() 是没有重复值的排序(即使两行记录相等也是不重复的)
    rank() 是跳跃排序,两个第二名下来就是第四名
    dense_rank() 是连续排序,两个第二名仍然跟着第三名
    NTILE(n),用于将分组数据按照顺序切分成n

    三.数学分析函数

    STDDEV      :计算当前行关于组的标准偏离

    STDDEV_POP:该函数计算总体标准偏离,并返回总体变量的平方根

    STDDEV_SAMP:该函数计算累积样本标准偏离,并返回总体变量的平方根

    VAR_POP       :该函数返回非空集合的总体变量(忽略null)

    VAR_SAMP    :该函数返回非空集合的样本变量(忽略null)

    VARIANCE     :如果表达式中行数为1,则返回0,如果表达式中行数大于1,则返回VAR_SAMP

    COVAR_POP   :返回一对表达式的总体协方差

    COVAR_SAMP :返回一对表达式的样本协方差

    CORR        :返回一对表达式的相关系数

    CUME_DIST   :计算一行在组中的相对位置

    NTILE        :将一个组分为"表达式"的散列表示(类于Hive的分桶原理)

    PERCENT_RANK :和CUME_DIST(累积分配)函数类似

    PERCENTILE_DISC :返回一个与输入的分布百分比值相对应的数据值

    PERCENTILE_CONT :返回一个与输入的分布百分比值相对应的数据值

    RATIO_TO_REPORT :该函数计算expression/(sum(expression))的值,它给出相对于总数的百分比

    REGR_ (Linear Regression) Functions :这些线性回归函数适合最小二乘法回归线,有9个不同回归函数可使用

    四.行比较分析函数

    LAG         :可以访问结果集中的其它行而不用进行自连接      -- 落后 -- lag(xx,1,0)

    LEAD      :LEAD与LAG相反,LEAD3可以访问组中当前行之后的行    -- 领先 -- lead(xx,1,0)

    lag(field, N) 取前N行的值

    lead(field, N) 取后N行的值

    注意:取前/后N行的值是当前行往前/后数第n行的值

    first_value,取分组内排序后,截止到当前行,第一个值

    根据组内排序获得第一行的

    last_value,取分组内排序后,截止到当前行,最后一个值

    也就是当前行的值

     

    concat_ws:实现多行记录合并成一行

    collect_set:对记录去重

    collect_list:不对记录去重

     

    分析函数的语法结构一般是:

    分析函数名(参数) OVER (PARTITION BY子句 ORDER BY子句 ROWS/RANGE子句)

    分析函数名:sum、max、min、count、avg等聚集函数,或lead、lag行比较函数 或 排名函数等;

    over:关键字,表示前面的函数是分析函数,不是普通的集合函数;

    分析子句:over关键字后面挂号内的内容;分析子句又由以下三部分组成:

    partition by:分组子句,表示分析函数的计算范围,不同的组互不相干;

    ORDER BY:排序子句,表示分组后,组内的排序方式;

    ROWS/RANGE:窗口子句,是在分组(PARTITION BY)后,组内的子分组(也称窗口),是分析函数的计算范围窗口。窗口有两种,ROWS和RANGE;

     

     

     

    range是逻辑窗口,是指定当前行对应值的范围取值,行数不固定,只要行值在范围内,对应列都包含在内。

    rows是物理窗口,即根据order by 子句排序后,取的前N行及后N行的数据计算(与当前行的值无关,只与排序后的行号相关)。“ROWS” 是按照行数进行范围定位的,而“RANGE”则是按照值范围进行定位的,这两个不同的定位方式 主要用来处理并列排序的情况     前后遇到相同的值的时候会进行累加

     

     

    1)同时存在

     spark.sql("""

     SELECT cookieid, createtime, pv,

            SUM(pv) OVER(PARTITION BY cookieid ORDER BY createtime) AS pv1

     FROM t1

     """).show

    正常显示

    2) partition by出现

           spark.sql("""

           SELECT cookieid, createtime, pv,

                  SUM(pv) OVER(PARTITION BY cookieid ) AS pv1

           FROM t1

           """).show

    没有排序仅分组内没有一个个迭代计算

    都是分组的计算值

    3) order by 出现

    只有排序 两两相加再加上,上一个的和(两两是计算机分组的数)

    4) 都没有

    显示总计算值

     

     

     

     

     

     

    展开全文
  • 可视化大数据大屏设计

    千次阅读 2019-10-23 09:15:14
    可视化大数据大屏设计一、如何做好一款大屏1.1工具的选择帆软报表工具Finereport1.2大屏设计通用的大屏设计原则1、大屏指标在8-12个为宜2、比率类、数字类和子部分布类指标要合理布局3、时间序列指标、文本指标不可...
  • 大数据平台设计

    万次阅读 2016-06-27 10:44:59
    大数据总介 我们通常说的大数据,包括大数据本身和基于大数据的系统和技术。大数据的5V特点(IBM提出):Volume(大量)、Velocity(高速)、Variety(多样)、Value(价值)、Veracity(真实性)。而基于大数据...
  • 如果缺乏有效的数据整体架构设计或者部分能力缺失,会导致业务层难以直接利用大数据大数据大数据和业务产生了巨大的鸿沟,这道鸿沟的出现导致企业在使用大数据的过程中出现数据不可知、需求难实现、数据难共享等一...
  • 必读|聊聊大数据产品经理

    千次阅读 2020-05-04 00:02:49
    本文也算是一个读书笔记吧,书名《数据产品经理》,作者梁旭鹏。五一期间,浪尖没事,就给大家整理些文章,以供大家在大数据的路上走的更明白,更通畅。本文摘自第一章,主要是讲大数据发展,数据产品...
  • 架构师在做架构设计时,最大的挑战是如何对计算组件和存储组件进行选型和组合,同类的计算引擎的差异化相对不大,通常会优先选择成熟和生态健全的计算引擎,例如批量计算引擎Spark和流计算引擎Flink。而对于存储组件...
  • 大数据背景下《景观规划设计》混合智能课堂的研究与实践.pdf
  • 利用计算机图形学,图像处理技术以及大数据技术,通过简单拖拽、配置编排出可视化应用页面的 ...大数据产品家族中的应用与服务层的大数据可视化产 品系列,更注重如何快速有效地采用直观多样化的效果将数据呈现出来
  • 大数据平台产品开发

    千次阅读 2019-11-05 08:26:06
    本文就作者在大数据产品开发的经验,从大数据的产品规划、项目管理、架构设计等三个方面,讨论大数据产品的构建过程。 由于时间关系,先列出目录,后续补充。 一、大数据产品--产品规划篇 什么产品规划 如何...
  • 大数据平台架构设计案例

    千次阅读 2020-10-12 18:38:34
    大数据平台的整体架构可以由以下几个部分组成: 一、业务应用:其实指的是数据采集,你通过什么样的方式收集到数据。互联网收集数据相对简单,通过网页、App就可以收集到数据,比如很多银行现在都有自己的App。 更...
  • 实时大数据平台的设计与实现

    千次阅读 2019-01-12 16:24:38
    实时大数据平台的设计与实现 什么是实时大数据平台 实时大数据平台和离线大数据平台还是有区别的,更强调数据的实时性.具体的架构,具体的代码该怎么写,模块怎么去构建,各个系统之间怎么去组织协调,都需要根据对应的...
  • PAGE 2 PAGE 2 第 PAGE 92 页 共 NUMPAGES 112 页 大数据平台 详细设计 V1.0版 TOC \o "1-5" \h \z \u 产品简介 4 重要公共模块 5 ? 基础数据结构Array 5 ? 内存访问数据结构MemoryBlock 5 ? 内存池Memory Pool 7 ? ...
  • 15篇大数据精品文章大合集

    万次阅读 2020-02-06 15:50:06
    简介:这一次,开发者社区为正在“宅家办公”的小伙伴们献上福利~这次的合集整理了一些比较受开发者欢迎的关于大数据技术领域的优质文章。 不管是初涉该领域,还是已经有一定了解,相信都能从文章中获益。大家快来...
  • 为了充分利用运营商大数据来支撑终端产品运营,设计了一种基于运营商大数据的终端产品运营系统,主要包括终端监控子系统、终端推荐子系统、应用推荐子系统。该系统通过建立监控指标、终端推荐模型、应用推荐模型充分...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 123,961
精华内容 49,584
关键字:

大数据产品设计