关于 ETL 过程如何保证数据量的准确性和数据的正确性的讨论
Flywolf2000
这个问题很简单，就是 ETL 过程中，你怎么保证数据的准确性，这个准确性包含两个方面：数据量的准确性，数值的正确性。这个问题看起来很简单，但是却包含很多内容：
A 、字符集的转换 —— 怎么将基于不同字符集的数据转换到目的数据库 。
B 、数据量的准确性 —— 使用 ETL 工具的质量监控工具就那么准么？我可遇到过不准的情况哦。
C 、discard 的数据怎么重新能够加载回目的数据库中（ ETL 已经完毕了，并不是所有的数据能够重新加载进取的）。
B 、数据量的准确性 —— 使用 ETL 工具的质量监控工具就那么准么？我可遇到过不准的情况哦。
C 、discard 的数据怎么重新能够加载回目的数据库中（ ETL 已经完毕了，并不是所有的数据能够重新加载进取的）。
D 、 ETL 一般都是在晚上生产库结束后进行的，如果第二天发现 ETL 数据不对，怎么保证还能够抽取到昨天的业务数据？
E 、一个指标的计算是经过多层次的抽取后完成的，怎么保证在抽取的过程中数值精度不丢失？怎么让业务人员理解其指标进行运算的过程（ ETL 抽取的时提供的可是技术元数据，客户所关心的可是业务员数据）？
wxlmail2008
D 的回答，好像会很麻烦吧，比如在分布式的情况下，抽取的数据是多个库的，而且源数据库（事物数据库）是很烦忙的，总不能停机处理把（特别是在金融，电信领域），不过我知道他们是有备用数据库的（我不太清楚该术语，就用这个备用数据库代替了），就是一旦某一数据库宕掉，会自动启用另一数据库（这种备用数据库也不只一个），是不是可以用备用数据库来抽取昨天的业务数据呢？
不知对不，偶想也不只一种方法吧，望 LZ 给予指正！
不知对不，偶想也不只一种方法吧，望 LZ 给予指正！
hskd-iceman
我的理解：
A 、如果数据源比较多而且字符集都不一样的话，字符集的转换的确是比较麻烦的，不过我想如果能够保证目标数据库的字符集是其它源数据库字符集的超集，或者是大部分源数据库字符集的超集，我想这样的麻烦可以减少很多。
B 、如果 ETL 处理的表比较多，那么除了用监控工具之外，我想不到有什么其它好的方法，或者可以写写过程之类的，让它定期运行，获取你关心的一些数据指标。
C 、 ETL 已经完毕了，并不是所有的数据能够重新加载进取的？这个我不是很明白为什么不能重新加载进取？
D 、这一点的话楼上的建议也不错，我们现在一般不到生产库抽取数据，数据都是在备机上取的，因为直接到生产库抽数据会影响到正常的业务办理，这种方式不是很好。不过如果没有备机的话，那也只能从生产机上取了，不过不是很明白为什么不能抽到昨天的业务数据？如果要保证抽到昨天的业务数据，既然技术上实现不了，那只能通过别的途径了，是否可能跟客户谈谈，改变这种方式？
E 、这个也是个问题，有时我们只能引导客户。
A 、如果数据源比较多而且字符集都不一样的话，字符集的转换的确是比较麻烦的，不过我想如果能够保证目标数据库的字符集是其它源数据库字符集的超集，或者是大部分源数据库字符集的超集，我想这样的麻烦可以减少很多。
B 、如果 ETL 处理的表比较多，那么除了用监控工具之外，我想不到有什么其它好的方法，或者可以写写过程之类的，让它定期运行，获取你关心的一些数据指标。
C 、 ETL 已经完毕了，并不是所有的数据能够重新加载进取的？这个我不是很明白为什么不能重新加载进取？
D 、这一点的话楼上的建议也不错，我们现在一般不到生产库抽取数据，数据都是在备机上取的，因为直接到生产库抽数据会影响到正常的业务办理，这种方式不是很好。不过如果没有备机的话，那也只能从生产机上取了，不过不是很明白为什么不能抽到昨天的业务数据？如果要保证抽到昨天的业务数据，既然技术上实现不了，那只能通过别的途径了，是否可能跟客户谈谈，改变这种方式？
E 、这个也是个问题，有时我们只能引导客户。
我的理解比较肤浅，希望大家都来讨论讨论。
Bq_wang
这个问题很简单，就是 ETL 过程中，你怎么保证数据的准确性，这个准确性包含两个方面：数据量的准确性，数值的正确性。
这个问题看起来很简单，但是却包含很多内容：
这个问题看起来很简单，但是却包含很多内容：
A 、字符集的转换 —— 怎么将基于不同字符集的数据转换到目的数据库。 ITPUB
B 、数据量的准确性 —— 使用 ETL 工具的质量监控工具就那么准么？我可遇到过不准的情况哦。
-- 这个很难，我建议在不符合标准的数据上做个记号，全部写入到数据仓库中
C 、 discard 的数据怎么重新能够加载回目的数据库中（ ETL 已经完毕了，并不是所有的数据能够重新加载进取的）。
-- 通上，不符合条件数据的维度值给以一些缺省值，一般情况下流水作业很难重新补登再入库的
D 、 ETL 一般都是在晚上生产库结束后进行的，如果第二天发现 ETL 数据不对，怎么保证还能够抽取到昨天的业务数据？做个好的脚本，只负责删除和处理某个时间段的数据
B 、数据量的准确性 —— 使用 ETL 工具的质量监控工具就那么准么？我可遇到过不准的情况哦。
-- 这个很难，我建议在不符合标准的数据上做个记号，全部写入到数据仓库中
C 、 discard 的数据怎么重新能够加载回目的数据库中（ ETL 已经完毕了，并不是所有的数据能够重新加载进取的）。
-- 通上，不符合条件数据的维度值给以一些缺省值，一般情况下流水作业很难重新补登再入库的
D 、 ETL 一般都是在晚上生产库结束后进行的，如果第二天发现 ETL 数据不对，怎么保证还能够抽取到昨天的业务数据？做个好的脚本，只负责删除和处理某个时间段的数据
E 、一个指标的计算是经过多层次的抽取后完成的，怎么保证在抽取的过程中数值精度不丢失？怎么让业务人员理解其指标
进行运算的过程（ ETL 抽取的时提供的可是技术元数据，客户所关心的可是业务员数据）？
自己理解后，做好元数据维护和释义
进行运算的过程（ ETL 抽取的时提供的可是技术元数据，客户所关心的可是业务员数据）？
自己理解后，做好元数据维护和释义
innovate511
做个简单的补充，这些问题是最常见的 ETL 数据控制的问题，最好用治本的办法： ETL 工作流控制＋控制表双重控制，同时 ETL 开发留出接口，让客户可以非正常情况下重新抽取（有的时候客户要求很怪， ETL 开发无法全部控制）。控制表我以前提到过，可以分为数据准确性控制表和 ETL 控制表两大类。而控制表有两种设计方法，一是由数据组成，二是直接存储逻辑（动态 SQL ），两者各有优势，数据组成的非常灵活，而逻辑组成的则方便管理 ，我都玩过，有机会可以一起探讨下。 保持数据精度不丢失，这得看客户的需求，所以人们说到数据集市层的时候，数据粒度可以比较大，但也可以小到最低粒度，这样数据精度可以一直完好保存。如果是客户技术人员，就给他看技术元数据，如果是最终用户，就看业务元数据，或者直接对前端 UAT ，最终用户一般只要他们要的报表或者分析准确，满足他们的需求就行了。
piliskys
估计这只是理论的解决，实际中应该是不好使的
就说两个吧 c, 不符合条件数据的维度 -- 很多时候不符合条件的是五花八门的，什么情况都可能，所以无法预先知道哪些是不符合条件的，
d, 不是所有数据只是插入操作，在业务系统中更新操作的数据很多，而且不是所有都有时间字段的， 具体问题还是要具体分析 ITPUB个人空间1P�gEw1ye`
很多时候理论上是如此，事实却是另一面，这就是为什么有很多好的数据仓库方面的书籍而难有很好的数据仓库的实际项目
就说两个吧 c, 不符合条件数据的维度 -- 很多时候不符合条件的是五花八门的，什么情况都可能，所以无法预先知道哪些是不符合条件的，
d, 不是所有数据只是插入操作，在业务系统中更新操作的数据很多，而且不是所有都有时间字段的， 具体问题还是要具体分析 ITPUB个人空间1P�gEw1ye`
很多时候理论上是如此，事实却是另一面，这就是为什么有很多好的数据仓库方面的书籍而难有很好的数据仓库的实际项目
xx_adam
B ，我个人觉得对照业务系统数据记录条数和导入之后的记录条数进行比较，一致应该是准确的，不过 DW 中的表要建好主键约束
D, 一般情况下，业务系统会有一个时间戳，从昨天的时间戳重新抽取。
E, 在每一步的计算机中尽可能保留多的小数据位数据，不进行四舍五入
D, 一般情况下，业务系统会有一个时间戳，从昨天的时间戳重新抽取。
E, 在每一步的计算机中尽可能保留多的小数据位数据，不进行四舍五入
mingjian129
对照业务系统数据记录条数和导入之后的记录条数进行比较，如果一樣則很好辦，但是如果記錄數不一致的話，比較難去判斷哪些是已經導入的？哪些是沒有導入的？單純以時間戳的話是沒辦法去判斷的，而且如果從昨天的時間戳重新抽取的話，那么务必要刪掉已經導入的數據。
gushangzao007
D 、 ETL 一般都是在晚上生产库结束后进行的，如果第二天发现 ETL 数据不对，怎么保证还能够抽取到昨天的业务数据？ ITPUB个人空间R�T
回复：呵呵，如果用户可以接受的话，我一般把 ETL 执行安排在第二天的凌晨开始，从第二天凌晨开始抽取第一天的数据。
E 、一个指标的计算是经过多层次的抽取后完成的，怎么保证在抽取的过程中数值精度不丢失？怎么让业务人员理解其指标进行运算的过程（ ETL 抽取的时提供的可是技术元数据，客户所关心的可是业务员数据）？
回复：我认为在 ETL 的过程中不对数值型数据据进行四舍五入操作，可有效防止数据精度不丢失，至于客户想看到多少位的精度，我们可以在前端展现中对数据进行格式化。为了让业务人员能更好的理解指标的运算过程，我们一般在展现层以文字或在线帮助的形式对可能会引起歧义的指标给出后台的计算公式，帮助用户更好的理解指标含义。
回复：呵呵，如果用户可以接受的话，我一般把 ETL 执行安排在第二天的凌晨开始，从第二天凌晨开始抽取第一天的数据。
E 、一个指标的计算是经过多层次的抽取后完成的，怎么保证在抽取的过程中数值精度不丢失？怎么让业务人员理解其指标进行运算的过程（ ETL 抽取的时提供的可是技术元数据，客户所关心的可是业务员数据）？
回复：我认为在 ETL 的过程中不对数值型数据据进行四舍五入操作，可有效防止数据精度不丢失，至于客户想看到多少位的精度，我们可以在前端展现中对数据进行格式化。为了让业务人员能更好的理解指标的运算过程，我们一般在展现层以文字或在线帮助的形式对可能会引起歧义的指标给出后台的计算公式，帮助用户更好的理解指标含义。
flywolf2000
今天冒个泡说两句：
对于 A 问题字符集 bq_wang 说的是很贴切的，一般来说为了确保安全该使用字符集的超集合，对于 Oracle 数据库来说，是可以转换字符集的，也就是说不同种字符集之间 Oracle 会自动给你转换，这个部分抽时间我传个最近整理的字符集 ppt ，大家看看 就知道了，但是我们这里讨论的不仅仅是 Oracle 数据库，这个时候你就要同时考虑操作系统字符集、客户端字符集、数据库字符集甚至应用程序字符集的问题。而最关键的是要看你抽取的数据是否落地，并且在落地的同时有没有进行字符集的转换
例如：如果从一个字符集的操作系统中导出来数据，传输过程中几次落地，但是仅仅是落地存储，即使落地的操作系统、客户端的字符集再怎么相互不兼容，这也不会影响了源数据。一般来说都会在 ETL 前详细调查源的字符集以落地解析的字符集以及目的地的字符集，如果这个过程是字符集的子集以及超级的话那当然最好了，如果不是那么就要评估数据的损失量或者制定 ASCII 的转换机制，因为字符集说白了就是将 “ 字 ” 存储为 ASCII 码，而这个 ASCII 在另个字符集展现中是什么样子的问题。
B 数据量准确性问题，说实话至今好像还没有什么好的方法，因为 ETL 不是数据平移 ---- 用个 count 统计对比就能知道数据量是否正确，当一个指标是经过多次 join 、过滤、判断、计算以后就已经很难保证抽取过来的数据是否在量上是正确的，一般我这边采取的方法是定义抽样检测，得出一定的概率，这个概率就算是指标体系的一个误差了。
C bq_wang 和其他人说的都有道理，有些业务数据在当天做完 ETL 的 EOD 以后是没有办法再重新单独抽取的，在这种情况下要么 制定手工更改抽取的指标；要么启用前一天业务数据备份 ，再另一个环境下在人为的干预下重新跑一次该模块的 ETL 流程。而对于一些仅仅是静态平移、简单清洗的数据当然就不用这么麻烦了。
今天冒个泡说两句：
对于 A 问题字符集 bq_wang 说的是很贴切的，一般来说为了确保安全该使用字符集的超集合，对于 Oracle 数据库来说，是可以转换字符集的，也就是说不同种字符集之间 Oracle 会自动给你转换，这个部分抽时间我传个最近整理的字符集 ppt ，大家看看 就知道了，但是我们这里讨论的不仅仅是 Oracle 数据库，这个时候你就要同时考虑操作系统字符集、客户端字符集、数据库字符集甚至应用程序字符集的问题。而最关键的是要看你抽取的数据是否落地，并且在落地的同时有没有进行字符集的转换
例如：如果从一个字符集的操作系统中导出来数据，传输过程中几次落地，但是仅仅是落地存储，即使落地的操作系统、客户端的字符集再怎么相互不兼容，这也不会影响了源数据。一般来说都会在 ETL 前详细调查源的字符集以落地解析的字符集以及目的地的字符集，如果这个过程是字符集的子集以及超级的话那当然最好了，如果不是那么就要评估数据的损失量或者制定 ASCII 的转换机制，因为字符集说白了就是将 “ 字 ” 存储为 ASCII 码，而这个 ASCII 在另个字符集展现中是什么样子的问题。
B 数据量准确性问题，说实话至今好像还没有什么好的方法，因为 ETL 不是数据平移 ---- 用个 count 统计对比就能知道数据量是否正确，当一个指标是经过多次 join 、过滤、判断、计算以后就已经很难保证抽取过来的数据是否在量上是正确的，一般我这边采取的方法是定义抽样检测，得出一定的概率，这个概率就算是指标体系的一个误差了。
C bq_wang 和其他人说的都有道理，有些业务数据在当天做完 ETL 的 EOD 以后是没有办法再重新单独抽取的，在这种情况下要么 制定手工更改抽取的指标；要么启用前一天业务数据备份 ，再另一个环境下在人为的干预下重新跑一次该模块的 ETL 流程。而对于一些仅仅是静态平移、简单清洗的数据当然就不用这么麻烦了。
这个问题上我发现大家的想法都不太对，一般来说对于生产库的一些关键×××易数据都是要每天在抽取的之前做一次逻辑的备份 ——
就是类似于 create table table_name_2008_1_5 as select * from .... ，一旦第二天发现抽取问题，还有昨天的静态数据源；而 对于流水性质的数据来说我们就可以不用做 tmp 表而在第二天还能重新抽取了，但是对于那种可以删除流水的业务系统就有点 变态了：
就是类似于 create table table_name_2008_1_5 as select * from .... ，一旦第二天发现抽取问题，还有昨天的静态数据源；而 对于流水性质的数据来说我们就可以不用做 tmp 表而在第二天还能重新抽取了，但是对于那种可以删除流水的业务系统就有点 变态了：
今天就先不说了，准备迷糊了，上面这些问题希望大家继续深层讨论，东西还是很多的。
大家别仅仅就考虑我提出来的这 A--E 五个方面，可以集思广益，多谈谈大家在实际工作中遇到的问题。好了，今天就罗嗦到这里，欢迎大家来拍砖头。
大家别仅仅就考虑我提出来的这 A--E 五个方面，可以集思广益，多谈谈大家在实际工作中遇到的问题。好了，今天就罗嗦到这里，欢迎大家来拍砖头。
这个问题看起来很简单，但是却包含很多内容：
A 、字符集的转换 —— 怎么将基于不同字符集的数据转换到目的数据库。
B 、数据量的准确性 —— 使用 ETL 工具的质量监控工具就那么准么？我可遇到过不准的情况哦。
A 、字符集的转换 —— 怎么将基于不同字符集的数据转换到目的数据库。
B 、数据量的准确性 —— 使用 ETL 工具的质量监控工具就那么准么？我可遇到过不准的情况哦。
C 、 discard 的数据怎么重新能够加载回目的数据库中（ ETL 已经完毕了，并不是所有的数据能够重新加载进取的）。
