(一) 导论

本章仅讨论在没有大数据工具之前的传统数据架构，其中部分经验在当前大数据模式下也可以借鉴，权当抛砖引玉。

(二) 本文实践环境

数据库Oracle 11g ，宿主主机 IBM P595 ，16核*4线程，约300G内存，1*1000M的网卡，约60TB的有效使用存储阵列（好像是raid3）,性能相当于10多万的x86主机；ETL华为2288主机*6，配置 12*2线程、256GB内存，6*4TB raid0 存储盘，500G ssd 系统盘，1*10000M的网卡。

(三) 业务场景

某省运营商需要将实时的通信话单经过归类之后存储在数据库，按照T+1日或者按月统计的方式进行模型汇总，简化为实时入库，离线统计。

(四) ETL分析

百亿数据模型，第一个面临的问题是数据如何处理入库，数据入不了库，在高大上的模型都是空中楼阁。

特点之一数据量大，在本业务场景数据是实时推入系统，上游系统是通过离线文件不停推送到对应目录，以19年某月数据计算平均的每天条数为120亿条数据，由于通信话单所得的字段很多，平均一条话单长度是600多个字节，对应原始文件大小约为6TB（事后分析经过入库大约2TB，压缩之后大约1.6TB）。

特点之二数据混乱需要预处理，原始文件是一批批的文件推送到后端系统，每个文件将各种业务数据随机混在一起，我们需要实时将相同业务进行重新归类，写入到新的文件，这一步我们叫做分拣，由于分拣之后各种业务大小不一致，单位时间有些业务数据量很大，又有部分业务数据很少，产生很多碎片化数据，不管是特大文件加载还是碎文件加载，对于数据库来说都是灾难，为了解决这种数据不均衡的问题，新增一步合并，我们将碎文件进行合并，大文件进行拆分，我们根据经验设置单个文件不超过1GB，太大、太小都不利于数据库的加载，这个参数跟环境有关，数据合并之后就可以根据合并之后的文件进行加载，这个过程属于典型的传统过程。

(五) ETL关键点

这一步看似很简单，实际中间有很多经验点，我们道德经有句一生二,二生三,三生万物，很多道理都是相同的，做架构设计、优化，其实本质都是一样，最终是时空的平衡，时间与空间如何平衡是一门极大的学位，数仓的终极的艺术是让系统满载极限而不崩盘。

首先计算各种极限值

a)制约ETL的最大出口能力预估

DB的极限入库能力/小时：1000Mb/8*60秒*60分钟/1024/1024=0.429TB

DB的极限入库能力/天：0.429TB*24=10.299TB

平均最小处理能力/小时：6TB/24=0.25TB/小时

由于数据的流入不是均衡的，可能会参考如下图

那么实际我们的设计小时峰值处理能力，参考为平均值2倍=0.25*2=0.5TB/小时

但是我们的数据库处理能力为0.429TB/小时，0.429/0.25=1.716倍，

上图峰值倍率为900/500=1.8倍

从这个地方看数据库的IO制约了我们的峰值处理能力，所以我们建议是新增千兆网卡或者更换万兆网卡（小型机器原因无法更换万兆网卡），最终其他原因俩个都未实现，所以我们最终是按照数据库1000Mb网卡写入的最大速度设计ETL，即是DB的极限入库能力/小时=0.429TB

b)制约我们的另外因素-磁盘的IO分析

由于ETL集群采用的是普通sad盘而且做的raid1，写的速度大约100MB,读的速度大约为单快磁盘读的2倍大约300+MB，故制约因素磁盘在于写的方面。

故我们将写的场景进行分析主要有3个即推送、分拣、合并，考虑到冗余我们按照3.5倍来放大磁盘的写操作（前提是程序效率高，后期来看我们的程序前期也有问题，后面分析）。

写的数据量峰值/小时=峰值处理能力*3.5=0.429TB*3.5=1.5TB

峰值写入磁盘数=写的数据量峰值/小时/100MB=15个

