1. 数据中台建设背景

1.1 数据中台里程碑事件

1.1.1 启蒙：数据仓库的出现

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

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

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

1.1.2 技术变革：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弱化了数据结构要求，数据存储和数据模型是分离的，数据在被使用时候，可以按照不同的模型读取，满足异构数据灵活分析的需求。

1.1.3 数据商业化：数据湖

随着 Hadoop 技术日趋成熟，2010 年Pentaho 创始人兼 CTO James Dixon 在纽约 Hadoop World 大会上提出了数据湖的概念：

数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统。

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

1.1.4 数据工厂时代：大数据平台兴起

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

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

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

1.1.5 数据价值时代：数据中台

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

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

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

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

1.3.1 数据愿景

政采云是一家业务相对稳定、有一定规模的公司，基于这些年的快速发展，有众多的客户及业务线，沉淀了许多业务数据，拥有许多数据应用场景。
建立数据驱动运营（商业智能）有助于提高公司经营效率、收益、降低成本。

1.3.2 数据发展困境

• 在以前公司内部存在数据孤岛，以当时面临的情况，不消除数据孤岛无法提供完善的数据驱动能力
• 随着数据需求越来越多，公司内部的数据团队会面临效率、质量、成本的问题，一方面需要提高效能、另一方面还要控制成本
  • 指标的业务口径不一致、混乱：比如同样叫销售额，部门间定义的标准不一样。新业务部门
    • 直接复用发现数据产出不是期望值
    • 不敢去复用提需求重新开发
    • 需要数据开发人员进行代码追溯，重新梳理指标逻辑
  • 数据重复建设，需求响应慢：随着数据沉淀、人员更替，数据表越来越多，数据开发和运营分析师在上千上万张表不熟悉、找不到自己的业务需求表，以为没有就重新开发
  • 取数效率低，情况类似上一条，运营分析师找数据、理解数据非常困难，想找一个自己想要的数据，能与自己的需求相匹配，需要花费很长时间
  • 数据质量差、修复不及时：数据开发的bug，导致数据产出存在问题。而问题的暴露往往是通过业务方自己发现或客户反馈，层层传递过来，等数据开发排查到原因-修复-测试、上线，至少半天到1天，滞后性强，影响业务
  • 数据成本线性增长，需要的机器资源越来越多。数据重复建设的是其中一个原因，成本和新需求成了线性关系。另外历史作业不知道是否还有业务方在使用，不敢随意停掉，造成“上线容易下线难”，也是一因素。

以上都是数据应用达到一定规模，每个公司都会遇到的问题

1.3.3 数据中台建设门槛

数据中台是一个投入大、收益线偏长的平台，适合业务稳定的大公司

2. 数据中台建设思路

在政采云，iData是数据中台One Data的落地实现，Datapi是数据中台”One Service”的实现（此处One Service加引号是因为目前还有一小部分数据应用入口没有收敛到Datapi中，这也是之后要规划的事情之一）
架构如下：

2.1 大数据平台

数据中台依托于大数据平台，大数据平台架构如下：

2.2 One Data

用一句话定义 OneData 的话，就是所有数据只加工一次。比如不同业务线或主题域统计同一个指标，只需要开发一次。虽然听起来很简单，但在实际工作中，随着业务越积越多，数据元信息管理越来越混乱，往往会出现：

• 接到开发需求却没有发现之前另个部门或在其他主题域已经实现过了
• 这个需求指标和之前的一个指标有点像，不知道能不能复用，它们的定义是否一致
• 之前其他数据开发开发过了，但找不到他的输出表
• 和之前的某个需求很像，但数据模型不满足，只能重新加工

解决上述的一个个问题，就是One Data构建的一步步实现，即至少要做到：

