北笙.png

数据中台背景

启蒙：数据仓库的出现 商业智能（Business Intelligence）诞生在上个世纪 90 年代，它是将企业已有的数据转化为知识，帮助企业做出经营分析决策。而数据分析需要聚合多个业务系统的数据，同时需要保存历史数据，进行大数据量的范围查询。传统数据库面向单一业务系统，主要实现的是面向事务的增删改查，已经不能满足数据分析的场景，这促使数据仓库概念的出现。在 1991 年出版的《Building the Data Warehouse》中，数据仓库之父比尔·恩门（Bill Inmon）首次给出了数据仓库的完整定义：

数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的，不可修改的数据集合。

注：此处的数据仓库是传统数据仓库，与当今互联网时代基于大数据技术实现的数据仓库不同，但概念的提出和落地具有指导性意义。_

技术变革：Hadoop诞生 从 2003 年开始，互联网巨头谷歌先后发表了 3 篇论文：《The Google File System》《MapReduce：Simplified Data Processing on Large Clusters》《Bigtable：A Distributed Storage System for Structed Data》，这三篇论文奠定了现代大数据的技术基础。它们提出了一种新的，面向数据分析的海量异构数据的统一计算、存储的方法。Hadoop是前面三篇论文的一个开源实现。与传统数据仓库相比，Hadoop是完全分布式、易扩展的，满足海量数据处理要求，另外Hadoop弱化了数据结构要求，数据存储和数据模型是分离的，数据在被使用时候，可以按照不同的模型读取，满足异构数据灵活分析的需求。

数据商业化：数据湖 随着 Hadoop 技术日趋成熟，2010 年Pentaho 创始人兼 CTO James Dixon 在纽约 Hadoop World 大会上提出了数据湖的概念：数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统。

企业可以基于 Hadoop 构建数据湖，将数据作为一种企业核心资产。注：数据湖虽然和数据仓库一样都是用户数据存储，但数据湖的出现并不是为了取代数据仓库。数据湖相比数据仓库还能处理半结构化、非结构化数据，更适合于深度分析，但相比结构化型数据转化为多维数据或分析报表，数据仓库性能更高、计算模型可重复、持续使用。仓湖一体（Data Lakehouse）是当前大数据领域最为火热的流行词，也是一种大趋势。

数据工厂时代：大数据平台兴起 对于一个数据开发，在完成一项需求时，常见的一个流程是首先要把数据导入到大数据平台中，然后按照需求进行数据开发。开发完成以后要进行数据验证比对，确认是否符合预期。接下来是把数据发布上线，提交调度。最后是日常的任务运维，确保任务每日能够正常产出数据。

如此繁杂的一个工作流程，如果没有一个高效的平台作为支撑，就跟写代码没有一个好用的 IDE，用文本编辑器写代码一样，别人完成十个需求，你可能连一个需求都完成不了，效率异常低下，根本无法大规模的应用。提出大数据平台的概念，就是为了提高数据研发的效率，降低数据研发的门槛，让数据能够在一个设备流水线上快速地完成加工。

大数据平台是面向数据研发场景的，覆盖数据研发的完整链路的数据工作台。

大数据平台按照使用场景，分为数据集成、数据开发、数据测试、发布上线、任务运维，大数据平台的使用对象是数据开发。大数据平台的底层是以 Hadoop 为代表的基础设施，分为计算、资源调度和存储。

数据价值时代：数据中台 随着大数据平台的普及，也催生了不少大数据的应用场景。此时开始暴露出一些新问题：

为了快速实现业务需求，烟囱式开发模式致使不一样业务线的数据是彻底割裂的，
两个数据应用对一份数据统计相同指标，展示的结果不一致，导致运营对数据的信任度下降
形成了大量数据指标的重复开发，不只研发效率低、同时还浪费了存储和计算资源，使得大数据的应用成本愈来愈高。

2016 年，阿里巴巴率先提出了“数据中台”的概念，提出了One Data，One Service的建设方向。数据中台的核心，是避免数据的重复计算，通过数据服务化提高数据的共享能力，赋能数据应用。

