突然就想写写关于数据治理的收获，主要是担心自己会慢慢的把数据治理相关的一些想法忘记了，顺便理一下关于数据治理的框架。同时强调一下：以下的言论仅仅代表我个人的看法和认知，很片面，也很肤浅，如果有大佬看见了错误之处，欢迎批评指正！后期有错误，我会进行相应的修改。
1.工作经历
从接触数据治理是从ETL开始的，ETL我自己的总结就是数据交换（集成、交换、清洗）
集成、交换就是把一张表的数据放入到另外一张表，这个过程主要是不同数据库之间的交换，同种数据库之间的交换比较少
清洗就是数据表中的数据不规范、不合理、有问题的进行处理的一种手段，比如日期字段格式转换、数据有空格、代码转换（男-1，女-2）等等，将数据转换成符合我们格式要求的数据
使用ETL的手段有很多，主要是ETL工具（ODI、Kettle）、数据库脚本（存储过程、函数、视图），对数据库越熟悉的人，个人感觉在这个方面更有优势，这个和DBA是有区别的。主要是在使用数据库，不是管理。
接触到ELT之后，接下来就是接触标准指定和管理，标准是指在数据表详细到字段的长度、类型、约束等等制定一个统一的模板。
目的是：在业务系统中的数据库是由研发搭建框架等等，但是里面的存放的数据不一定是合格，比如金额等等字段，设置成字符型的，长度很大，这个样子实际从业务系统的录入的数据就很随意，导致数据的混乱。这里就牵扯到了平台研发时候的规范性问题，所以在这个方面就需要制定一个标准出来，比如：性别 长度 为2 ，类型为 C，那么在业务系统数据库中都遇到这个字段的时候就都应该是这个类型的。这个样子的目的不仅是统一了整个数据库的规范，同时同样的字段数据可变化性就变小了。这个标准的制定需要是很合理，满足实际需要，同样这个也是一个很痛苦、很磨人、需要大量耐心的过程
标准制定完了之后，就是建表、数据集成，然后就是关于数据质量监控上的收获。从过数据库本身的约束条件往往是无法完全检测数据的质量问题，这个时候就可以通过类似于正则表达式，或者其他的一些手段，在平台上设置规则，比如不为空，长度为多少等等，然后平台通过这些规则对数据库中的实际数据进行检查出一个数据质量报告或者直接显示在BI上，能够让用户清晰的知道数据是什么问题、需要怎么控制和修改。
2.数据治理的前景
从工作上接触到数据治理，个人认为数据治理的前景是宏大的，还有待发展的。主要从几个方面上说明：
1.目前大数据、数据分析、数据中台、数据仓库等等技术的发展，注定了以后的生活方方面面上只会越来越智能化，智能化就代表了如何对庞大的数据量一个有效的利用。回归到根本就是数据，那么数据的规范与合理化就很重要，数据治理就是代表了这一个方面。
2.其次国内据我的了解（OS：可能很片面）没有一个真正的、成熟的数据治理流程出来，相当于目前的国内的数据治理体系大部分是根据市场的变化来的，比如面对的不同的客户，需求不同，数据治理的流程体系不同，这个代表了数据治理的方向的一个多元性，在我看来（OS：还不够成熟）不管数据治理的多元性如何的复杂，汇总之后或者说数据治理发展在最后都会出来一个统一、被广大行业认可的模板，然后在模板上进行修改。这种想法是我从Java的发展时代想到的，比如Spring的发展。
基于两种观点所以我对数据治理的前景很看好，数据治理门槛不高，但是做的过程会很痛苦，耐心很重要，同样知识和见识的沉淀也很重要。
3.数据治理的范围规划
什么叫数据治理的范围规划？这个词是我自己定义，就是给工作划一个边界线，知道哪些是我们应该做的，哪些不是。
广义上只要是与数据相关的，数据治理就有其中，狭义上的就是数据的产生、运转、最后的销毁都是有数据治理的产生。
解释一下：数据的产生往往从业务系统使用中产生，进入到数据库，然后在其他地方上使用、或者进入到数据仓库，使用完了之后的销毁（数据不一定会销毁，可能会存在一直保留的情况）等等，那么这个过程就衍生了其他的需求，比如：数据是由谁产生的，那么就是由谁来负责，数据运转上想知道这条流程从哪里产生，又经过了哪些部门，这个可以叫溯源（血缘），这样就能具体到数据的负责人、以及数据的可视化。同样对不同行业的业务开展也有参考价值，比如业务上还需要什么数据没有，那么是业务平台的功能缺失，还是没有用起来等等。所以数据治理应该不仅仅只是简单的对数据进行检测，出一份报告出来，或者给数据分析、BI等等提供数据，还需要对外扩展，完善业务。那么这个一整个合起来个人感觉才叫数据治理，也许这方面还有可以扩展的地方我没有发现。