• 表规划管理：表按业务线、主题域管理，划分要以长期稳定、尽可能覆盖大部分表为目标
• 分层设计实现数据模型复用，常用的分层包括ODS 原始数据层，DWD 明细数据层，DWS 轻度汇总数据层，ADS/DM 应用数据层 / 数据集市层
• 表遵循命名规范定义，表的名称中最好能够携带表的主题域、业务过程、分层以及分区信息，命名规则可以：”分层主题域业务过程表内容写入规则”，政采云内部的规则是“主题域.[dim]业务过程表内容_写入规则[_tmp]”
• 需要一个指标系统，确保指标定义无歧义，指标系统需要数据产品、数据应用开发、数开发、运维分析师各方共同维护，保证各方达成共识。

• 数据中台的每一层数据要尽可能完善，让数据使用者尽可能的使用汇总后的数据

  2.2.1 元数据管理

  我们以元数据管理平台作为One Data体系的落地方案切入点

  2.2.1.1 数据地图

  数据地图是基于元数据中心构建的一站式企业数据资产目录，可以看作是元数据中心的界面。数据开发、分析师、数据运营、算法工程师可以在数据地图上完成数据的检索，解决了“不知道有哪些数据？”“到哪里找数据？”“如何准确的理解数据”的难题。
  数据地图提供了多维度的检索功能，使用者可以按照表名、列名、注释、主题域、分层、指标进行检索，结果按照匹配相关度进行排序。考虑到数据中台中有一些表是数仓维护的表，有一些表数仓已经不再维护，在结果排序的时候，增加了数仓维护的表优先展示的规则。同时数据地图还提供了按照主题域、业务过程导览，可以帮助使用者快速了解当前有哪些表可以使用。
  以下是政采云数据地图的系统界面：
  

  2.2.1.2 指标管理

  指标随着数据需求越来越多，也越来越混乱：

• 相同指标名称，口径定义不同。不同的部门对相同的“新用户销售额”，因为口径定义的差别，导致指标数值的不一致。而这种情况是指标管理中最容易出现的情况。口径不一致，数据也就没办法横向对比，失去了数据辅助商业决策的意义。

• 相同口径，指标名称不一样。这种情况与上面相反。
• 不同限定词，描述相同事实过程的两个指标，相同事实部分口径不一致。这个问题该如何理解呢？ 来看一个例子。会员购买用户和非会员购买用户数，它们描述的都是用户下单购买商品的相同业务过程，记录的都是购买商品的事实，只是一个限定词是会员，一个限定词是非会员。按照一致性原则，虽然是两个指标，但是对于购买用户数这个相同的事实部分，业务口径、计算逻辑应该是一致的，但是现实情况却可能不是这样：“会员购买用户数”的口径定义是计算周期内去重的（重复购买的用户只算一个），下单并且支付成功的用户数量；“ 非会员的购买用户数”的口径定义是计算周期内去重的，下单并且支付成功，排除下单购买成功后，取消订单的用户数量。你能看到，对于购买用户数，这两个指标的口径是不一致的，一个包含取消订单的用户，一个不包含。
• 指标口径描述不清晰。
• 指标口径描述错误。
• 指标命名不规范，从指标名称中很难看出指标描述的业务过程。
• 如果指标数据来源不清楚，一旦这个指标数据异常，就很难去做溯源。另外，有些指标的计算逻辑比较复杂，仅仅凭借业务口径一段描述，使用指标的人还是无法理解这个指标的计算逻辑，这个时候就需要有一些伪码或者 SQL 描述。

基于指标系统构建全局的指标字典。指标治理的最终结果，就是要形成一个全局业务口径一致的指标字典。让使用指标的人，可以通过指标字典，快速了解指标的业务含义和计算过程，不会对指标口径产生歧义。为此可以让数据中台团队，最好是数据产品经理来专门负责指标管理。尽管是同一批人管理指标，随着指标越来越多，也会出现指标重复定义的情况，关于指标在系统中的唯一性实现，可以提供了一个文本相似性检测的功能，可以把相似指标定义，业务口径的指标找出来，然后由负责人来判断是否是重复。另外规范化定义指标，为了提高指标管理的效率，按照业务线、主题域和业务过程三级目录方式管理指标。

2.2.1.3 模型设计

