不吐不快-记录一次千万级数据统计

不吐不快-记录一次千万级数据统计

六月 04, 2020 阅读量

不吐不快-记录一次千万级数据统计

吐槽专用，没啥干货

数据

甲方发来了两个压缩包，一个Google的，一个IOS的游戏充值数据。因为数据量较大，超出了Excel的处理范围，只好让我们来处理分析。Google里面原始数据有10G，还有他们自己拆分的csv文件（Excel超过1048576行后无法完全加载文件），这也为以后的操作埋下了雷。IOS的很小，txt文本文件，合计15M，但是后期计算却花费了不少时间。
Google字段：Description,Transaction Date,Transaction Time,Tax Type,Transaction Type,Refund Type,Product Title,Product id,Product Type,Sku Id,Hardware,Buyer Country,Buyer State,Buyer Postal Code,Buyer Currency,Amount (Buyer Currency),Currency Conversion Rate,Merchant Currency,Amount (Merchant Currency)
IOS字段：Start Date,End Date,UPC,ISRC/ISBN,Vendor Identifier,Quantity,Partner Share,Extended Partner Share,Partner Share Currency,Sales or Return,Apple Identifier,Artist/Show/Developer/Author,Title,Label/Studio/Network/Developer/Publisher,Grid,Product Type Identifier,ISAN/Other Identifier,Country Of Sale,Pre-order Flag,Promo Code,Customer Price,Customer Currency

处理

  1. 首先对Google的一个渠道数据进行处理，先用了他们给的拆分数据，根据月份划分文件夹，每个文件夹里有3个csv文件。通过批处理复制到同一目录下，通过copy *.csv all.csv来合并为一个csv文件。因为之前的数据分析用的SQLServer数据库，效率比较好，一亿多的数据量秒级导入。但是这次就不行了，ManagementStudio的导入无法识别csv文件，通过平面文件源只能以,号来分割。但是因为有107格式的英文日期Jan 1, 2019，导致列错位。另外字段Buyer State是按照当地语言的，乱码导致无法通过验证。尝试了很久无果，就用Navicate导入，但是速度很慢。
    第一次导入1800万数据，用时接近3小时，传输速率在7Mbps左右。

    然后根据月份分组查看，发现缺少2月份的数据（11月份拆分数据异常，只有1k，未导入）。然后用certutil -hashfile filename MD5复查数据，发现拆分好的数据1月和2月居然是一样的（想打人），压缩包的CRC32也是一样的。

    无奈和甲方沟通，让使用原始数据……然后又导入一遍，1900万数据，用时3个多小时，弄到公司只剩我一个人。

  2. 第二天对另外一个渠道进行处理，这次鉴于前面的情况，直接用原始数据。然而二月份的压缩包居然是坏的（被他们玩坏了吧），经过沟通让使用他们拆分好的文件。这次按照季度汇总，分了四个表，四倍速导入。千兆带宽还是很给力的。

    导入3000多万数据，一个半小时，传输速率在30Mbps左右。

    然后计算的时候又暴雷了（哎）。经排查2月份部分数据因为拆分出的字段Buyer State乱码，导致后面的字段全部向前偏移。因为要用到后面的字段就通过update语句修改了数据。然而把字段位置修正，然而格式转换的时候还是报错，看数据没啥问题，复制粘贴出来，感觉多出一个换号符，然后通过Len发现确实多了一个长度，通过replace替换CHAR(13)后转换正常。

  3. 又过了一天，最后对IOS的数据处理，以为很快，然而也是个坑。就14万数据，导入很快，没啥问题，就是计算的时候来回沟通了好几次。Google是每条都计算好的，IOS不是，没有汇率，只有客户的货币。不是很清楚游戏划分种类，根据字段Vendor Identifier（和Apple Identifier一一对应）来划分，有1170种……再按月份，货币划分，最后统计出9万数据。显然这个不行，后来的想法是根据新提供过来的每月汇率来来计算出人民币。没有汇率的货币就远远本本表示，最后各整理出8千和9千的数据。不知道以后还会提出啥要求。以防万一，SQL都保存了，因为写的比较复杂。

结语

还好是按工作量算钱的，不过甲方就是甲方。
能看完的都是勇士（手动滑稽）。