加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 云计算 > 正文

作为数据产品经理,你需要知道这些技术知识

发布时间:2019-11-29 23:32:02 所属栏目:云计算 来源:顽皮木偶
导读:副标题#e# 在数据分析领域下,总会被提及诸如SQL、Hive,甚至Hardoop、Druid、Spark等这些技术上的词汇。那么作为一名数据领域的产品经理,听着这些不是很常见的产品知识,又应该具备怎样的技术知识呢?本文主要从“用户行为数据“角度介绍一整套的技术架构

由于采集的数据属于原始数据,且SDK层基于原始数据的真实性和翘楚性,基本是不会做结构化的逻辑处理,即不会做数据加工。所以SDK在这里多会进行识别数据的处理。

  • 识别用户ID:不管数据如何原始、混乱,有一个关键的就是需要识别产生这个数据的“用户”是谁,所以就有用户ID的说法。但这个用户ID不同的产品和业务,各家不尽相同,生成ID的算法也不同,有人用操作系统的IDFA和IMEI生成设备口径的算法,也有人直接用软件的账户ID作为翘楚用户ID,这个是没有规定的。例子:“userid”:321990ddwsadnkiouf78hjh”;
  • 识别程序ID:因为SDK是支持多个程序独'立使用的,但是数据终是在同一个服务端和数据库,那么就需要做应用程序之间的区分。这个时候就有应用ID,每个独'立应用分配一个ID,且是翘楚的。至于如何分配生成,也是看各家的业务诉求,并没有翘楚标准。例子:“productid”:“12321321321dasdasdas33213”

2.3.3 上报数据

由于SDK在嵌入应用程序前,就已经打通与服务端的接口并进行上报。所以此时SDK是已经界定了一系列的上报逻辑,以及需要传什么数据。

  • 原始数据:其实就是一条条原始数据记录,每条数据附带那一刻采集的诸多信息,包括用户ID、设备数据、埋点数据等,但这些数据并不是每条都必带的,取决于当时的环境是否有提供这些信息.
  • Session:指某一次节会话信息,主要为了记录用户行为习惯。因为每个用户操作习惯、时长都不同,有可能突然不再操作,又可能隔几分钟在操作,对于这样的情况需要基于业务场景的诉求,定义这些session逻辑,并分别创建不同的sessionid去分割。比如停止操作几分钟后、程序退出或切换至后台等是否需要定义。
  • Cookie:主要是网站使用的一种识别用户的数据集,一般存储在用户本地终端上,以便于用户在不同时间操作时都可以快速调用且识别为同一个设备用户。与session区别在于,Cookie存储在浏览器内,数据量有限且相对没那么安全。
三、数据接入存储层

从这一环节开始,就进入服务端运作的流程。这个环境涉及数据接入、解析和存储等3方面。

前面提到,SDK只会采集原始数据(就好比绿色无污染的食品),而这些非结构化数据其实不利于管理和使用的。这时候就需要在接入后进行数据解析、清洗加工再扔进数据库。

3.1 接入层

这一层是服务端与SDK端之间联系的一层,所有的日志数据就是通过这个接入层进行获取,但获取成功后是需要返回“成功”的信号给到SDK,证明是畅通的没有报错。

但大多数情况下,由于上报的数据较多,尽管是按批次上报,也是会出现类似“排队”的情况,一个一个去等完成再返回数据效率十分之低。所以这时候就会借用“redis”手段。

redis:Remote Dictionary Server 远程字典服务,实质是一个key-value存储系统,一门开源的数据库技术。简单来说它就好像一个副服务器,当主服务器接收到诸多数据后,都可以扔到这里来,让它慢慢接收,并且无需等待返回“结果”信息,主服务就可以告知SDK我这边“ok”了,请放心。

3.2 逻辑层

这一层的作用实际是指对数据进行解析、清洗加工处理,即日志数据,因为数据的存储是要按照明确的数据库和表的结构来存储。

日志数据例子:{“userid”:”3213213hdhdhasjoiewq3321″,”productid”:”dadsadsad2321321″,”mobile”:”samsung:SM-G9008V”,”country”:”CN”}

3.3 数据存储

提到数据存储,就必须接触到数据库,那么对于这样的用户行为数据,又会使用什么样的数据库呢?目前关于数据库,主要分为关系型和非关系型数据库。

3.3.1 关系型数据库

平常所接触到诸如Oracle、Hive、PG等,其实这些都属于关系型数据库,本质上都是建立在SQL(结构化查询语言)的基础上,所以大的特征就是结构化。这些适合大量的数据查询,统一提供增、删、改、查、排序等多种查询。

数据库类型有很多,以下仅列举常遇见的3种:

作为数据产品经理,你需要知道这些技术知识

3.3.2 非关系型数据库(NoSQL)

此类数据库的存在是出于性能、速度等方面考虑,主要是因为关系型数据库涉及数据较大、结构复杂,一些简单、体量小的存储和查询不适合在这样的数据库进行运作,所以才有这样的数据库。

上面也提到,其中redis就是这么一种,以及MongoD、Memcache。

  • 优点:这类数据库优点在于足够快、结构单一、数据集中等;
  • 缺点:结构相对没那么规范清晰、会有重复冗余;

3.3.3 数据库表

在使用SQL查询的时候,一个关键地方就是需要知道表结构。所谓的表结构就是数据表与表之间的关系,以及具体表字段的含义。所以数据库表的设计十分重要,对后续SQL查询计算、机器运行性能、任务执行等方面有很大的影响。

作为数据产品经理,你需要知道这些技术知识

(样例:usertable_01)

存在在数据库中的就是一张张这样的表,通过SQL语句查询可以快速获取所要的数据结果。所有原始数据经过解析清洗之后,就会像这样以结构化的形式进行存储,以便于管理和使用。

表设计:系统有诸多数据指标,而对于产品或运营而言,就是定义各个指标的统计逻辑和场景。那么对于技术者来说,除了输出固定的查询语句之外,还需要进行合理的表设计。

所谓的表设计,就是根据指标体系把结构化的数据分拆成多张数据表,并进行有机关联,从而提供合理的统计输出。

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读