1700509100
1700509101
1700509102
1700509103
1700509104
图12-8 PC BIOS中的Boot Device配置
1700509105
1700509106
在每台终端上安装数据收集程序也是一样的。数据收集程序通常要做两件事，第一件事是周期性地前往一个URL地址下载策略文件，第二件事是确定执行这个策略文件的内容。
1700509107
1700509108
所谓“周期性地前往一个URL地址下载策略文件”，是指程序里面要有这样的功能：在每天、每小时或者更短的时间间隔，到一个URL去下载一个策略文件。这个周期可以按照自己的业务需求而定。如果周期太短，不仅会给服务器造成不必要的压力，也没有必要；如果周期太长，策略生效的实时性也会降低。所以，对这个度要好好考量，并且要紧扣业务需要。文件的URL最好是一个域名，这样就不会因为IP地址的迁移而导致地址失效。
1700509109
1700509110
策略文件就是具体的报送逻辑——需要报送什么字段，以什么逻辑收集，报送到哪里，用什么格式承载这些信息。一般的策略文件都是脚本文件，由终端上的脚本库提供支持。在智能手机上，通常通过App版本的迭代直接升级（用C或Java编译的二进制文件居多）。PC上的情况类似，在程序里加入一些升级模块，可以直接升级一个 .dll文件，或者用其他库文件来更新。如果终端环境相对封闭（例如专用的ARM平台），也可以考虑在其中加入Python或者lua库，这样就可以将Python或者lua脚本作为策略文件，可读性更强，版本管理也比较方便。
1700509111
1700509112
数据科学家养成手册 [:1700503612]
1700509113
12.2.7 维度分解
1700509114
1700509115
维度分解是日志收集中在入库前的最后一个环节。所谓维度分解，就是把收集上来的消息格式分解成数据库或数据仓库可以识别并存储的格式（如图12-9所示）。
1700509116
1700509117
1700509118
1700509119
1700509120
图12-9 维度分解
1700509121
1700509122
在收到一条消息后，根据分隔符进行切割，把原来的一串字符切分成不同含义指代的维度信息。
1700509123
1700509124
在使用标准的GET或POST方式时，通常可以直接使用第三方提供的类（Class）进行拆分，把收到的信息转换成一个数组或哈希表，这也同样是一种Key-Value对的形式。
1700509125
1700509126
1700509127
如果是自定义的字符串格式，而且字符串中表示了多个不同的含义，需注意分割不要产生歧义，分隔符不应出现在维度的Key和Value中。所以，在自定义字符串格式的时候，推荐使用Base64对Key和Value进行编码。由于在Base64传输的字符中，只能由A～Z、a～z、0～9、“+”和“/”这64个字符和“=”作为正文内容，所以只要使用这些以外的字符作为分隔符，就可以保证信息不失真。这种方式的代价是编码后数据会比原始长度长约（这是工程经验值，在实际应用中仍然需要具体测算）。
1700509128
1700509129
在维度分解后进行保存时，建议保存一份原始消息数据作为存档信息，在类似HDFS这种可低成本扩容的分布式文件系统上进行压缩存储，在Hive、Oracle、MySQL或HBase等数据库（数据仓库）中保存一份分解后的维度与值的描述信息供查询与统计使用——前者供出现问题时进行倒查，后者供日常业务运营使用。
1700509130
1700509131
如果报送的字段内容不确定，而且随时可能扩展或者取消，尤其是在互联网这种变化极快的产品环境中，还是建议将它们放入类似Cassandra或HBase这样的NoSQL数据库中，不仅使用比较方便，更改的代价也比较小。
1700509132
1700509133
1700509134
1700509135
1700509136
数据科学家养成手册 [:1700503613]
1700509137
数据科学家养成手册 12.3 这只是不靠谱的开始
1700509138
1700509139
在一个复杂耦合的系统中，任何一个独立组件的有效性都会影响整个系统的有效性。就拿数据采集系统来说，每个采集点的有效性Pcollect、网络传输的可靠性Ptrans、服务器的有效性Pserver都会影响最终收集到的数据的有效性（或称“可靠性”）。如果没有办法直接从提供商那里得到这3个数值，就只能用其他办法进行测算了。
1700509140
1700509141
我们举个例子，假设能够测算出这3个值。
1700509142
1700509143
在测算过程中发现，Pcollect的有效性为99.9％，即平均1000条信息报送中会有1条信息由于收集终端的问题无法报送成功。
1700509144
1700509145
Ptrans有1％的失效概率（这个值已经很高了，说明运营商的网络状况非常不理想），那么Ptrans为99％。这里的失效概率不是丢包率，因为使用TCP协议族（包括HTTP和HTTPS）是有重传机制的，可以理解为网络层的故障、运营商的网络问题等导致在终端和服务器都正常的状态下无法访问的情况。
1700509146
1700509147
Pserver有0.1％的失效概率，即一段时间（例如1年）里有0.1％的时间处于无法工作的状态，而且这个时候也无法进行数据保存和重传。
1700509148
1700509149
