为什么Excel数据需要导入数据库？为什么不直接把数据规规矩矩的录入数据库中再使用？

原因很多。比如企业就是有很多历史Excel文件的包袱，或者上下游业务流程中会产生Excel文件，或者一谈到数据库就和建系统花大钱费时间这种事儿联系到了一起，也就没动力去干了。

那为啥数据不直接在Excel中使用呢？用肯定是能用的，毕竟Excel透视表，PowerBI之类的溜的飞起。但这二者能玩得转的前提，是Excel的数据格式必须非常标准，透视表乃至BI工具才有用武之地。如果数据分散在多个Excel文件的多个Sheet里面，长相有点类似但又不完全一样，那就还要走一遍Excel数据解析入库的标准化路线，这类BI工具才能发挥自己的优势。

但凡ETL工具或者BI工具，都宣称自己能导入Excel文件，没错，是的，但它们只能处理这种最简单和标准的格式：

简单的excel格式

在kettle里面怎么弄呢，选个Excel Input的节点，选中文件，选择sheet，Fields里面点下按钮，然后表头就被识别出来了：

在kettle中预览下列类型

Preview rows一下，恩，数据都ok，那就直接入库吧

kettle中preview数据的结果

如果Excel文件都是这种简单款，那就没必要往下面再看了。随便BAIDU一下，就能解决99.9999%类似文件的入库问题。

很多时候，我们的Excel文件中会有较复杂的格式，比如这样的：

图1

图2

图3

这个是其中一个sheet打开后，左侧的样子。首先3张图的A列区分出了3个类型，对应“本期数据及预测修正”，”本期数据”，“上期数据”，且是合并单元格。

以图1为例，B列中包含了“供给，消费，库存净流出，期末库存”三个数据大类。“供给”里面，按地区又分OECD，非OECD两个地域大类，每个地域里面再细分诸如：美国本土，加拿大，墨西哥等。

再看第二行横向的日期。从D到O列是2012年月份值，P列是2012年的Total（合计）值，一直到W列（截图右边未截完整）是2013年的值。【图1】中D2单元格中的值是Jan，E2单元格中的值是Feb。第一行中的2012（年份），加上第二行的Jan，Feb，Mar，......Dec这些月份的英文名，组合成为月份。

但，格式不会就这么简单，再看往右边拖拉滚动条后的数值格式。

2018年的日期值格式变了

可以发现，从2018年开始（CD2单元格），原本第二行里面的Jan，Feb，Mar等英文单词，变成了2018/1/17这样的标准日期格式。

带有预测值的月份和年份

再往右边拖一点，到了2023年的时候，年份后面多了E，这是estimate（预测值）的意思。EQ2单元格，里面是Jan-23E的字样，因为11月份还没结束，这个值也是预测值。到次我们总结下该文件里面单一sheet中的3种日期格式：

第一种：2000（年份）+ Mar（月份），两行组成日期

第二种：2000/01/01，单行是日期，上面的年份是冗余项

第三种：2000E（年份）+ Jan-23E（英文缩写+天），两行组成日期

至此，这个文件的结构分析完毕。

对这个例子，ETL工具肯定是没法胜任的了。kettle这种，如上所述最多只能处理简单的行、列、且日期在列上的数据格式。某些BI工具呢，对Excel格式的要求和ETL工具基本一致，也就是格式要标准，不能有合并单元格，格式中不能有复杂变化。像上面这种，2行组合成为日期，还有3种形式，变来变去，最后又出现预测值这么复杂的情况，还是算了吧。况且，工具对A，B的文字列内的层级关系“供给 - OECD - 美国本土”这种，更加是没辙的。

诚然，这种事情写程序肯定是能搞定的，但成本极高。每个文件的每个sheet长的都不一样，找人一个个的去写程序读取么？后面格式稍微变一下，这跟着调整的工作量就得折腾s人。而且，还得要求写程序的人有一定的数据规划功底，至少TA能定义出数据入库后表的结构，因为Excel不是为了解析而解析，而是要让入库后的数据更易用。

这样的Excel解析到数据库中后，应该是什么样子呢？我们可以看一下：

原文件与数据库数值的映射

先看IF_FORECAST（是否预测值）字段，2022年10月是0，表示是真实值；2022年11月之后是1，表示是预测值。单就在入库的数据行中区分是否预测值这一个点，工具就做不到，写代码也要扑腾一下才能搞定。

再看VIEW（视角）字段，原先sheet中的A列体现在这，区分“本期数据及预测修正”，”本期数据”，“上期数据”三种类型。

REGION_TYPE（地域类型）字段，源文件中分“OECD”和“非OECD”两种，非标对应上图的红色和蓝色框的区域，VALUE列与EM列的值对应。

“供给，消费，库存净流出，期末库存”这个数据类型，体现在数据库表的DATA_TYPE字段中。上图截图部分因篇幅只包含了“消费”和“供给”，但已经足够看出Excel中数值和维度，与数据库表中的映射关系了。

该示例文件的解析，至少要在数据库中实现类似的表结构，才算基本包含了原始文件的全部信息量。这时，去做一些分析，比如统计OECD区域中，美国本土供给量的季度趋势，或者OECD区域与非OECD区域总体均值的对比情况，才会比较方便。