政采云为什么要建设数据中台

政采云是采购行业Top级的SaaS公司，在政府采购及企业采购领域有众多的客户及相关衍生业务，沉淀了许多业务数据，拥有丰富的数据应用场景。业务的数字化，对外可以帮助行业用户提升效率、降低成本，对内可以帮助公司提升经营效率、优化决策。

在以前，公司内部存在数据孤岛，以当时面临的情况，不消除数据孤岛无法提供完善的数据驱动能力。在组建数据平台团队集成各业务部门数据后，随着数据需求越来越多，团队内部又面临效率、质量、成本的问题。比如各部门之间业务口径不一致，同样是统计本年度销售额的需求，有的部门计算规则是包含退单额的，有的不包含，有的是不包含非当年退单额等，命名和规范越来越多、越来越混乱。准备接入该指标的业务部门提出自己的业务诉求后，数据团队也不太清楚是否可复用，需要重新走读一遍代码，梳理指标逻辑。

同时随着人员更替、数据表增多，数据开发和运营分析师在上千张不熟悉的表中想找一个能与自己的需求相匹配的数据，需要花费很长时间，有时找不到以为没有就提出开发需求，造成了数据开发数据重复建设，运营分析师抱怨需求响应慢的问题。在数据运营过程中，由于数据开发的bug，导致数据产出存在问题，而问题的暴露往往是通过业务方自己发现或客户反馈，层层传递过来，等到数据开发排查到原因、修复、测试、上线，至少要花费半天到1天，滞后性强，影响到业务正常运行。

最后，数据成本随着需求呈线性增长，需要的机器资源越来越多。除了数据重复建设，作业任务“上线容易下线难”也是一个因素，不知道输出表是否还有业务方在使用，不敢随意停掉作业服务。

政采云数据中台架构

政采云的数据中台依照"One Data，One Service"的思路建设。在政采云，IData是"One Data"的落地，Datapi是"One Service"的实现。

IDATA-指标库

IDATA构建在大数据平台上，提供数仓开发、API开发、数据治理、数据监控等功能。 IDATA元数据治理中包括数据地图，而数据地图中包含指标库，在指标库出现之前，我们的业务分析师会面临以下问题：

分析场景的指标和维度不明确
数据报表频繁的需求变更和反复迭代变得臃肿
用户分析具体业务问题找数据和核对确认数据成本较高

数据开发会面临以下问题：

指标定义、指标命名混乱，指标不唯一，指标维护口径不一致
指标生产重复建设
指标消费：数据出口不统一，重复输出，输出口径不一致

为此，我们要构建一个指标库：在技术方面统一维度、指标命名、计算口径；在业务方面统一数据出口、场景覆盖。构建指标库的核心在于指标设计，从业务输出到模型设计，从数据研发到数据服务，指标都不可或缺。所以在设计指标时，我们从业务出发，基于主题域进行划分，然后根据原子指标、派生指标、复合指标规则生成指标。指标模型设计架构如下： 业务过程：业务过程可以概括为一个个不可拆分的行为事件，如购买、点击、浏览等业务过程/事件。与埋点的事件类似。

数据域：联系较为紧密的数据主题的集合，是对业务对象高度概括的概念层归类，目的是便于数据管理与应用。简而言之，数据域就类似于我们电脑桌面要建立不同的文件夹来存储数据，这些个文件夹名就是数据域。

维度：度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，可以从who-where-when-what层面来看。维度属于一个数据域，如地理维度（其中包括国家、地区、省市等）、时间维度（其中包括年、季、月、周、日等级别内容）。

维度属性：维度属性隶属于维度，相当于维度的具体说明，如用户维度中性别为男、女，地理维度里面的国家名称、国家ID、省份名称等都属于维度属性。

修饰词：统计维度以外指标的业务场景限定抽象，修饰词属于一种修饰类型，如在日志域的访问终端类型下，有修饰词APP、PC端等。

