从“数据中台”的视角来认识“数据分析”

数据中台炙手可热，然而很多人并不知道数据中台有什么作用，也不懂为什么人人都在谈论数据中台。总之，提到「数据中台」4 个字，很多人都会「不明觉厉」。其实简单来说，数据中台就是企业用户数据的链接枢纽，数据中台的搭建就是以数据创造价值的过程。

那么，本期邀请了有着8年多年数据平台架构，数据管理，数据分析经验的王广老师，就职于某AI药物设计公司大数据架构师，目前带领公司大数据部门进行企业数字化转型！

1. 什么是数据中台

数据中台是一套可持续“让企业的数据用起来”的机制，是一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建的一套持续不断把数据变成资产并服务于业务的机制。数据来自于业务，并反哺业务，不断循环迭代，实现数据可视、可用、可运营。

2. 数据中台的三个核心认知

2.1 数据中台需要提升到企业下一代基础设施的高度，进行规模化投入；

2.2 数据中台需要全新的数据价值观和方法论，并在其指引下形成平台级能力；

2.3 数据中台围绕业务、数据、分析会衍生出全新人才素养要求，需要尽快启动人才储备；

3. 数据中台驱动模式

以上四种驱动模式，最优的就是业务能力驱动模式。需要业务架构师和数据架构师联合驱动，从公司顶层的视角构建公司业务架构，从业务架构到数据架构从上而下去建设是最好的。但是这种情况还是比较少的。在国企、央企、政府比较多，因为，采用这种方式的公司，一般它对数字化转型非常重视。

4. 数据中台推进原则

4.1坚持"业务牵引，咨询、平台、实施三位一体推进"原则

♦以满足相关业务应用需求为目标

♦总体规划

♦按需搭建平台

4.2遵循"横向规划，纵向切入"建设模式

♦规划必须全盘考虑，打通企业的所有板块

♦数据中台建设不可能一蹴而就，需要从业务应用出发倒推数据需求

♦围绕单个业务场景的闭环快速搭建数据中台的各种能力

♦按照全景规划依次迭代，逐步实现全局数据中台

5. 数据中台架构原则

5.1 核心纪律严明

创建新的架构范例的目的是要敏捷和创新，但它需要实用的治理。这种平衡是一条需要把握的微妙线。第一条神圣的原则体现了这种平衡。在核心上遵守规则意味着存储数据的各个层需要按照它们的数据管理方法进行结构化。这些层需要有详细的治理策略，不能留下任何模糊的空间。然而，DataLakeHouse的边缘，即数据转换、数据屏蔽和有助于洞察的层，需要具有灵活性。灵活性并不意味着在方法中乱作一团。这些层仍然由Data LakeHouse的策略管理。但是，它们在创建基于需求的新特性时具有一定的灵活性。在边缘灵活的一个例子是，将来自Data LakeHous的原始数据和来自数据服务层的数据仓库的数据混合起来，以创建一个ML模型。这些数据集具有不同级别的质量分数和属性。然而，这种灵活性是可以接受的，因为它有利于快速洞察的创建。

5.2 解耦计算和存储

Data LakeHouse存储大量的数据。它以结构化和非结构化的格式将数据存储在数据湖层和服务层。数据需要用不同类型的计算引擎来处理。它可以是基于批处理的计算，也可以是基于流的计算。紧密耦合的计算和存储层剥离了Data LakeHouse所需的灵活性。解耦计算和存储也有成本影响——存储是廉价和持久的，但计算是昂贵和短暂的。它提供了按需旋转计算服务和根据需要扩展计算服务的灵活性，还提供了更好的成本控制和成本可预测性。EDW和数据湖模式面临的一个关键挑战是计算和存储的紧密耦合。无论是否正在使用，都需要分配计算。随着存储的增加，计算也需要相应地伸缩。云计算平台提供了解耦计算和存储的灵活性。

5.3 关注功能而不是技术