数据中台模型设计的核心是追求模型的复用和共享，良好的模型设计有助于提高效率加快数据产出。
数据模型采用常用的分层包括ODS 原始数据层，DWD 明细数据层，DWS 轻度汇总数据层，ADS 应用数据层，DM 数据集市层。
一个理想的数据数仓模型应该具备“数据模型完善、规范、可复用”，以下是一种衡量方法：

• 完善度
  • DWD完善度：ODS层直接被DWS/ADS/DM层引用的表，占所有活跃的ODS层表的比例，比例越低说明DWD层数据越完善
  • DWS/ADS/DM层完善度：汇总层数据查询的比例，如果汇总数据无法满足，一定会使用明细层甚至原始数据。汇总数据查询比例越高，说明上层越完善
• 复用度
  • 通过数据血缘我们可以获取直观的依赖关系：
  • 从有向无环图的数据结构看，节点的出度越多，复用度越高
• 衡量规范度
  • 是否分层，常见分层ODS/DWD/DWS/ADS/DM
  • 分层命名是否统一按比如”分层主题域业务过程表内容写入规则”
  • 不同模型间同个字段的命名是否统一，比如表A的用户id叫userId，表B叫id

数据模型落地过程中，需要注意：

1. 控制住所有数据源即ODS层，从源头控制住才能根本上防止一个重复的数据体系出现
2. 划分主题域，根据业务划分，依据是否能够长期稳定，覆盖大部分模型来判断划分标准是否合理
3. 构建一致性维度，对于维表命名可以参考政采云内部的规则：“主题域.dim业务过程表内容_写入规则[_tmp]”
4. 模型开发阶段
   1. 所有任务必须严格配置任务依赖，防止基于错误的数据空跑。政采云对没有任务依赖的作业会单独提供悬垂作业界面，另外在配置任务依赖过程中，会检查依赖关系
   2. 任务中的临时表，及时删除，否则会占用大量空间。政采云统一规范了临时表命名，以定时扫描的方式清理
   3. DWD层宜采用压缩方式存储，节省带宽和存储资源

      2.2.2 数据质量

      数据产出除了”快”，还要”准”。我们很可能会因为数据”不准”导致了数据长时间不可用：晚于业务方发现数据异常，被投诉后才发现问题。发现问题后，又无法快速定位到数据异常的根源，花了很长时间排查问题。终于定位到问题数据在加工链路的上游顶端，在问题修复时，所有下游链路上的任务都要运行，修复完大半天过去了。

2.2.2.1 数据质量问题的根源

• 业务源系统变更：数据中台的数据来源于业务系统，而源系统对数据库进行了表结构变更，增加了一个字段，同时对部分字段的类型、枚举值进行了调整。这种表结构变更没有通知到数据团队，导致数据同步任务或者数据清洗任务异常，进而影响了下游数据产出。
• 数据开发的纰漏引发
  • 环境没做隔离，或隔离不完备，线上数据被污染
  • 数据格式处理错误，代码忽略了异常，导致数据错误
  • 任务配置异常
• 物理资源不足导致任务延迟产出
• 基础设施不稳定，如HDFS的DN宕机影响全局读写、Yarn的RS宕机等

2.2.2.2 如何提高数据质量

• 基于上述引发问题的原因做归纳总结、不断完善管理流程、代码规范、自身技能降低事故发生概率。
• 出现问题几乎是不可避免的，“亡羊补牢”的最好办法是“早发现、早恢复”，先于数据使用方发现数据问题，缩短故障恢复时间，降低故障对数据产出影响。

如何做到早发现、早恢复？

• 添加稽核校验任务：对产出表按照业务规则，设计一些校验逻辑，确保数据的完整性、一致性和准确性。
  • 完整性：表数据增量波动，比如超过20%为异常；主键、唯一键重复监控重复记录；字段级别监控0值、null值
  • 一致性：根据业务规则校验相同数据在不同数据模型中的一致性
  • 准确性：基于业务或基本数据规则检查，如用户行为时间是还没发生的时间