修饰类型：对修饰词的一种抽象划分。修饰类型从属于某个业务域，如日志域的访问终端类型涵盖APP端、PC端等修饰词。

指标类型：包含原子指标、派生指标、复合指标。

原子指标：基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名称，如呼单量、交易金额

派生指标：时间周期+多个修饰词（可选）+1个原子指标，是原子指标业务统计范围的圈定。 派生指标又分以下二种类型：

事务型指标：是指对业务过程进行衡量的指标。例如，阅读量、订单支付金额，这类指标需要维护原子指标以及修饰词，在此基础上创建派生指标。
存量型指标：是指对实体对象（如用户、作品）某些状态的统计，例如注册用户总数、作品总数，这类指标需要维护原子指标以及修饰词，在此基础上创建派生指标，对应的时间周期一般为“历史截止当前某个时间”。

复合指标：建立在原子指标、派生指标之上，通过一定运算规则形成的计算指标集合，如CTR，次均浏览时长等。

度量/原子指标：原子指标和度量含义相同，某一业务行为事件下的度量，是业务定义中不可拆分的指标，如推荐量、搜索次数。

时间周期：用来明确数据统计的时间范围或是时间点，如最近7天、自然月、截至当日等。

在掌握指标划分外，还需要指标命名规范，对于原子指标，指标中文名称适合用“动作 + 度量”的命名方式（比如注册用户数、购买用户数），指标英文名称用英文简写或者汉语拼音缩写比较好；对于派生指标，指标中文名称应该严格遵循“时间周期 + 统计粒度 + 修饰词 + 原子指标”的命名方式，指标英文名称要用“修饰词 _ 原子指标 _ 时间周期”的方式。如

另外，有些指标的计算逻辑比较复杂，仅仅凭借指标命名和业务口径一段描述，使用指标的人还是无法理解这个指标的计算逻辑，这个时候就需要有一些伪码或者 SQL 描述。

在了解如何设计指标之后，再基于指标属性，就可以搭建一个web指标库系统用于指标管理指标库上线后，数仓人员将已存在的混乱指标梳理后，录入指标库并持续维护，通过指标库形成了一个全局业务口径一致的指标字典。数据开发和业务分析师目前都可以通过指标字典，快速了解指标的业务含义和计算过程，不会再对指标口径产生歧义，提高了整体效率

以上是指标管理在IDATA中的实践，IDATA作为数据中台One Data落地系统，还包含许多其他模块功能，后续我们会一一讲解。比如如何建立全链路数据质量监控，如何计算数据价值、如何量化数仓设计优劣等。

招贤纳士

政采云技术团队（Zero），一个富有激情、创造力和执行力的团队，Base 在风景如画的杭州。团队现有300多名研发小伙伴，既有来自阿里、华为、网易的“老”兵，也有来自浙大、中科大、杭电等校的新人。团队在日常业务开发之外，还分别在云原生、区块链、人工智能、低代码平台、中间件、大数据、物料体系、工程平台、性能体验、可视化等领域进行技术探索和实践，推动并落地了一系列的内部技术产品，持续探索技术的新边界。此外，团队还纷纷投身社区建设，目前已经是 google flutter、scikit-learn、Apache Dubbo、Apache Rocketmq、Apache Pulsar、CNCF Dapr、Apache DolphinScheduler、alibaba Seata 等众多优秀开源社区的贡献者。如果你想改变一直被事折腾，希望开始折腾事；如果你想改变一直被告诫需要多些想法，却无从破局；如果你想改变你有能力去做成那个结果，却不需要你；如果你想改变你想做成的事需要一个团队去支撑，但没你带人的位置；如果你想改变本来悟性不错，但总是有那一层窗户纸的模糊……如果你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的自己。如果你希望参与到随着业务腾飞的过程，亲手推动一个有着深入的业务理解、完善的技术体系、技术创造价值、影响力外溢的技术团队的成长过程，我觉得我们该聊聊。任何时间，等着你写点什么，发给 [email protected]

微信公众号

文章同步发布，政采云技术团队公众号，欢迎关注

数据中台建设实践