下一个神圣的原则是关注组件的功能，而不是它的技术化身。这一原则体现了灵活性。正如系统上下文图中所描述的，Data LakeHouse可以满足很多人的需求。Data LakeHouse的技术表现形式有大量的技术选择。它可以部署在任何云平台上，甚至可以使用不同类型的选择在内部部署。此外，技术正在迅速变化。许多新产品都在商业上或开放源码世界中发展，专注于实现特定的功能。让我们以实时处理为例。Apache Storm是2011年发布的一款针对实时处理进行了优化的产品。Apache Spark在2010年开源，到2013年成为了事实上的流处理引擎。Apache Spark一直在发展，而Apache Flink现在正在挑战Apache Spark作为流处理引擎的霸主地位。技术的发展是迅速的。然而，功能仍然是相同的流处理。专注于一个组件完成的任务是至关重要的。此外，随着技术的发展，我们可以很容易地替换技术来满足相同的功能。

5.4 创建模块化架构

模块化架构指的是由可连接的独立组件组成的任何系统的设计。模块化架构的美妙之处在于，您可以替换或添加任何部件(模块)，而不会影响系统的其余部分。模块化架构确保了Data LakeHouse架构的灵活创建，并且我们可以在不破坏现有功能的情况下无缝添加新功能。例如，假设将来需要向Data LakeHouse架构添加新功能。在这种情况下，可以添加组件，使其遵循与所有其他组件相同的模式。它从数据湖层获取数据，执行其功能，并将数据存储到经过处理的数据存储中，以便为其提供服务。模块化架构原则确保了数据保持在核心位置。根据不同的功能，可以实例化不同的服务以根据需要使用数据。

5.5 积极开展编码

防止Data LakeHouse变成沼泽的唯一最重要的原则是在其层内进行编目的程度。因此，执行主动编目是一个神圣的原则。编目是防止数据湖变成数据沼泽的关键。勤奋的编目可以确保Data LakeHouse的用户具有数据感知能力。他们应该理解存储在不同生命阶段的数据的属性。他们需要理解数据转换过程的血缘，从数据生成到数据消费。需要对Data LakeHouse架构的所有组件进行编目，以便使用DataLakeHouse提供整个数据生命周期的整体视图。

6. 常见数据问题

♦独：烟囱系统，数据孤岛严重。重复开发，成本浪费；

♦断：数据理解与数据价值链条的断层；

♦缺：缺标准、缺治理、缺数据、缺流程、缺组织、缺制度；

♦难：知数据难、要数据难、懂数据难、溯源难；

♦脏：数据质量差；

♦安全：数据存在泄漏风险

7. 数据中台的业务价值和技术价值

7.1 业务价值：从洞察走向赋能业务创新，形成核心壁垒

在以客户为中心的时代，数据中台对数字化转型具有重要作用，以数据中台为基础的数据系统将位于企业应用的核心，通过数据从企业降本增效、精细化经营等方面为企业带来巨大收益。具体来说，包含以下三个层面：

◆ 以客户为中心，用洞察驱动企业稳健行动

在以客户为中心的时代，客户的观念和行为正在从根本上改变企业的经营方式以及企业与客户的互动方式。

数据中台建设的核心目标就是以客户为中心的持续规模化创新，而数据中台的出现，将会极大提升数据的应用能力，将海量数据转化为高质量数据资产，为企业提供更深层的客户洞察，从而为客户提供更具个性化和智能化的产品和服务。

譬如，数据中台能够汇聚全渠道的数据，在标签管理、营销圈人、效果分析等应用上实现全域的闭环，优化对客户全生命周期的理解。此外，以数据中台为基础，通过数据化运营提升客户留存、复购和忠诚度，也得到诸多企业的认可。

◆ 以数据为基础，支持大规模商业模式创新

只有依托数据和算法，将由海量数据提炼的洞察转化为行动，才能推动大规模的商业创新。数据中台在通过算法将洞察直接转化为行动、实现大规模商业创新方面的能力，令人瞩目。

另一方面，数据无法被业务用起来的一个原因是数据没办法变得可阅读、易理解。

信息技术人员不够懂业务，而业务人员不够懂数据，导致数据应用到业务变得很困难，数据中台需要考虑将信息技术人员与业务人员之间的障碍打破，信息技术人员将数据变成业务人员可阅读、易理解的内容，业务人员看到内容后能够很快结合到业务中去，这样才能更好地支撑商业模式的创新。

