关于数据、数据流、数据管道的一些看法（二）

数据猿数据流数据管道大数据

Austin Liu | 2019-11-11 10:31

【数据猿导读】再来一波硬科普

这个系列的上一篇就是写关于ETL 名字叫数据，数据流，数据管道（点这里阅读）现在补充一些事情，算是对上一篇内容有一个交代。

上篇提到了大数据，众多种类的数据库如何将数据灌入到大数据的那块“处女地”。看似容易，实际上问题那是梵天的星星，一般获取数据时你会遇到什么问题。

1 数据库的种类的问题，有人说了哎，你用一种数据库不就完事了，好吧，说这样话的人我就直接跳过，现在哪家公司只用一种数据库的，你传统数据库就算是一种，你NOSQL 的数据库就一个没有，如果真是这样，我只能给你送365个祝福了，估计你公司的业务也需要祝福了吧？

2 数据库里面的表的数据结构千奇百怪，现在公司里面的尤其是第三方开发的项目，那是没法看，表里面字段七扭八歪的不说，各种奇葩的字段名是只有你想不到（你见过用汉语拼音简写的字段名吗，我见过），还有没有让传统ETL工具能进行增量提取数据的有效时间字段，如果将这些都怪罪到开发的头上，有时候是不公平的，有的表的确有时间字段，但时间字段的含义，变动都不是为BIG DATA 服务的，而如果让开发应用的工程师在开发系统之前还要考虑BIG DATA的需求，未免有点强人所难了。

3 实时计算的大数据项目，目前我们就有业务部门需要5 - 10 分钟一次获得当前的CALL CENTER 的工作情况，数据量不少，如果每次在应用服务器来操作，势必给业务带来影响，而放到BIG DATA 的问题就是，不能实时运算，难道大数据的实时数据分析，还要不断的借助各种传统的ETL 的增量数据提取？？？ OMG

4 字段的变更，在开发部门业务的需求以及字段的变更，增加，是常有的事情，传统的ETL 工具一般只要是你数据源的字段变化了，趴窝的几率会很高，不是字段顺序与源和目的端不一致的问题，就是字段的源与目的之间的字段缺斤短两，如果能有一个ETL 能进行相关的元数据管理，那将是涉及这些变化的开发，运维，BIG DATA 之间的福音。

5 ETL 在数据的权限管理上，传统的ETL 工具也是问题多多，而有一个良好的用户权限的管理，从与技术无关的角度来说，至少你公司的审计，你公司的安全部门，都的过问此事，尤其外企，对数据的流向，权限那是很重视的。

但实际上，以上5条能达到的ETL工具少之又少，但各种炫技，提供各种高大上的界面，以及各种出自名师的开源离线同步工具,并且加上各种并行任务，告诉你抽取数据有多快怎么把表给你分成100个TASK，提供各种数据质量的监控，解决数据失真的问题等等等等，那是一个比一个牛，在撕开外衣后，里面的棉絮能呛死你。

所以，一个ETL 几家欢喜，几家愁， ETL 工具最重要的点要搞清楚，否则和姑娘买车一样，看颜色，看内饰，看销售的小哥哥，就是不看发动机，变速箱，底盘这三大件，那就只能是小伙子火力壮，门外凉快去。
这三大件是什么

1 实时的数据流，从数据库底层做功课而不是去用SQL 来去提取数据。
2 支持多种数据库之间，数据库与大数据产品之间的任意往来
3 元数据管理，避免多个department 的罗圈架

当然从贵到喊“爹娘 ”的ETL 到免费被吹捧到天上的 ETL 工具，此时大部分都变得不再喧嚣，因为什么，因为不行。

一个产品的好坏，最重要的是能解决用户的痛点的问题，如同我买车，我说我家里的路坑坑洼洼，我要底盘高的，动力好的，你给我来一个兰坡基尼，告诉我如何的快，如何的炫，如何马力强劲，如何能0 首付，我此时只能说，我勒个去。

那ETL 工具中如何能侵入到数据库内部，与数据的上层逻辑剥离，直接提取数据才是一种功夫，至少人家对各种数据库都的有相关的研究，而不是花里胡哨通过各种界面，各种并发，来填补内心的空虚，说句实话，你不知道你面对的表是什么情况，如同你初入社会，你不知道你遇到的会是“绿茶”，还是“掉渣烧饼”。那怎么能搞定“绿茶”，“掉渣烧饼”，才是考验你ETL工具的试金石。

说道这里，还的说另外一个问题就是侵入性，如果一款ETL 要在数据库上安装AGENT ，然后才能进行提取，例如大名鼎鼎的那谁（就是那个数据库产品在走下坡路的数据库业界霸主的产品），如果你能顺利的完成部署（且不说和他公司数据库媲美的价格），我只能说你公司好“纯净”。大公司任何一款产品如果要侵入到数据库服务器的层面，那都不会是容易的事，安全部门要审核，运维部门要审核，很可能开发部门也的来围观一下，然后就送你一首凉凉。一款不侵入数据库服务器，或者最小化侵入数据库的产品才是能继续前行的KEY。

但这里就有矛盾了，上面是要从数据库底层来搞，下面又说不要侵入到数据库中，此时有人想说你是要找，年薪500万，身高1.8米，无父无母，北京三环有100多平的房子的未婚纯情肌肉帅哥，Day Dream!

其实我们目前倒是使用了一款“绿巨人”，至少从部署到现在8个月的时间，我倒是没有听说有什么抱怨。其实市场上类似的东西也是有几种的，期间也联系了一家做演示，不过人家脾气大，根本不来，而绿巨人这家，来了一个“智慧型”女士来做PPT ，每句都能说到点子上，让你无法拒绝，那感受好像有点Soufflé，我想大部分人能明白我的意思。
（注：避免广告嫌疑，这款软件从头到尾外号就叫“绿巨人”）

其实现在说的大数据工作主要部分，到底是什么，我看核心就两块 1 ETL 数据的抽取， 2 得到数据后的建模，分析，界面展示。

数据中台又是什么，数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。这不就是，数据，数据流，与数据管道，打开数据流的水龙头就有源源不断的你要的数据流入你要的器皿。

难点在哪里，数据抽取，如果数据的抽取困难，数据不准确，不及时，你怎么能保证你后续数据分析的准确性，和及时性。

目前我们的“绿巨人”就承担了从多种数据库中实时抽数并且从底层还不强行介入的工作，所以拥有一个“绿巨人”你的BIG DATA 甚至是多种数据库的数据分发和汇聚都变得容易。

如同上次的那篇文字，如果数据如同水一样，打开水龙头就可以来去自如，那数据的处理，分析的工作就会变得容易，简单，高效。

在最后的最后，我也表达一下对这款产品的 unsatisfactory operation，希望能全面支持POSTGRESQL 你都支持TIDB了是吧，当然目前也是支持POSTGRESQL 的源端，如果目的端能支持就更好了，另外MONGODB 如果能产出一个MONGODB to FILE （JOSN）的图形化的tools，那就更完美了。因为我们目前的MONGODB 还在半自动化的导出，尾音（真的很烦）

来源：AustinDatabases

收藏分享

声明：数据猿尊重媒体行业规范，相关内容都会注明来源与作者；转载我们原创内容时，也请务必注明“来源：数据猿”与作者名称，否则将会受到数据猿追责。