• 建立全链路监控：基于数据血缘关系和稽核规则，建立全链路数据质量监控。
• 智能预警，确保任务按时产出：对指标加工链路中的每个任务的产出时间进行监控，基于任务的运行时间和数据血缘，对下游指标产出时间进行实时预测，一旦发现指标无法按时产出，则立即报警，数据开发可以终止一些低优先级的任务，确保核心任务按时产出。
• 重要性区分数据等级，加快恢复速度：稽核校验会消耗大量的资源，只对核心应用的数据链路上的所有任务做检查；

基于智能预警，第一时间发现问题；基于全链路监控，第一时间定位到问题；基于数据重要性等级，优先恢复核心数据；

2.2.3 成本治理

数据除了”快”和”准”，还要”省”。数据的投入和产出如果不匹配，项目价值会小很多。

2.2.3.1成本陷阱

• 数据上线容易下线难：不知道一张表还有哪些任务在引用，还有哪些人在查询，不敢停掉这个表的数据加工
• 低价值的数据应用消耗了大量的资源：数据应用业务价值低，但相关数据加工消耗的资源庞大
• 烟囱式开发模式：数据重复加工，浪费资源
• 数据倾斜：数据倾斜会让任务性能变差、也会浪费资源。分布式计算符合木桶效应，整个任务运行时长取决于运行最长的那个任务。每个分片数据量不同，每个任务所需资源不同，但不同任务不能分配不同资源。所以，总任务消耗资源 =max{单个任务消耗的资源} * 任务数量。这样一来，数据量小的任务会消耗更多的资源，就会造成资源的浪费。
• 数据未设置生命周期：一般原始数据和明细数据，会保留完整的历史数据。而在汇总层、集市层或者应用层，考虑到存储成本，数据建议按照生命周期来管理，通常保留几天的快照或者分区。如果存在大表没有设置生命周期，就会浪费存储资源。
• 调度周期不合理：政采云的大数据任务的资源消耗有很明显的高峰和低谷效应，一般晚上12点到第二天的9点是高峰期，9点到晚上12点是低谷期。任务有明显的高峰低谷效应，但是服务器资源不是弹性的，所以就会出现服务器在低谷期比较空闲，在高峰期比较繁忙的情况，整个集群的资源配置取决于高峰期的任务消耗。如果业务条件允许，把一些不必要在高峰期内运行任务迁移到低谷期运行，也可以节省资源的消耗。但在政采云，更适合以弹性计算服务资源的方向解决成本问题
• 任务参数配置：任务参数配置的不合理，往往也会浪费资源。比如在 Spark 中，Executor 内存设置的过大；CPU 设置的过多
• 数据未压缩：Hadoop 的 HDFS 为了实现高可用，默认数据存储 3 副本，所以大数据的物理存储量消耗是比较大的。尤其是对于一些原始数据层和明细数据层的大表动辄几十T

2.2.3.2 应对成本陷阱

下线表
基于One Service维护冷热表属性信息，制定下线冷表策略-停止产出任务调度-数据冷备-线上数据删除
数据倾斜
数据倾斜的处理方法有很多，不同的场景有一些适用的解决方案：比如在一些大表和小表关联时，Key 分布不均造成的数据倾斜，可以使用 mapjoin 的方式解决；内存计算时进行repartition操作；分区存储上进行预分区加随机盐等
数据压缩
压缩性能样例：

压缩格式比较：

整体来看，对于小文件的压缩，不考虑 split，gzip 比较合适；对于大文件，推荐使用 lzo，支持 split，在保证压缩效率的前提下，有着相对稳定的压缩比

数据生命周期设置

• 对于 ODS 原始数据层和 DWD 明细数据层，比较适合用永久保留的策略
• 对于一些维度表依据业务重要性可以考虑保留3-5年

定量数据性价比：计算数据成本

我们要对上图中财务分析报表核算成本，这个报表上游链路中涉及到 a，b，c，3 个任务，A，B，C，D，E，F， 6 张表，那么：这张报表的成本 =3 个任务加工消耗的计算资源成本 +6 张表消耗的存储资源的成本。另外，需要注意的是，如果一个表被多个下游应用复用，那这个表的存储资源成本以及产出任务消耗的成本，需要分摊给多个应用。

