|
由于采集的数据属于原始数据，且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 关系型数据库 （编辑：西安站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
