ZLog数据服务实践
导语
背景
移动端是用户数据的源头，数据也分多种类型，每一种数据其处理方式也会不一样，下表是移动端常见的一些数据及处理方式：
移动端常见数据以及其处理方式
这么多种数据，收集、上报、处理等方式都不一样，同时也要考虑数据的安全。但业界对移动端数据收集、上报、分析并没有相对成体系的方案。大多是日志的存储、埋点的收集等单一功能组件的设计。随着我们对数据的需要，我们对每一种数据都需要写一套收集上报，先不说可行性，就说数据管理的复杂度、系统的稳定性、具体数据收集上报服务的配置、上报数据的准确性、后续的扩展性、数据之间的关联性等都有较多待解决的问题。
所有基于以上问题，我们的数据服务ZLog提供了解决方案。
ZLog是什么
ZLog是数据服务的基础，所有的对数据收集，整理，上报，分析的工作都可以基于ZLog来实现。
ZLog数据服务系统分为两个部分：
1、移动端的数据服务收集上报SDK（已完成，已上线，支持Android、iOS，可单独使用）
2、PC前端的数据服务可视化系统和后端对数据服务的接口API支持。
ZLog提供了更加简单的使用，新增一种数据类型就像搭积木一样组合就可以了。接入简单，调用和打log一样简单。
ZLog名称的由来，一开始只是提供给部门内App做日志系统使用的，使用过程中发现还有其他不同类型的数据需求同样适用，所以经过了架构升级优化后，目前可支持任何类型的数据。log这个词对于描述数据服务来说有一定的直观性。我们希望使用Zlog支持的数据服务，使用起来就像打log一样简单可信赖。
ZLog的方案设计
移动端数据服务ZLog SDK的设计
1、设计要求：
ZLog数据收集上报SDK是整个数据服务的基石，高性能、稳定性、准确性、可靠性、可扩展性是其必须具有的基本特征。
高性能：ZLog SDK的接入不能对APP性能产生显著的影响，要尽可能提高SDK的性能。
稳定性：ZLog SDK支持的数据服务一般都是系统数据服务，所以要有较高的稳定性，恢复能力，容灾能力，不能有崩溃。
准确性：ZLog SDK对支持的不同数据服务之间做了服务的隔离，避免数据相互影响。能确保数据的准确性，数据无丢失等情况。
易接入、可扩展：ZLog SDK支持多种数据服务，新增一种数据服务，只需要简单配置，就像搭积木一样简单，容易接入，提升开发效率。
2、框架设计：
Zlog SDK的设计框架如下图所示：
ZLog SDK设计
A、ZLog SDK层：
Worker : 数据服务的抽象。保证数据服务之间数据隔离、数据有序、支持业务自定义 Writer：数据存储的抽象。支持文件、DB、mmap文件等不同的存储方式。没有业务逻辑，各种不同的数据可以独立组合使用 Upload：数据上报的抽象。支持上报WOS、上报后端接口文件服务，实时上报，本地导出支持 DataMgr: 数据管理的抽象。各种不同的数据有不同的处理逻辑，需要业务方实现（加密），收集上报策略 Config：数据服务配置。各种数据服务都有自己不同的配置 Context：数据服务上下文环境。提供给数据服务使用 ZLog：统一调用入口
为了方便接入，ZLog SDK 同时还提供了大量的base基类。
Comm层只需要继承实现特定业务功能方法即可。如图CommUploader 公共的数据上报，只需要调用自己的业务接口实现上报即可。
C、业务调用层：
新增一种数据服务，只需要在初始化的时候创建自己的Worker（只需要继承即可，如有其他需要可覆写父类的方法），并在worker中按需添加writer、dataMgr、uploader即可。
调用非常方便，全局ZLog.xx()即可，就和打系统Log一样方便。
ZLog中每一条数据都会被携带在Msg中，同时也会自动生成这条数据产生的时间，进程id，线程id等等辅助数据。Msg也会复用，保证较少的内存消耗。Msg数据在Worker的处理也是使用生产者与消费者处理逻辑，保证数据不会出现时序问题，以及多线程调用出现问题。
PC前端数据服务可视化系统的设计
可视化系统主要功能有：各种数据服务的配置管理，数据收集控制、上报控制；具体数据的可视化页面。
下面以全应用日志为例讲解。
1、全应用日志数据可视化操作流程：
A、研发收到用户反馈问题，在可视化系统配置捞取特定用户的全应用日志
B、ZLog SDK接收到上报全应用日志指令，上报加密压缩日志
C、可视化系统接收到日志后，进行解压解密处理
D、研发根据用户对问题的描述，在可视化系统上筛选、定位、分析问题。
2、全应用日志数据格式：
每一条日志数据算是结构化的数据，日志数据格式如下图：
根据日志的level类型我们可以分类提取，快速定位问题，如下图：
log数据分类提取
比如用户行为我们可以单独提取出来，结合adb模拟点击、滑动等行为可以动态复现用户的操作行为。从可视化的角度就可以展现用户问题的场景。
遇到的问题
为了支持更多数据服务的接入，ZLog SDK从单一的日志组件向数据服务框架演进，如下图：
ZLog SDK架构演进
ZLog SDK 数据准确性校验
如图，我们在业务接口调用时(排除网络影响)埋点key，同时接口请求到达后端，后端也会有一个请求埋点k5。埋点key同时输入老埋点系统、ZLog埋点服务（存储方式有文件和DB两种）、单独一套DB埋点上报系统，上报得到的key应该是：k1、k2、k3、k4。按理预期结果应该是k1:k2:k3:k4:k5≈1:1:1:1:1。
我们做了多次的灰度对比测试。下图是23、24日两天某两个key的灰度数据：
灰度对比
1、ZLog SDK 埋点服务（存储使用DB write）这种方式是准确的。
2、ZLog SDK数据服务的稳定性和准确性。
ZLog的应用
ZLog已经在内部两款App上稳定使用快一年。
目前使用的数据服务有：
1、点对点日志回捞（全应用日志）
上线时间：2018.11
上报方式：在线实时回捞；用户协助上传（可在登录异常，网络异常的情况下由用户帮忙将加密压缩日志文件发给RD）
使用范围：APP Native代码、H5交互协议支持、DU（招才猫动态页面技术）支持
Case处理流程：ZLog全应用日志服务上线后，我们规范和梳理了一套问题排查解决流程
成果：
A、解决了不少难以复现的问题。例如全应用的使用帮助我们解决了困扰已久的消息列表不显示的偶现问题 和登录异常等问题，提升了用户体验。
B、提高了解决问题的效率。以前我们没有相关日志，只能不断地找用户了解问题复现的步骤，现在有了关键日志信息我们很快的就能定位问题。
C、制定和梳理了解决问题的流程，ZLog全应用日志成了我们解决问题的首选。
基于ZLog SDK 的全应用日志服务的使用，获取反馈用户的全应用日志，更有利于我们解决问题，也极大的提升了我们解决线上用户反馈问题的效率。
2、业务埋点
上线时间：2019.06
使用范围（支持）：APP Native代码、H5交互协议支持、DU（动态框架页面技术）支持
涉及服务：
A、ZLog埋点数据服务移动端SDK
B、埋点存储使用云窗DB（云数据库）
C、后端埋点管理系统（埋点注册、查询、报表生成等）
D、QA自动化埋点测试平台
基于ZLog SDK的新埋点服务上线后，验证了Zlog埋点服务数据的准确性。提高了运营数据的准确性。提高了业务埋点数据的准确度。
3、设备安全信息数据
上线时间：2019.01
基于ZLog SDK的设备安全信息数据服务上线后，根据上报的安全信息数据，可以构建出用户设备的安全权重，依靠权重可以助力业务安全。
4、用户行为数据（目前只做了页面级别）
上线时间：2019.10
基于ZLog SDK的用户行为数据上线后，支持如下能力：
A、可以更方便的统计某个路径过来的漏斗转化
B、提供了用户操作路径页面流量分析
C、有了行为数据之后，任何操作都可以拿到用户操作页面路径，类似web 的referer机制，据此也可以作为黑产防护的一项措施
下图是我们用户行为页面数据，1000个测试用户的操作页面流量路径图：
总结
目前数据服务ZLog SDK已经在使用了，未来我们会在数据可视化系统，数据分析方面做更多的工作，希望能助力业务提效。
参考文献
2、网易无埋点实践：
3、美团外卖移动端性能检测体系：
4、微信读书质量保证和性能检测：
作者简介
张万新，HRG技术部 Android高级研发工程师，常规Android开发之外，对于客户端安全、客户端研发效率工具开发有一定的研究。
END
阅读推荐
应用AST技术实现自动化升级React 15至React 16的解决方案