定量数据性价比：计算数据价值

• 如果末端数据是一张应用层的表，它对接的是一个数据报表，那衡量这个数据的价值，主要是看报表的使用范围和使用频率。在计算使用范围时，通常用周活来评估，同时还要考虑不同管理级别的人权重。使用频率一般使用单个用户每周查看报表的次数来衡量，次数越高，说明报表价值越大。
• 如果末端数据对接的不是一个数据报表，而是面向特定场景的数据应用（比如招投标巡检）。衡量这类产品的价值，主要考虑目标人群的覆盖率和直接业务价值产出。
• 如果末端数据是一张集市层的表，用于提供给分析师做探索式查询。这类表的价值主要看它被哪些分析师使用，使用频率如何。同样，在使用范围评估时，要对分析师按照级别进行加权。

2.2.3.3 量化成本治理效果

根据1个CU（1 CU包含的计算资源为4 GB内存和1 CPU Core）年1300元为估算单位，1CU/天=3.5元为计费单元进行评估；存储成本按1TB的1年300元，1G/天=0.0008元进行评估。统计下线的任务数，这些任务每日消耗的CU，增量数据大小（G），即可定量评估出节约的金额。

2.3 One Service

One Service即统一对外数据服务，好处较多：

• 屏蔽底层数据接入逻辑
• 实现访问数据链路监控
• 数据接口复用
• 方便权限管理
• 保证交互数据完整保证底层数据特征统计完整
• 松耦合，底层改动对外透明。比如数据部门字段变更导致应用变更，会影响到直接访问数仓的数据层应用

“Datapi”项目是政采云数据中台”One Service”的落地实现，解决了应用系统接入效率低，消除烟囱开发，提供权限管理保证数据安全。但由于入口收敛不完整，One Service部分能力无法发挥出来，如没有完全覆盖底层数据资产访问入口，导致部分功能不可落地，无法准确统计冷热表，无法通过此办法落地下线表功能。目前收敛入口计划已在未来规划中。

2.3.1 数据服务建设

数据服务架构建设可参考后端服务中台设计包括服务本身高可用、高可靠、高性能，功能包含但不仅限：

• 数据网关
• 服务方式提供API和推送形式
• 利用中间存储，加速数据查询
• 逻辑模型，实现数据的复用。基于逻辑模型发布接口，API 服务接到查询请求后，根据逻辑模型和物理模型字段的映射关系，将逻辑执行计划拆解为面向物理模型的物理执行计划，并下发多个物理模型上去执行，最后对执行的结果进行聚合，返回给客户端
• 构建 API 集市，实现接口复用

如果数据服务的API接口无法满足用户的需求，可以让用户自己定义，如果还是没办法满足，可以考虑通过数据服务放开SQL接口接入，但是必须要由数据服务代理。否则，你没办法获取到链路关系。另外，尽量不要放开SQL，不好管理。

3. 政采云数据中台建设实践

上面已经讨论了如何建设一个数据中台，下面简单展示下政采云的数据中台建设，标红部分是正在建设或未来要建设的功能/组件，标紫部分是目前要淘汰的功能/组件用于降低运维成本：

3.1 IDATA

以下是IDATA开源版本的功能界面，功能目录分类如图：

以下是公司内部版本功能目录：

3.1.1 数据开发

3.1.1.1 作业

功能如下：

• 支持SPARK/SQL/SCRIPT/KYLIN作业类型，PYTHON/JAR/COMMAND/SHELL运行方式
• 支持页面调试，调试状态会在数仓生成临时表[_tmp]，基于临时表执行作业逻辑，临时表会定时清理
• 带运行状态的作业依赖DAG视图
• 支持调度配置、告警配置、运行配置、依赖配置、输出路径等配置
  • 调度配置支持AirFlow和Dolphin Scheduler，目前最新的已替换为Dolphin Scheduler2.X
• 环境隔离
• 支持作业版本控制

SQL作业配置示例图：

3.1.1.2 函数

即函数元数据信息的管理，主要对象是python/java的自定义udf文件

3.1.2 数据集成