此外，数据中台提供标准的数据访问能力，简化集成复杂性、促进互操作性等特性也非常受企业CIO们的青睐。同时，在快速构建服务能力、加快商业创新、提升业务适配等方面，数据中台也将会发挥重要的作用。

◆ 盘活全量数据，构筑坚实壁垒以持续领先

在以客户为中心的时代，只有赢得客户的企业才能在竞争中保持优势。企业能否真正做到“客户至上”，并不断提高对客户的快速响应力来满足客户的需求，甚至引领市场潮流，持续推进规模化创新，终将决定企业能否在充满挑战和机遇的市场上发展壮大，长久保持生命力与竞争力。

7.2 技术价值：能力多、成本低、应用广

数字化转型的需求必将催生多元化的数据场景，而多元化的数据场景将会带来以下技术需求，企业数据中台建设势在必行。

◆ 应对多数据处理的需求

针对不同的数据应用场景，需要能够快速应对多数据处理需求，比如：

要保持原来的报表需求，仍需要保持批量离线计算的能力（Hadoop、Oracle RAC）；

针对准实时的指标统计和实时推荐，需要实时流式计算的能力（Storm、Spark Streaming、Flink）；

针对决策类业务如海量人群的圈人需求和ad-hoc需求，需要即席计算能力（Greenplum、Elasticsearch、Impala）；

针对高并发业务场景（如用户画像），需要在线计算能力（MySQL、Redis、Oracle）。

因此，企业需要一个统一的数据中台来满足离线／实时计算需求、各种查询需求（实时查询和ad hoc），同时在将来新数据引擎（更快的计算框架，更快的查询响应）出现时，又不需要重构目前的大数据体系。

◆ 丰富标签数据，降低管理成本

根据全国信标委大数据标准工作组发布的《数据管理能力成熟度模型》（DCMM），针对数据标准提到的数据分类主要有主数据、参考数据和指标数据，但根据目前真实的数据建设情况来看，需要对一类数据进行定义和分类，譬如标签名为“消费特征”，标签值为“促销敏感”“货比三家”“犹豫不决”。

数据中台能对这类标签进行快速定义和有效管理。

◆ 数据的价值能体现业务系统效果而不仅是准确度

过去的数据应用场景主要为报表需求，注重数据的准确性，但在更多数据场景下，特别是对于标签数据的应用，越来越多的数据是需要不断“优化”的，数据本身没有准不准确之分，比如某个会员是属于促销敏感人群，这个数据其实更多的说的是概率。

◆ 支持跨主题域访问数据

企业早期建设的应用数据层ADS（传统数据仓库ODS/DW/ADS）更多是为某个主题域所服务的，如营销域、人力资源域、风控域，而企业在数据应用的时候往往需要打破各个业务主题，会从业务对象主体出发来考虑数据应用，如人（会员、供应商、渠道、员工）和物（商品、仓库、合同），从全域角度设计完整的面向对象的数据标签体系。

◆ 数据可以快速复用而不仅是复制

传统的架构中，要将数据应用到业务中，通用的做法都是通过数据同步能力，把计算的结果同步给业务系统，由业务系统自行处理，这会带来一个数据管理问题，即无法获取数据在应用场景中的具体价值和热度，整个数据血缘链路也是割裂的。

1.数字化转型面临的问题

利用数据中台，实现数据采集、存储、处理、分析和服务的统一管理，提高信息和数据的响应时间，提高经营管理工作效率，有利于压缩开支，降低管理成本，推进数字化转型发展。”5步走”解决问题！

▶1种战略行动：把用数据中台驱动业务发展定位为企业级战略，全局谋划；

▶2项保障条件：通过宣导统一组织间的数据认知，通过流程加速组织变革；

▶3条目标准则：将数据的可见、可用、可运营3个核心准则始终贯穿于中台建设的全过程，保障建设在正确轨道上；

▶4套建设内容：通过技术体系、数据体系、运营体系建设保证中台建设的全面性和可持续性；

▶5个关键步骤：通过理现状、立架构、建资产、用数据、做运营5个关键行动控制中台建设关键节点的质量；

1.数据中台架构图

2.典型应用场景介绍

民生服务、经营决策、风险控制、精准营销、绩效考核

