许多大数据公司在过去一段时间都得到了较好的发展，究其原因是因为恰逢专注于业务流的信息化建设正在向数据化转型。
但在很多时候，数据其实还只是 IT 化的“副产品”，早期的工作思路仍然围绕如何将业务 IT 化，而数据只是这个过程中自然而然产生的结果，即所谓的“副产品”。
由于在数据生产的过程中并未做到足够重视，数据质量与可靠性则很难得到保证，这也是数据治理在现在得以被重视的重要原因。
在业务 IT 化的过程中，企业通过第三方厂商、自研等方式构建多种数据系统，采用多种系统中的数据化治理，是实现数据效能、数据驱动业务的关键步骤。
早期，企业用信息技术去构建业务流，而现在，我们试图用信息技术，特别是互联网行业中的一些大数据处理以及分布式处理技术构建数据流，但在构建过程中，过多强调技术本身而忽视了对数据的治理。
数据治理是整体性问题，并非仅是技术问题，市面上数不胜数的商业组件可以解决如何对数据进行存储、查询等问题，但是在实际的业务情况下对于数据治理这样一个系统性工程，目前却并无现成的产品或技术可以直接解决。
我们可以尝试用数据治理的角度来解读上图。
构建数据流的过程，很大意义上是为了解决分布在 IT 系统里各个不同子系统之间的数据孤岛问题，用一条完整的数据流将不同子系统之间的数据孤岛打通，同时应用于不同的应用场景，这个打通的过程，就是某种意义上的数据治理。这也反映了我之前尤为推崇的一个观点——构建数据仓库本身就是一个数据治理的过程。
另外，对于数据的本质，我一直推崇如下两个定义：第一“信息是用来消除不确定性的”，第二“大数据的本质，就是用信息来消除不确定性”。
同样，对于数据驱动在业务决策和产品智能两大方面的应用，也都将建立在数据治理的基础上才有意义。
一、什么是数据治理？
数据治理的本质是组织对数据的可用性、完整性和安全性的整体管理。
1. 数据治理的本质
可用性指数据可用、可信且有质量保证，不会因为分析结果的准确性造成偏差，从业者可以放心地根据数据结果做业务决策；完整性分为两个方面，一方面指数据需覆盖各类数据应用的需要，另一方面指不会因为数据治理没有到位而造成数据资产的流失，也即影响数据资产的积累，这也是神策数据在创业伊始便开展私有化部署的原因；安全性指治理和分享过程需安全可控，不侵犯用户隐私，且不会给组织留下安全隐患。
2. 数据治理的重要性
数据治理是所有数据应用的根基，数据治理的好坏直接影响所有数据应用的价值。
无论是基于数据看报表，还是做交互式的多维分析，还是做更复杂的个性化推荐，所有的数据应用都需要有一个良好的数据治理结果。
神策本身就拥有一款推荐产品——神策智能推荐，通过这款产品的实践，我们发现，它的实施周期相比其它几个产品普遍偏长，这也是因为个性化推荐对于数据的质量和准确性要求相对更高。
简而言之，数据应用做得越深入，所需数据就会更多，对数据质量也会有更高的要求。
数据治理是组织数据资产沉淀的基础，数据治理的好坏直接决定了组织的数据资产能否得到沉淀，能否充分地发挥价值。
经常会有客户主动来询问：
“领导说我们要做一个数据中台沉淀数据，但不知具体原因，亦不清楚搭建中台的具体目的，可能要等搭建之后寻找数据价值时，再去探索具体应用。”
个人认为，在经费条件允许的情况下，当然可以将企业的所有数据整合在一起，通过良好的权限管控，充分的共享，聚合所有的业务部门一起去探索数据的应用，因为数据中台本身就承载着组织内部所有数据的整合分享角色。
二、数据治理面临的挑战
本部分的内容将数据治理面临的挑战分为两类，一类因“技术”而起，一类因“人”而起。
由客观的技术问题对数据治理带来的挑战普遍较好解决，比如如何采集数据、如何存储数据等，都可通过更先进的工具、更新的技术等方式解决。
而由人或组织架构带来的问题相对复杂，它的背后包含的是企业在文化、流程上的问题，可以通过以下实例说明。
1. 多业务系统多数据源的整合挑战
企业想要做的数据应用越多，所需的数据就会越多，所要去获取的数据源也会增多，而相应的数据处理也会越多，这是一个极为显而易见的问题。
对于神策数据而言，我们在数据应用方面相对“单纯”，主要针对用户行为领域，采集用户行为数据，从客户端、服务端、数据库等做对接。
但即使是这样一个限定特殊领域的应用，我们在整合多方面数据源上也会碰到非常多的挑战，可想而知在面对多业务系统多数据源的情况下将更加困难。
2. 数据采集技术上的挑战
近年来，许多公司都在尝试将自己的业务线上化，都需要通过数据对用户进行分析与运营，如何精准采集可用的用户数据以及其他相关数据，都将是数据采集在技术层面上面临的挑战。
3. 用户隐私与安全挑战
用户隐私与安全不仅是对技术挑战，更多的是一种意识上的挑战。企业需要准确把控数据采集的红线，比如针对欧盟范围内的国际业务，就需要参考 GDPR 的相关规范。
在国内，很多银行券商等企业也同样拥有一套完善的数据合规要求，甚至已经细化到“某个特定字段对于某一个特定人可看但不可下载”的程度，这些都是需要在进行数据治理时考虑的因素。另外，如果需要在公网传输交换数据，也同样需要思考数据如何防止窃取和伪造的问题
4. 组织架构与部门隔阂带来的配合
部分组织在数据治理的过程中速度过慢，成效不好，其中一个很重要的原因是权责、部门配合等方面存在问题。很多情况下，生产数据、使用数据、分析数据的工作人员分布在不同的职能线与部门，角色不同，立场也不同，这些客观存在的影响因素都会影响整个数据治理的最终结果。
5.业务持续迭代中带来的挑战
在互联网行业中，尤其是业务迭代较为迅速的团队里，通常存在“1.0 版本的数据质量最优，1.1 版本不行，2.0 版本完全不可用”的说法，说明第一次做数据治理时，极重视数据质量，会有完善的流程来保证埋点的准确性，本身也没有太多的包袱；而在后续的产品迭代中，如果流程和标准的迭代相对滞后，整个数据治理的结果也会随着受影响，最终导致整个数据质量低劣，直至所谓的“完全不可用”。
下面举两个具体实例说明。
实例 1.
某公司的业务部门向第三方数据分析平台提出数据需求，该公司内部有多个 App 频道，每个频道隶属于一个单独的部门，而第三方数据分析平台在埋点采集阶段需要不同部门的团队相互配合。由于缺乏统一各部门需求与任务的统筹角色，实施过程中很难清楚划分相关责任，再加上管理、测试等工具的缺失，最终导致每次发版都会发生埋点丢失和报错。
实例 2.
某企业的所有用户相关数据分散在不同的系统里面，试图通过第三方数据分析平台整合统一的用户标签数据系统。然而在收集数据的过程中，每跨一次部门就需要提一次全套的审批流程，好不容易收集齐各部门各系统中的数据之后，却发现数据统计口径不一致，无法得到一个公司统一的用户标签数据。
三、数据治理与组织架构
上述内容已经提到关于组织架构的内容，因其重要性将在本部分单独说明。
1. 数据治理是一个动态的过程
数据治理实际反映的是组织问题、文化问题，这也是许多公司为了明确权责划分而建立数据治理委员会的原因。同时，还需要明确的程序与执行程序的计划，明确的程序指对数据进行治理所需经历的阶段、问题有明细的了解，执行程序的计划指每一步需要解决哪些问题。当公司的主流业务发生变化时，组织架构会随之改变，接而带来数据治理层面的变更，所以，数据治理是一个动态的过程，伴随整个业务变更与组织架构变更。
2. 数据治理中的两个核心角色
由于数据使用者属于数据治理中受益的一方，多数情况下需由其来推动数据治理任务进行。
在神策数据的具体实践中，我们非常强调对客户接口人，通常情况下也就是数据使用者的培训，由他去推动整个流程，去了解数据生产者的实际情况，从而让数据治理工作更好地进行。
四、数据治理中的应对
首先，数据治理的核心认识是，数据治理是一个持续并且长久的一个过程，不同的产品可以解决比如采集、传输等数据治理层面上的不同问题，但并不存在一款所谓的“数据治理产品”，可以用来解决所有问题。
其次，数据治理的整体方法论是“从应用倒推”。先确定数据应用、数据资产的需求，接着确定需要哪些数据，之后确定需要从哪种数据源获取数据，最终确定具体的数据治理方案。
神策凭借近年在实际业务中的经验，围绕用户行为分析领域，总结出一套数据治理方法论。
第一步，确定分析需求。通过了解数据使用者需要看哪些指标、用在哪些场景、使用哪些分析模型等方面来了解具体的数据使用需求，完成需求梳理。
第二步，映射数据模型。在该步骤需确定采集的事件和属性，并完成事件设计。
第三步，确定数据采集技术方案。根据要采的事件和属性，结合现有实际业务系统，去确定到底要从何种系统里以何种技术方案采集数据。
第四步，数据采集与集成。这一步就是指具体的开发、集成工作，包括完成相应的 SDK 集成、数据采集工具的开发、数据 ETL 开发等。
第五步，数据校验和上线。这一步中需要使用必要的测试工具、利用埋点管理平台做数据对比等。
下面，举例说明数据治理的三大原则：
数据治理原则 1：不要先污染后治理，要从源头控制
在创立神策数据之前，我们曾长期参与百度的日志数据相关的工作。在最开始的阶段，所谓的日志处理就是通过中控机器，从不同的业务系统里下载文本日志，跑完脚本后生成报表，再通过邮件的形式分发。
2008 年，团队解决了之前方案中的技术架构的问题，把以前的单机系统变成了分布式系统，提高了整体性能与计算效率，用分布式的方式下载日志，用分布式的方式来计算报表。但是，我们本质上只提供了一个计算的调度平台。就数据本身而言，没有人知道这些海量数据其中的细节，数据没有得到充分的复用，造成了许多计算资源的浪费。所以，这部分的工作其实只是解决了一个技术问题，但并没有解决任何数据治理方面的问题。
意识到数据治理的问题之后，团队中开始了百度用户数据仓库的构建工作。有工程师每天将文本日志用程序转成结构化日志，并在进行必要的数据清洗、Union、Join 等 ETL 的工作之后，将这些结构化日志统一映射到一张大表（今天 event 模型前身），并对外提供集中访问。
但随着产品线不断增多，入库周期变得更长，到后期，每增加一条产品线，都需要付出至少一周时间去解决。同时，由于数据在产生后需要做 ETL，从产生到传输到统一的 Hadoop 集群需要时间， ETL 的计算也同样需要时间，即使在最佳情况下也只能保证半小时的时效性。
这是一个典型的数据“先污染后治理”的例子，不仅在治理上需要付出更多的代价和成本，数据本身的可用性和时效性也会受到影响。
之后，我们尝试通过推行全百度统一的 Logging 平台，从打日志开始就保证数据的正确性，并且直接将数据传输到分布式集群上以保证数据的可用，这就是从源头来治理数据的思路。
在创立神策之后，我们就充分吸取了这些教训，通过 SDK 或者其他工具去严格控制数据埋点格式及数据模型，尽最大努力减少 ETL 的代价，从而保证查询时效性与导入时效性。所以，数据治理要从源头开始，不要先污染后治理。
数据治理原则 2：数据治理的过程要贯穿到整个业务迭代的过程中
以软件开发流程为例。
首先，在产品需求阶段，同样需要去明确数据需求。在具体设计阶段，完成产品交互系统架构变更的同时，去确定要加哪些日志、字段等。
在实际开发阶段，完成相应的代码开发、日志变更，单元测试应包括相应的日志变更部分，并进行日志审计，不要将埋点当成一个单独的开发任务，而是伴随的过程。在
测试阶段，当测试整体性能的正确性的同时，测试数据、日志的正确性，确保功能符合预期、日志打印正确，可以满足分需求。
在上线阶段，要实际查看上线的埋点、日志是否正确，并对功能进行确认。
最后，在项目总结阶段，用数据说明转化率变化、流程优化情况，对功能完成程度的总结，尝试真正地用数据说话。
数据治理原则 3：以产品化、组件化的思路来解决，不能依赖于人工
以产品的方式解决客户端数据采集问题。
神策的开源 SDK 被许多业界同仁参考学习，究其原因是因为它用产品的方式解决客户端数据采集问题的思维，无论是电商、社交、金融、游戏，还是哪一种产品，都会在客户端采集用户数据时面临匿名 ID 生成、基础属性采集、数据打包压缩加密、本地缓存、网络传输、时间校准、根据数据模型限定了采集数据的 Schema、通过全埋点等方式提供了对常见数据的自动采集功能、结合后端提供了对于采集端调试功能等场景，所以，可以用产品思维来解决的问题，不依赖人工。
CIO之家 www.ciozj.com 公众号:imciow