1. 数据中台建设的基本流程
2. 数据中台建设的常见问题
- 企业在数据中台建设过程中，通常以IT条线人员作为产品经理主导，虽然能够做到技术架构的先进性，围绕“ODS、DWD、DWS”大规模存储及计算性能展开投入，但业务参与度太弱，导致系统对业务响应的敏捷度较差，业务通用性低。
- 往往企业新上一个业务，在业务看来很简单的“接入数据、生成标签、报表统计、提取数据”业务需求，在数据中台从需求分析到上线支持以月为周期。
2020年底，传出阿里掌门逍遥子要拆掉亲自搭建的大中台，核心原因对业务一线响应效率较差。
2.1. 数据标准建立和协调困难
- 业务板块和业务线众多，数据标准难建立，协调扩展困难。
2.2. 技术选型困难
- 技术选型众多，不同业务方有不同的数据需求，技术选型时依据这些客观需求及主观偏好，会选择不同的计算框架和数据组件。
2.3. 数据需求多样
- 业务部门需求多样化，包括：报表计算、可视化看板、数据探索、数据服务、结果推送、数据采集及迁移、A/B测试、标签体系、用户触达、数据应用等。
2.4. 数据需求多变
- 为应对市场的快速变化，业务方的数据需求也是多变的，看板必须能够按需调整，标签必须能自主配置，诸如此类的需求需要有大量自助工具来支撑。
2.5. 数据正确性难以确定
- 随着数据的复杂度越来越高，数据链条越来越长，数据源越来越多，保证数据的正确性及验证数据将成为一个很耗时的问题。
2.6. 数据管理复杂
- 业界对数据的可解释性、可管理性要求越来越高，各种新存储架构的加入，使得元数据管理和数据流程标准化更加复杂。
2.7. 数据安全管理复杂
- 如果无法保证数据安全，数据就是不可用的，数据合规使得数据安全成为刚需，这里要求能够支撑多级数据安全策略、数据链路可追溯、敏感数据可加密。
2.8. 数据权限管理
- 在数据赋能的体系中权限控制是很关键的功能，需要实现各种级别的数据权限，组织架构、角色、权限策略自动化，以及对新的计算架构的权限管理。
2.9. 数据成本高，难以量化
- 数据成本包括集群成本、运维成本、人力成本、时间成本等，持续系统地计算这些成本需要在系统架构中加入相应的统计接口，而现有的大多数平台并没有将这些接口考虑在内。
3. 数据中台建设的内容
3.1. 底层服务
- 底层服务层重点为整个数据中台，从数据接入层到数据安全管控全流程的数据活动，提供统一的数据存储资源、计算引擎、数据处理中间件服务，增强了服务器资源的有效调度和统一管理。
3.2. 数据接入
- 数据接入层提供统一的数据接入平台，根据数据采集的业务场景，平台提供了数据收集的工具及解决方案，让数据采集》数据传输》数据存储》数据资源管理全链路都可自动化完成，并实现对活动任务的自动化监控。
3.3. 数据整合
- 数据整合层提供统一数据处理及标签/模型开发服务。在整合层的数据需求应当来自企业的数据使用场景对数据进行建模，生成如标签管理、数据仓库这样的服务平台，为企业的数据团队／业务团队使用数据提供一个高效的整合后的数据源；
- 并在这一层对数据进行治理，例如编码规范、主题域划分，表模型规划、数据质量校验规则设计等都在这一层完成，通过这些模型、规范及平台的协同作用，为企业提供可高效获取并质量可靠的数据。
3.4. 数据挖掘分析
- 数据挖掘分析层整合了企业存在的几大数据挖掘及分析工作场景，比如对用户行为数据进行数据分析、通过算法模型挖掘用户潜在的商业价值、或者多个BU之间进行数据加密碰撞发现新合作场景等，这一层提供的平台及工具，基本覆盖了大部分数据挖掘的工作场景；
- 通过数据中台实现共享这些数据组件，使得各部门和团队都可以通过工具高效完成挖掘分析工作。
3.5. 业务应用
- 业务应用层是指可以直接提供给业务端使用的数据产品，业务可以直接使用这些数据产品高效获得满足业务需求的目标数据，甚至这些数据可以直接打通到业务系统；
- 比如 DMP 平台，让用户从
产生数据需求 > 数据加工 > 数据使用的整个数据获取周期大幅度缩短。 - 此外，也可以通过提满足特定具体业务场景的数据应用来给业务赋能。
3.6. 数据服务管理
- 数据服务管理层提供统一的数据服务出口，目标在帮助企业提升数据资产的应用价值，同时要保证数据的安全性和有效性。
- 统一服务通过行业成熟的ONESERVICE解决方案，构建API和数据服务接口来满足不同数据使用场景的需要，同时降低了数据的开发门槛。
4. 数据中台的设计原则
4.1. 数据通用性
- 数据中台的核心价值就是共享，因此数据中台的数据标准、数据接口、数据规则是否具备通用性衡量了数据中台的成功与否的标准；
- 如果每一个新接入的数据源需要重新设计接口，设计数据处理流程、更新宽表、开发新的标签，那么数据中台不过是把数据烟囱平移到新的平台而已。
4.2. 数据标准化
- 数据中台具有沉淀数据的价值使命，数据通用性、可用性主要依赖于“数据的标准化”。
4.3. 服务敏捷性
- 数据中台强调复用，复用最大的效果之一响应业务需求“快速敏捷”；
- 如果一个数据需求中台响应时效不如过去的数据集市，那么中台难以满足日益提速的业务节奏。
5. 数据中台建设涉及的角色
5.1. 业务部门主管 / 接口人
- 了解业务流程和优先级，能够将业务场景与数据对应，指导建模的流程。
- 了解企业的系统架构、技术框架。
- 对业务流程非常熟悉，通常是技术部门与业务部门的纽带。
5.2. 数据工程师
- 数据平台工程师：
- 通常有系统工程师背景，负责建设和运维数据平台，安装和运维各种大数据组件，以及保证数据平台的性能和稳定性。
- 数据开发工程师：
- 以数据仓库技能为背景，懂业务，负责建模、数据清洗和编写ETL程序。
- 数据应用开发工程师：
- 以应用开发为背景，开发服务于业务部门的数据应用。
5.3. 数据中台架构师
- 全面掌握数据平台的功能，对公司的产品提出数据的支持和要求，负责公司产品与数据平台的集成、与业务系统进行衔接的架构规划以及公司的数据标准推动和把控。
5.4. 数据分析师
- 以统计学背景为主，能够从数据中产生合理、准确的商业智能报表。
5.5. 数据科学家
- 以机器学习为背景，提供基于机器学习和人工智能的数据分析产品和结果。
5.6. 数据产品经理
- 5负责公司内部数据能力的规划和开发流程的协调，有时这个角色由数据架构师承担。
6. 数据中台建设路径
6.1. 路径一：业务中台与数据中台并行建设
- 数据中台与业务中台并行建设，复杂度可想而知，也是挑战难度最大的路径。因为建设业务中台的过程需要对业务进行梳理和规划；
- 这个过程会反复出现多次对流程调整，这给数据中台建设带来了非常多的不确定性，这也进一步增加了数据中台建设的难度。
- 在数字化营销成熟发展的今天，其实业务与数据早已不能完全分割，业务数据化和数据业务化几乎是同时完成的。
6.2. 路径二： 业务中台先行建设，数据中台跟进
- 相对比数据中台与业务中台并行的复杂度和挑战度更高，路径二显得更加稳健，也是被企业采用最多的一种路径。
- 业务中台先行，数据中台跟进，这种模式吸取了第一种模式下的业务不确定给数据中台带来了多种不确定的教训。
7. 案例：用户行为事件-数据接口标准化-建设实践
7.1 接口的通用化
- 实现接口的通用化，对实时接口、批量接口、文件上传接口中字段的定义配置化与模块化。
- 例如：90% 的事件数据可以进行通用化定义:
- 事件来源（枚举值/文本）
- 事件对象（枚举值/文本）
- 事件开始时间（日期）
- 结束时间（日期）
- 事件内容（枚举值/文件/数值）
- 事件特殊标记（枚举值/文件/数值/日期），
- 通用化标准化的接口，可以节约数据接入需求分析及接口重复设计工作量，仅需维护数据源的定义表。
- 同时，对于非分析数据应用场景，允许数据应用层可以跨层调用接入的数据（避免ODS层、DWD层处理流程消耗的时效），根据需要设置接入数据临时表（只存储一定周期接入原始数据），直接供应用层调用（实际业务中很多事件数据无需DWS或DWD层进行加工），可大幅提高响应业务时效。
7.2. 寿险领域实践案例
- 在寿险保险领域，客户的投保、保全、理赔、咨诉事件数据都可以纳入通用化接口：
- 事件类型：设置3个数值字段（如应用到咨诉-投诉-销售投诉）
- 事件名称：设置2个文本字段（XX活动）
- 事件对象：设置6个文本字段（客户号、手机号、保单号）
- 事件开始与结束时间：各设置两个日期字段（客户投诉时间、投诉事件发生时间、实际结案时间、客户要求结案时间）
- 事件内容：设置三个文本字段（投诉内容、客服备注内容）
- 特殊标记：设置2个数值、2个文本、2个日期（如投诉是否升级等）。
- 实践证明通用化接口兼容 80% 以上保险领域事件数据，减少需求分析及接口设计工作。
- 寿险实际业务中，“作业报表、触点推送”两类应用中，很多数据无需在DWS或DWD层汇总加工。
- 因此，增加设置接入数据临时表，供中台的报表、触点两两大应用模块取用进行快速增量更新，实现与数据写入ODS层流程解耦，有效解决排期不一致各种问题。