♦场景一：在财务管理中使用 BI 找到数据关键

BI 可以帮用户获取外部、本地的各种财务数据。还可以利用拖放可视化工具，完善客户对财务状况的分析。

♦场景二：帮助市场营销活动管理数据

借助 BI，用户可以监控并分析当前的市场状况，从而把营销资源投入到更有效率的渠道上。 

♦场景三：在销售活动中预测市场机会，达成业绩目标，提高利润

BI 可以帮用户管理公司的各种销售渠道。 

♦场景四：掌握人力资源的相关信息

BI能帮用户收集和监测所有重要数据。仪表板还能帮用户追踪合规性、人员编制和其他信息，保护公司和员工数据。

♦场景五：IT领域提高工作效率

通过BI，用户可以创建各类仪表板，从而监测并分析从 Active Directory 到 Zendesk等各种服务。如果需要企业级别的商业智能解决方案，您还能将它与 SSAS 服务包无缝集成。

♦场景六：在运维工作中以数据为向导

BI 能够监测包括 Excel表、本地数据库和云服务等所有来源的数据，并为用户的产品、商场绩效、申报额分析等发现新的可能

3.数据使用者

一旦数据被接入到Data LakeHouse，各种利益相关方将以原始或转换后的形式使用它。这些利益相关者将从Data LakeHouse中提取用于特定目的的数据。每个消费者都有使用Data LakeHouse的个人动机。一个架构良好的Data LakeHouse应该能够满足每一个涉众的需求。

让我们看看一些典型的用户和系统，他们使用来自Data LakeHouse的数据，如下所示:

♦数据科学家

我们看到使用Data LakeHouse的第一类人是数据科学家，他们从Data LakeHouse中提取数据，以测试他们可能想要证明或反对的各种假设。数据科学家研究各种类型的数据：结构化的、非结构化的、原始的和处理过的。Data LakeHouse需要能够确保数据对于特定用途是容易识别的，用户必须精通许多编程语言和技术，包括Python、R和结构化查询语言(SQL)， 架构需要为这个用户提供正确的平台来创建和测试他们的模型。

♦数据分析师

使用Data LakeHouse的第二类人是分析师。他们主要是业务驱动的，寻求业务问题的答案，并且精通报表工具或基于SQL的语言。他们主要处理处理过的数据，他们的日常工作包括执行业务分析。通过查询、聚合和切片数据(主要是清理和处理的数据)来完成这项任务。DataLakeHouse应该迎合这样的用户，为他们提供一个平台，进行有效和无缝的数据分析。

♦管理人员

第三类大量使用Data LakeHouse的人是管理人员，他们需要定期的报表以进行业务决策。他们深入研究那些按特定业务需求处理过数据。他们可能是半技术通，可能需要一个使用商业智能(BI)工具创建报表或分析的地方。这些人通常通过报表系统获取他们所需的报表。

♦报表系统

Data LakeHouse的其他关键用户是报表系统。报表系统间接地迎合了希望订阅预定的、临时的或自助报表的人员。此外，可能还有其他类型的报表系统是为了监管报表。这些系统定期从Data LakeHouse中提取数据，然后存储报表以便交付。

♦下游应用系统

当数据从上游应用程序接入到Data LakeHouse时，下游应用程序也会使用处理过的信息。这些应用程序可能是OLTP系统，也可能是另一个数据仓库或数据湖，其任务与企业DataLakeHouse(EDL)不同。通常，用于下游消费的数据要么定期从Data LakeHouse中提取，要么使用一种可行的机制将数据推送到目的地。

♦基于应用程序编程接口(API)的系统

Data LakeHouse还需要能够以API的形式公开数据。DataLakeHouse处理各种类型的数据，需要服务于多个内部和外部系统。虽然紧密耦合的交付机制可能适用于特定的使用者，但基于API的数据使用是一种可伸缩且实用的选择。此外，基于API的系统还可以公开不属于组织的外部涉众所使用的数据。

♦数据共享系统

数据共享系统代表了一种新型的数据消费机制。当数据作为数据市场的一部分被消费或共享时，就会使用这种机制。当需要就数据使用的特定条款达成一致时，也可以使用数据共享机制。