来个近距离接触“数据中台”的建设思路，供大家参考，但一千个人眼里就有一千个数据中心。什么是数据中心？数据中心包含什么？图片来自Pexels。本文分享的主题主要包括以下几大内容：带大家回顾一下中国大数据的发展历程，从传统的数据仓库到现在的数据中心的演进过程。个人认为数据中心的核心组成和一些技术选型参考。数据研发是数据中台非常重要的一环，我们将分享我们在数据研发方面的一些实践，主要是在数据仓库架构和研发方面。大数据的演进，从数据仓库到数据中心的第一阶段21世纪的第一个十年，企业级数据仓库（EDW）从萌芽发展到蓬勃发展，“物联网”（IBM、Oracle,Teradata)占据了大部分市场，提供了从硬件、软件到实施的数据仓库建设整体解决方案。这个时代数据仓库的实现不仅需要购买大（中、小型）机器，还需要配套商业关系数据库（Oracle、DB2、SQLServer）和一些ETL/OLAP套件。实施成本较高，数据仓库的建设主要集中在金融、电信、大型零售和制造等行业。数据仓库的应用主要是为企业提供报表、分析等数据，辅助企业的经营决策。比如电信行业的业务分析系统、银行的风控管理就是这一时期的典型应用。第二阶段，2010-2015年，为大数据平台阶段。移动互联网的快速发展带动了Bigdata（大数据）的发展。其中，Hadoop生态技术在国内也逐渐开始广泛应用。企业只要基于Hadoop这个分布式计算框架，就可以使用相对便宜的PC服务器搭建大数据集群。数据湖的概念也在这个阶段诞生（主要是为了减少传统数据仓库复杂的中间建模过程，通过访问业务系统的原始数据，包括结构化和非结构化数据，借助Hadoop强大的生态计算引擎，数据直接发送到应用程序）。现阶段，不仅是金融、电信等行业，国内主流互联网企业也纷纷搭建大数据平台。大数据应用更加丰富，不局限于决策分析，基于APP/门户网站的搜索推荐，通过A/BTest进行产品升级迭代是现阶段的常规应用点，用户画像也是现阶段看重的stage，主要用于企业的营销运营场景。第三个阶段就是我们现在所处的阶段，数据中心和大数据上云阶段。通过近10年技术的不断积累，大数据在方法和组织的变革上也有了新的沉淀，主要体现在几个方面：①数据统一的核心思想是统一数据流通的各个环节，例如从收集到存储到处理。在这些过程中，建立统一的公共数据模型体系、统一的索引和标签体系，提高数据的标准化和易用性，使数据本身更好地连接起来，提高使用效率。②工具组件数据在采集、计算、存储、应用过程中涉及多条业务线、多场景。将这些场景与工具（采集工具、流水线工具、计算调度工具、数据服务工具、数据管理工具、可视化工具等）结合起来，开发通用高效的组件工具，避免重复开发，降低研发成本.③在应用服务之前，大数据应用的数据调用比较杂乱，有的直接访问数据仓库数据表，有的调用临时接口等。通过数据中心应用的服务化建设，提供标准的应用服务，以及通过数据可视化产品、数据API工具等服务，支持应用的灵活调用。④组织清晰数据中心团队专注于数据内容和数据平台开发，提供各种基于数据的能力模块。而其他部门的人员，如业务产品、运营、分析等，只需要借助工具/产品有效利用数据，发挥其价值，不需要关注数据的处理过程加工。他们可以各司其职，充分发挥各自的特长。可以达到降本增效的目的。大数据团队的内部组织和职责也趋于清晰。比如根据职责分为平台（工具）研发、数据研发、数据产品、数据分析等不同组织。现阶段，数据应用到每一个角落。除了之前可以支持的决策分析，大数据与在线交易系统（OLTP）的联动场景还有很多。比如我们查询电商平台所有的个人历史订单，还有一些其他的例子，反作弊实时拦截，还有一些实时推荐。这些都是把数据计算交给数据中心部门，前端部门直接通过API调用结果。数据中心的集中建设也可以更好地支持创新业务，比如通过大数据+分析建立商业数据变现产品，销售数据，将数据转化为新的业务。大家都知道，共享和复用是中台建设的一个关键词，这也是为什么我们很多数据中台都会包含共享数据组，公共数据组等。其实共享和复用并不是一个新词。大数据的发展。在早期数据仓库（建立公共数据模型）和大数据平台（开发一些组件工具）的建设中，也满足共享和复用。上面说了，数据中心本身就是一个组织，方式的升级和变化更多的是利用技术的进步更好的支持这些升级和变化。如果你现在的建设还是数据平台+数据仓库（数据湖等）但是已经有了这些方法和特点，我个人觉得也是合理的。数据中心的建设也需要相应的成本和门槛，比如集群建设、工具建设等。云计算的发展可以快速提供构建数据中心的能力。比如企业不需要自建机房。利用云计算的弹性计算存储能力和丰富的工具可以支撑数据中心的快速建设。数据中心的合理性也一直颇受争议。大（集团）公司都有独立的子公司，数据之间不需要太多的连接和共享。建立自己的子数据中心也是一种合理的结构。集团层面可通过数据子中台上报数据，解决集团层面的数据市场、统计、分析、财务等需求。再比如一些小公司是否需要从一开始就按照数据中心的结构来建设，也存在一些争议。数据中心是阿里在2015年提出的双中台概念的重要组成部分，作为先行者，阿里提供了数据中心的架构和大量的建设思路供大家参考。从目前的建设成果来看，很多企业（尤其是大中型企业）的数据中心建设都取得了不错的成绩，数据中心的整体思路得到了验证。然而，数据中心本身仍然是一项新业务。这个新业务没有标准答案，只有参考答案。数据中心架构与技术选型数据中心架构的核心组成我认为数据中心的核心架构包括四大组成部分，具体来说：基础是基础数据平台，包括数据采集平台&计算平台&存储平??台，可以是自建也可以使用云计算服务。中间的两个区块是中间平台的公共数据区。公共数据区包括数据仓库（数据湖），主要负责公共数据模型的研发，还包括统一指标（标签）平台，负责将模型组织成数据，可外部服务，比如数据指标，数据标签。上层为数据应用服务层，主要对公共数据区的数据进行封装并提供服务，包括数据接口平台、多维查询平台、数据可视化平台、数据分析平台等。此外，数据研发平台和数据管理平台贯穿其中：数据开发平台包括数据开发的各种工具组合，如：数据管道工具（如数据接入、数据导出）、模型设计工具、脚本开发工具、数据调度工具等。数据管理平台包括统一的元数据管理、数据质量管理、数据生命周期管理。针对整个数据链路的数据管理，确保数据中心能够监控数据链路中的数据流向、数据使用效果、数据生命周期，衡量数据的价值和成本。以上是数据中心的核心部分，数据中心的组成还可以更加丰富，包括：数据资产平台、算法平台等。在数据中心平台的建设中，不可忽视的是与业务的连接，因为数据来源于业务，最终应用到业务中。在数据中心平台的建设中，需要一系列的流程体系与业务充分对接，以保证数据源和数据输出的质量。数据中心技术选型参考在构建数据中心方面，基于开源技术的选择有很多，尤其是Hadoop生态系统。从整体的数据流向来看，我们可以看一下各个层级的选择。数据抽取层：Sqoop和Flume是两大主流工具，其中Sqoop作为结构化数据（关系型数据库）进行离线抽取，Flume作为非结构化日志访问。数据存储层：Hadoop文件系统HDFS众所周知，Kafka也被广泛用作流数据总线。计算与调度层，包括：离线计算：离线计算主要使用Hive、Spark，部分使用Tez。实时计算：前几年比较火的是Storm和Spark。这几年大家都在向Flink转型。数据调度：除了AirflowAzkabanOozie等，易观开源的Dolphin-scheduler也很活跃。数据引擎层：也就是我们常说的OLAP层。我们看到这一层的选择很多，就不一一列举了（典型的业务需求驱动技术进步的例子，丰富的选择主要是为了适应不同的数据应用场景）。从概念上分为ROLAP、MOLAP，以及两者的混合。MOLAP提前做一些预计算生成Cube来交换空间来提高查询效率。但是ROLAP是即时查询，其效率完全取决于查询引擎的性能。我个人认为未来ROLAP的趋势会更加明显，因为没有了中间的数据链路。但是目前好像还没有一个统一的引擎足以支持各种数据场景（这可能是以后的机会~）。数据可视化层：比较主流的有Metabase、Superset、Redash，也可以选择阿里、百度的一些开源控件。在开源技术的选择上，我们看到各个层级的国产开源工具越来越多（也充分体现了我们在大数据技术领域的进步）。除了上面列出的这些，整个Hadoop生态系统中还有很多技术选择。您可以根据自己的实际场景选择自己的架构。在选择层面可以参考一些原则，比如：是否有新鲜的成功案例，优先寻找自己相似的业务场景。接口的开放性，与其他组件的兼容性。社区活动&发展趋势。当然，数据中心的选择不仅仅是开源技术，开源本身也不是完美的。比如维护开发成本高，升级迭代不易控制等。通过开源技术建设数据中心仍然存在一定的研发门槛。因此，也有很多商业套件和基于云的数据组件可供选择，包括数据采集、处理、分析和数据可视化的全过程。众多国内外厂商提供了丰富的选择。特别是在大数据可视化领域，国内有很多非常专业的商业套件。数据研发实践数据处理架构下面是一个简单的数据处理架构演进过程：最早数据仓库的计算只支持批处理，通常按日处理数据，后期逐渐演进到准实时阶段，本质上还是批处理，但是处理频率要提高，到小时级别，或者15分钟。随着技术的不断进步，后期又演化出一个新的流处理环节。这个环节和之前的批处理分开处理，然后在服务层面进行融合，利用大数据的计算能力，提供离线+实时的数据服务。这也是著名的Lambda架构。近年来，随着Flink等技术的发展，出现了流批融合的趋势。接入层统一采用流式接入，计算层采用统一的框架，支持实时计算+离线计算。批处理仅用作流处理。支持的特殊场景。整体上可以实现流处理和批处理的自由切换。流计算和批处理在需求场景中有一些本质的区别。前者主要用于支持在线业务场景（如互联网推荐、搜索、风控等），而批处理则支持更多的离线统计分析。日出而作，日落而息，大家对大数据的统计分析习惯不会发生根本改变，最简单的T+1批处理方式依然是数据应用不可或缺的一部分。在使用同一架构时，由于数据源变化&维度变化的多样性，批处理往往会面临一些复杂的场景。这是采用相同框架的一些困难。全面支持批处理也是流批一体化框架未来的发展方向。方向。数据仓库层次结构和主题分类①数据仓库层次结构不同于传统的ETL。我们使用更适合互联网的ELT数据架构。一般分为三个层次：业务数据层、公共数据层、应用数据层。业务数据层（ODS层）：原始数据经缓冲层（STG）加载后进入数据仓库的业务数据层。该层采用范式建模，基本保持与数据源完全一致的结构。对于变化的数据，采用数据拉链处理和存储。该层范式建模的选择是指维护源系统（如关系数据库）的范式结构。主要优点是：一次性访问数据源结构，不需要为了需求变化而频繁连接数据源。方便业务研发更好的理解数据，也是企业的原始数据资产。使用数据拉链改变数据的好处：在保留历史数据的同时，尽可能少占用存储空间。从长远来看，与每天保存完整历史记录相比，拉链存储可节省约90%的空间。快速高效获取业务系统历史任意一天的快照数据。公共数据层（包括公共明细层DWD和公共汇总层DWS）：公共数据层是数据仓库的核心层，在整个数据仓库中使用最多。该层主要采用维度建模的思想进行设计，类型包括交易事实、周期快照、累积快照。同时，为了方便数据下游的使用，我们会设计一系列的宽表模型来整合不同业务流程中的事实，包括纵向整合&横向整合。对于可能分散在不同源系统的商品和用户主数据，采用垂直整合；横向整合主要包括交易、内容等行为数据不同业务流程的整合。例如：用户（用户信息、注册信息）购买（下单、支付、结算、续费、完成）商品（商品信息、商家信息等）。我们将订单流业务流程整合到一个明细表中，同时开发一些基于用户或产品角度的轻型汇总宽表。宽表非常容易理解和使用，也方便下游应用调用。我们之前做过一些统计。从调用分布来看，宽表的使用占比超过70%。虽然宽表的使用在数据仓库建模中很常见，但也存在一些缺陷：数据冗余较多，在存储、计算、调用等方面占用资源较多。建议尽量根据场景使用。宽表集成了很多信息，数据权限不好控制。建议可以根据需要在限定范围内开放整体宽表权限，也可以通过视图或分表建立不同权限的数据范围，以满足不同组织的需求。宽表通常有很多依赖关系，会影响数据输出的时效性。应用数据层（DWA层）：顾名思义就是偏向于应用的数据处理。也可以称为集市层。这一层的设计可以比较灵活，只要贴近应用即可。整体的设计思路还是可以以维度建模为主。.学科分类数据仓库架构中的数据分类有两个视角，包括学科视角和业务视角。①从数据主题的角度来看，最重要的是我们经常提到的数据仓库主题。主题是从宏观数据中抽象出企业的业务，宏观数据是数据仓库中数据的主要组织形式。划分方法如下：参照波特价值链，分析企业自身经营的业务（基本活动和辅助活动），以及对应哪些数据。参考行业内的通用模型，例如IBM、TD等对大行业（如电信、金融、零售）的数据主题有一些通用的划分方法。对公司内部数据（在线数据模块、数据字典）进行彻底调查，并确认哪些主题与其相对应。划分结果将分为三个层次：第一层次为主题域，针对相对稳定的主题进行合并，归入主题域，有利于数据理解和全球数据资产目录的建立。第二个层次是主题。第三层是分主题，主要是一些类别比较多的主题。例如，供应链话题会包含采购、仓储、配送等子话题。建议数据主体划分完全互斥，不建议重复。②数据业务视角数据业务域是根据企业的具体业务，结合企业的组织架构来划分的。层级和分类可以相对灵活，子类可以重复，因为两个不同的业务领域可能经营同一个业务，比如电子商务和内容有会员业务。上图是典型的内容+电商数据主题和业务分类。以上两个角度，一横一纵，更好的对数据进行分类，在数据模型设计中打上相应的分类标签，让数据研发和数据使用者有一个统一的认识。以上两种分类方式主要用于核心公共数据层。业务数据层和应用数据层不需要遵循上述分类规则。例如，业务数据层（ODS层）根据数据源进行分类，应用数据层（DWA）根据具体应用进行分类。除了数据研发过程结构合理外，数据研发过程也很重要。整体流程如下：包括需求分析/数据调研、数据模型设计、数据开发测试、上线发布等流程。之前数据平台的核心架构提到，我们不要闭门造车。数据研发需要与业务部门充分对接。比如在数据研究方面，我们需要对业务研发的同学进行在线数据&结构访谈。数据开发方面，与分析&业务同学一起确定标准口径；数据研发完成后，将对数据用户进行数据发布和培训。在以上过程中，除了需求调研，我们在线上进行了其他部分，包括数据模型设计。早期我们会手写Mapping文档，后来逐渐把Mapping文档做成线上。通过模型设计工具完成了整体的数据模型设计，包括从概念模型、逻辑模型到物理模型的设计。模型设计完成后，一键生成数据知识文档：数据生命周期管理数据研发完成，还需要关注数据生命周期：一方面是数据的快速增长体积不仅需要大量的存储，比如自建机房，还会涉及到机柜的扩容，机房往往会面临一些瓶颈。另一方面，大量的数据会降低数据的计算效率，所以我们需要从数据的产生开始考虑生命周期，根据数据的使用情况制定数据归档、数据销毁等管理策略.针对已经占用大量存储资源的数据，可以采取一系列措施来控制成本，例如：减少库存：通过数据压缩技术，减少副本等，对数据进行更合理的设计模型，可以减少现有数据的存储。增量控制：根据数据重要性、可恢复性等考虑，确定数据保留期限，并根据期限自动归档或删除。成本分摊：通过数据调用分配、需求来源等一些算法，将成本分摊到相应的业务部门，让相关业务部门关注成本。数据安全也是数据生命周期管理中的一个重要问题。例如，对于敏感的用户信息，访问时需要考虑如何加密。一种方式是通过独立的物理集群隔离敏感数据并对其进行强控；在数据使用过程中，还需要将数据划分为不同的安全或敏感级别（例如，某些财务数据非常敏感，需要谨慎对外开放），根据不同的级别设置不同的访问权限机制。此外，还需要制定配套的数据归档和销毁安全管理措施，规避安全风险。数据质量管理数据质量管理主要包括三个方面：准确性、及时性和一致性。管理环节包括：事前、事中、事后、事故管理。传统的数据运维告警发送方式主要是短信、邮件、电话；随着移动办公工具的功能逐渐强大，运维告警可以以数据接口的形式与这些工具对接，将告警发送到企业内部的即时通讯工具。数据应用架构数据研发最终需要为业务和应用赋能，合理的数据应用架构非常关键。这张图是应用架构的简化图，供参考：从数据流向上：数据仓库（或数据湖）：负责原始数据的计算，主要是将数据落地到HDFS。数据引擎层：数据处理完成后，将数据推送到不同的引擎。这一层的选择很多，大家可以根据自己的场景选择混搭组合。比如我们目前选择Presto、Kylin、Druid、MySQL。数据服务层：通过统一的SQL调用服务，在底层屏蔽不同的数据引擎，在上层提供统一查询的标准接口。指标平台：指标平台是一个非常关键的产品，定位于连接数据研发和数据应用，包括指标的标准定义、逻辑、计算方法、分类等内容。在指标分类上，我们分为标准指标（指标口径已审核）和非标准指标。多维查询：这是我们的即席查询工具。查询数据的主要来源是指标平台。可以选择指标维度的不同组合来呈现结果。用户可以一次性查询结果，也可以将查询结果配置成可视化报表。治疗。中间是统一的元数据管理：统一管理整个架构中可以对外提供服务的元数据（包括数据仓库的元数据、查询引擎的元数据、指标的元数据等），并对这些元数据的调用进行监控。最右边是权限管理：权限管理关系到数据安全，需要在设计时慎重考虑。比如可以在表级别、索引级别、维度级别进行控制；在产品层面，权限审批级别和人员也需要灵活配置。在面向用户的使用层面，我们主要开放多维查询&可视化。用户通过多维度查询各种指标&维度数据，得到数据结果列表，然后选择可视化配置面板，完成各种图表表格的自主配置，并发布到个人看板或业务行情目录。配置好的数据仪表盘也可以灵活组合，定制小数据产品。数据ROI评估在数据研发中，还应该考虑数据的ROI。下面是一个简单的ROI模型：根据activity（调用次数等）、coverage（通过血缘关系查出依赖的数量）、contribution（取决于数据重要程度）来确定数据的价值。同时对数据的成本指标（如计算成本、存储成本等）进行评估。通过以上两者的划分，可以综合得到数据的ROI。根据ROI，可以将数据划分为不同的层级，并据此进行数据治理。比如对于价值低、成本高的数据，可以考虑下线。数据研发趋势&重点：效率提升：目前大部分数据研发工作都可以借助工具研发实现线上化。未来可以借助AI等能力，实现数据处理，包括开发、运维自动化，提高处理效率。Flexible：流批一体化，包括流处理和批处理之间的自由切换，前面已经讲过，个人认为也是一个发展趋势。降低成本：数据研发环节的成本控制，在数据建设初期通常不会引起太多关注。随着数据量的不断积累，存储和计算成本往往成为瓶颈。需要提前考虑数据建设的成本。算力：我们看到谷歌、IBM、阿里都在研究量子计算。未来的数据中间层（比如数据仓库的公共模型）是否可以考虑虚拟化（比如只保留规则&数据结构），具体的数据内容在应用程序发起的时候，可以调用和调用即刻使用，更多时候不需要占用存储资源。计算能力的不断提升，可能会颠覆一些传统的数据构建思路。作者：闫博简介：现任马蜂窝数据仓库团队负责人，曾就职于京东、IBM、亚信等公司。数据行业资深人士，经历过传统数据仓库、大数据平台、数据中台的发展历程。编辑：陶佳龙来源：转载自微信公众号DBAplus社区（ID：dbaplus），本文根据闫博先生在〖深加直播218号〗分享的演讲内容整理而成。
