架构师手记 16 个性化标签架构设计V0.1
第一年末总的用户行为日志数据量 = 年初数据量（无，即0） + （目前每日增长量20 G + 第一年末预计每日增长量50 G）/ 2 * 365 = 12.775T 同理可以算出其他数据的第一年末的估计数据量，你们可以算一下，我就不算了。 通过上述方法，我们算出第一年末总数据量为X1，第二年末总数据量为X2，第三年末总数据量为X3。这些数据用于估算在武汉的大数据中心每年需要多少磁盘存储来存放数据。 现在，你自己可以算出来，如果现有10台PC服务器的磁盘都是2.4T，如果使用HDFS存放文件，数据冗余为2，按现有的数据增长量，大概能够支持120天左右，当然实际情况下，必须要预留一些磁盘空间，不可能用到100%，所以连120天都支持不到。 注意，这还没有算上个性化标签系统的应用服务器和数据库需要的机器，如果要都做集群，应用服务器和数据库各需要2台机器。 很明显，10台PC服务器远远不够。 这个时候，就需要找公司要额外的预算来买机器了。
为什么要买额外的机器？不买有什么后果？买多少台？分几次买？ 这些都是要预算时需要回答的问题，而上面的整个过程，就是答案。
同样，根据上面的表格，我们可以算出来第一年初每天需要从厦门机房传输到武汉机房的数据量，每天需要从北京机房传输到武汉机房的数据量，然后计算出第二年、第三年每天需要从两个机房传输到武汉机房的数据量。这个数据量用于评估厦门机房到武汉机房之间、北京机房到武汉机房的专线带宽各需要多宽，这个带宽在未来3年如何增长。 最后，根据上述过程中估算出的数据，我们就可以进一步考虑数据的压缩传输、存储、归档等相关设计了，按下不表。 在很多场景下，架构师还需要评估服务器的CPU计算能力要求和内存要求。但在大数据的场景下，一般都不太关心单台机器的CPU和内存。就我的个人经历来说，都是要求“配满”。即CPU能上多高的频就上多高的频，内存能配多大就配多大。因为单台机器实在是便宜，1U的2万5千一台，2U的5万一台。 如果架构师无法获知现状，也不能对将来做出准确的预估，怎么办？
办法也是有的，可以从项目预算逆推。比如项目整体预算是500万，包括：硬件预算是150万，网络费用是100万，研发费用是200万，其余杂费50万。不过这种项目一般都是风险多多，火坑多多，黑锅多多，切记多做预防措施。 另外一方面，我们还需要分析一下个性化标签系统对已有系统的影响和依赖。 数据抽取是一件很影响性能的事情，所以如果个性化标签系统在白天直接从订单系统开始抽取数据，设计出此行为的架构师会被拖出来游街的。一般来说，数据抽取都是从业务系统的备份数据库中抽取的，而且也是在晚上12点之后开始抽取。但讨厌的是，有些业务系统会使用备份数据库计算一些报表或干别的用途，遇到这种情况，需要和对应的开发人员和业务人员都聊一聊，评估数据抽取的影响，来决定抽取的时间和方式。 日志文件的抽取会麻烦一些。对于一个业务系统，日志文件会分布在多台机器上。每个业务系统的日志配置也不同，比如每天写一个新日志文件，或者文件大小超过1G才写一个新日志文件，这些日志的配置也是架构师需要了解的。 总之，数据抽取不要影响到现有系统的运行。 数据抽取需要知道表结构、表关系、表字段说明、日志格式，这些就是个性化标签系统对已有系统的隐性依赖，也是风险高发区。因为一般来说，当你需要表结构、表关系、表字段说明的时候，你会发现没有什么参考文档；当你需要日志格式说明的时候，你会发现也没有什么参考文档，或者日志是程序员随意输出的。这时，架构师需要额外的人手，从各业务系统的开发人员、测试人员的脑子里面，把这些必须的信息挖掘出来，整理写成文档。