部分功能页面如下图：

3.1.3 DAG

DAG是调度系统的调度单元，作业包含在DAG内，依托DAG执行作业任务。在IDATA中主要是配置调度周期。IDATA会将页面配置的DAG通过接口API方式同步到调度系统（Airflow/Dolphin Scheduler）内。

3.1.4 数仓设计

同模型设计，支持自定义元数据属性，展示部分功能页面：

3.1.5 数据源配置

数据源类型配置用于可视化数据源接入，应用于数据集成等各方面，展示部分功能页面：

3.1.6 数据质量

数据质量模块目前暂未开源，同建设思路中数据质量，配有告警规则、稽核校验规则、告警等级。目前一个任务只绑定一张输出表，所以配合数据依赖同时实现了数据链路监控。展示部分功能页面：

3.1.7 数据地图

同建设思路中数据地图，展示部分功能页面：

自助取数：

• 用图形化的方式，替代了写 SQL 的方式
• 提供了对业务人员比较友好的业务过程、指标、维度的概念，替换了表、字段
• 每个指标的业务口径都能够直接显示
• 用户通过选取一些指标和维度，添加一些筛选值，就可以完成取数过程
• 界面非常简洁，使用门槛非常低

关于自助取数的对外服务，政采云提供了小采BI系统。

3.1.8 智能监控

与任务监控不同，智能监控中监控对象是悬垂作业和可能配置有误的元数据信息，是在运行任务之前的监控。稽查规则目前为：

• 无作业依赖的悬垂作业
• 元数据设计不相符错误
• 调试参数模板渲染失败 API

3.1.9 One Service

Datapi是政采云One Service的数据服务实现，系统入口设置在IData中。同建设思路中数据服务部分，支持SQL接口接入、应用权限管理和AK管理

3.1.10 其他

如Metabase，支持SQL和图形化两种方式给分析师、运营人员、技术人员提供查询底表功能，其他服务参见上面的政采云中台服务。

4. 未来规划

4.1 降成本

• 服务资源弹性伸缩，进一步降低成本
• 数据应用操作入口收敛，目前除了Datapi还有如Metabase通过presto等方式直连访问数仓，需要将入口统一收敛到Datapi中，用于后续权限管理、用户行为数据追踪、数据特征统计
  • 统计数据特征用于后续判断冷热表，为下线表做准备降低成本；结合用户行为数据追踪量化数据价值，为治理低价值数据做准备，进一步降低成本
  • 收敛、统一数据入口，基于统一权限管理，进一步提高数据安全性，权限统一易用性，搭建完整的日志审计系统
• 监控数据开发的作业质量，提高资源效率
  • 数据倾斜：如Spark作业，监控当前第几个stage的task处理数据差距超过阈值（比如10倍，有的task处理2000条数据有的处理20000条数据，说明发生数据倾斜），发出告警
  • 参数配置：小作业申请大资源，监控作业数据数量、大小和申请资源匹配程度

4.2 提高数据质量

• 数据质量：精确到字段级别数据血缘，方便数据应用更快定位数据问题

4.3 提升作业速度

• 小采BI目前是大部分是基于presto进行OLAP查询，速度较慢，后续替换为Doris，提升用户体验和效率
• kyuubi替换livy（需调研），livy相比Spark Thrift用户资源隔离，但针对同一用户无法实现资源共用，另外livy以服务方式提供能力需要运维成本

4.4 强化功能

• 支持实时数据集成，技术方案如Flink CDC
• 全维度钻取，增强分析：基于数据结果探索、推测各个已知维度与其结果的关联性，增强BI产品工具能力
• 一个长期的规划探索方向：不断寻找数据和AI能力结合的技术实现和业务落地

4.5 数据安全

• 细化权限颗粒度
  • 表字段级别
  • IData界面按钮级别
  • 存储空间(HDFS)权限
  • 调度资源(YARN)队列权限

引用

【1】：云原生大数据计算服务 MaxCompute：https://help.aliyun.com/document_detail/116880.html
【2】：数据中台实战：https://time.geekbang.org/column/article/216440