按照我们的数据分析，需要最小的磁盘个数为15个，至于这15个磁盘，由多少主机来分摊，详细见下面计算。

c)制约我们的因素-网络带宽

大家都知道，电脑的网络不是无限的，现在一般X86主机的读写是万兆网卡，

单台主机读写/小时=10000MB/8/1024/1024*60*60=4.292TB/小时，远远大于上面的DB的极限入库能力/小时=0.429TB，是10倍于后端的能力，故忽略

d)制约我们的因素-内存

内存确实也会制约我们的软件运行，但是目前一般的主机都是动辄上百GB的内存，所以影响微乎其微，更多的考虑的是并发的进程数量与总内存的关系，内存制约需要考虑单位时间在数据装载排序、加载到数据库文件大小，而且linux有优化机制，数据缓存机制，所以一般看到内存使用满不要觉得奇怪。

e)制约我们的因素-软件的优化

我们整个过程有几个主要因素：TCP接收数据、分拣、合并、加载 这4个子作业，其中TCP进程接收数据进程很少，消耗也小，故本次忽略，合并、加载对单一文件作业也是只做一次，不是本次重点的处理对象，主要的优化对象分拣。

分拣原始逻辑采用脚本写的程序：分拣原始程序是将单一文件逐行按照业务类型循环遍历找到对应代码，生产对应代码规范文件，一个文件完成之后，生成所有控制文件，假设文件10万行，业务类型60种，一共需要循环600万次，一共写磁盘IO 10万次，可以看出效率很有问题，而且大量调用了系统命令，大量高密度调用系统命令会造成kernel 使用过高，容易CPU 100%，造成全局崩盘。

分拣优化逻辑采用Java重构：由于所有文件开头前2位是业务代码，我们直接将所有数据装载进内存，然后按照代码前2位进行排序，排序完毕之后，直接按照代码规则写入到对应文件，按照上面预估，单次排序10万个之后就可以完毕，总共写磁盘IO 60次。经过多次测试，实际俩种分拣单一程序时间差别不是很大，而且java消耗内存还比老的大多了，是不是有点失落了，不是的，直接写结论，换个角度看磁盘写的次数完全不是一个数量级，减少磁盘的写入次数，能有效提升磁盘的利用率，降低CPU的使用率。

加载的优化：我们使用的是oracle的sqlload加载数据，sqlload默认加载是64行提交一次，比较影响速度，我们调整为1000行，能提升30%加载速度。

控制程序的优化：由于我们的程序需要频繁读写，我们将所有应用程序、配置文件都放在系统目录下面，享受ssd硬盘极速。

f)制约我们的因素-CPU计算能力

关于CPU的使用计算，跟应用相关度很大，不同的程序占用的CPU也千差万别，比较难以计算，一般推导是根据单进程使用CPU的占比来预估最大进程数，按照峰值使用到80%来计算慢负荷，需要做性能测试，在我们这次测试中发现单一主机建议承受能力为4个进程，故最终我们采用了4个主机*4进程=16个进程的方案。

g)管控的艺术-综合协调

我们系统有各种业务类型进程，从数据的接入、分拣、合并、加载都支持多线程并行处理，如何让系统使用高而不奔溃，需要我们平衡各个阶段的进程个数，如分拣比较消耗CPU、内存、磁盘，我们就严格设置分拣的进程，控制住最大入口的数据，保证每个小时最大数据处理量，不至于分拣受到数据峰值大幅度波动，因为分拣资源一旦占用多了之后，会影响后面，造成大家都处理不了，在数据稍微低下来之后，系统会自动跟上处理。

在这个过程中，需要我们综合分析各种业务的使用情况及不断实际调参，并发数、承载量不是说越多越好，在复杂的情况下，需要考虑到链路带宽、同链路核心业务、防火墙承受力等（之前遇到过，以后有机会分享一个高并发、高数据量ETL项目的实践过程），我们追求的是某一个平衡点，这才是我们追求最完美的。

今天暂且这些，很多知识需要在讨论之中产生火花，数据分享产生价值。