数据中台技术选型最佳实践目录一、大数据演进，从数据仓库到数据中台 (3)二、数据中台架构与技术选型 (8)三、数据研发实践 (13)一、大数据演进，从数据仓库到数据中台第一阶段21世纪的第一个10年，企业级数据仓库（EDW）从萌芽到蓬勃发展，“IOT”( IBM、Oracle、Teradata)占领了大部分市场，提供数据仓库建设从硬件、软件到实施的整体方案。

这个时代的数据仓库实施不仅需要购买大（中、小）型机，配套商用的关系型数据库（Oracle、DB2、SQL Server）以及一些ETL/OLAP套件，实施成本相对高昂，数据仓库建设主要集中在金融、电信、大型零售与制造等行业。

数据仓库的应用主要通过为企业提供报表、分析等数据，辅助企业的经营决策。

像电信行业的经营分析系统、银行的风控管理等，都是这个期间比较典型的应用。

第二阶段2010-2015年，大数据平台阶段，移动互联网的飞速发展带动Bigdata(大数据)的发展。

其中Hadoop生态技术开始逐步在国内大范围使用，企业只要基于Hadoop分布式的计算框架，使用相对廉价的PC服务器就能搭建起大数据集群。

数据湖的概念也是这个阶段诞生（主要是为降低传统数仓较为复杂的中间建模过程，通过接入业务系统的原始数据，包括结构化、非结构数据，借助hadoop生态强大计算引擎，将数据直接服务于应用）。

这个阶段不只是金融、电信这些行业，国内主流互联网企业也纷纷搭建起大数据平台。

大数据应用更为丰富，不仅限于决策分析，基于APP/门户站点的搜索推荐、以及通过A/B Test 来对产品进行升级迭代等是这个阶段常规的应用点，用户画像在这个阶段也得到重视，主要应用于企业的营销、运营等场景。

第三阶段就是我们现在所处的阶段，数据中台以及云上大数据阶段，通过前10多年不断的技术积累，大数据在方法和组织的变革上也有了新的沉淀，主要体现在几个方面：1）数据统一化其核心思想是数据流转的所有环节进行统一化，如从采集到存储到加工等过程，在这些过程中通过建立统一的公共数据模型体系、统一的指标与标签体系，提高数据的标准性、易用性，让数据本身更好地连通，提升使用效率。

2）工具组件化数据在采集、计算、存储、应用过程中涉及多业务线条，多场景，将这些场景与工具（采集工具、管道工具、计算&调度工具、数据服务工具，数据管理工具、可视化工具等）进行沉淀，研发出通用、高效的组件化工具，避免重复开发，降低研发成本。

3）应用服务化之前大数据应用的数据调用比较混杂，有些直接访问数仓数据表，有些调用临时接口等。

通过数据中台应用服务化建设，提供标准的应用服务，以数据可视化产品、数据API工具等服务，支撑应用的灵活调用。

4）组织清晰化数据中台团队专注于数据内容&数据平台开发，提供各种基于数据的能力模块，而其他部门人员如业务产品、运营、分析等角色，只需要借助工具/产品有效地使用数据，发挥其价值，无需关注数据加工的过程，做到各尽其职，充分发挥各自专长，同样也能达到降本提效目的。

大数据团队内部本身组织和职责也倾于清晰化，比如按照职责分为平台（工具）研发、数据研发、数据产品、数据分析等不同组织。

当前阶段数据应用到各个角落，除了之前可以支撑的决策分析以外，大数据与线上事务系统（OLTP）的联动场景非常多，比如我们在电商平台查询个人所有历史订单，再比如一些刷单、反作弊的实时拦截，以及一些实时推荐等，这些都是通过将数据的运算交给数据中台部门处理，前台部门直接通过API进行结果调用。

数据中台的集中化建设也更好地支撑起创新业务，比如通过大数据+分析建立起商业化数据变现产品，进行数据售卖，把数据变成新的业务。

大家知道共享复用是中台建设中很关键的一个词，这也是为什么我们很多数据中台下面会包括共享数据组，公共数据组等。

实际上共享复用并不是大数据发展的一个新词，在早期数据仓库（建立公共数据模型）、大数据平台（研发一些组件化工具）的建设中，也是满足共享复用的。

如上提到，数据中台本身是组织，方法的升级与变革，更多是利用技术的进步更好地支持这些升级变革，如果你当前的建设还是数据平台+数仓（数据湖等）但是已经具备这些方法和特性，我个人认为也是合理的。

数据中台的建设也需要相应的成本与门槛，例如集群搭建、工具建设等。

云计算的发展可以快速提供数据中台建设的能力，例如企业无需自己搭建机房，使用云计算的弹性计算存储能力以及丰富的工具，可以支撑数据中台的快速搭建。

关于数据中台的合理性也一直颇有争议，大型（集团型）公司有相互独立的子公司，数据之间不需要太多连接与共享，分别构建自己子数据中台也是合理的架构，集团层面可以利用数据子中台进行数据上报解决集团层面数据大盘、统计、分析、财务等诉求。

再比如一些小型公司是否需要在一开始就按照数据中台的架构进行建设，也是存有一些争议。

数据中台是2015年阿里提出来的双中台的概念其中的一个重要组成，阿里作为先驱者，提供了数据中台架构、以及非常多的建设思路供大家参考。

从目前的建设效果来看，很多公司在数据中台建设中有不错的成效（尤其是大中型公司），数据中台整体思路得到了验证。

但是数据中台本身还算一个新鲜事务，这个新鲜事务目前还没有标准答案，只有参考答案。

二、数据中台架构与技术选型1、数据中台架构核心组成我认为的数据中台核心架构包括四大组成部分，具体是：•底座是数据基础平台，包括数据采集平台&计算平台&存储平台，这些可以自建也可以使用云计算服务；•中间部分两大块是中台的公共数据区，公共数据区包括数据仓库(数据湖) ，主要负责公共数据模型研发，还包括统一指标（标签）平台，负责把模型组织成可以对外服务的数据，例如数据指标、数据标签；•上层是数据应用服务层，主要将公共数据区的数据对外包装并提供服务，包括数据接口平台、多维查询平台，数据可视化平台、数据分析平台等。

另外，数据研发平台和数据管理平台贯穿始终，其中：1）数据开发平台包括数据开发的各类工具组合，例如：数据管道工具（比如数据接入、数据导出）、模型设计工具、脚本开发工具、数据调度工具等。

2）数据管理平台包括统一元数据管理、数据质量管理、数据生命周期管理。

针对数据全链路的数据管理，保证数据中台可以监控数据链路中的数据流向、数据使用效果、数据生命周期，以衡量数据的价值与成本。

以上是数据中台的核心部分，数据中台的组成也可以更加丰富，比如包括：数据资产平台、算法平台等等。

在数据中台的建设中一定不要忽视的是与业务的衔接，因为数据来源于业务并最终应用于业务，在数据中台的建设中需要有一系列的流程制度明确与业务的充分衔接，以保障数据源&数据产出的质量。

2、数据中台技术选型参考在搭建数据中台方面，基于开源技术的选型，尤其是Hadoop生态圈有非常多的选择，从数据整体流向来看各大层级的选型。

•数据抽取层：sqoop和flume是两大主流工具，其中sqoop作为结构化数据（关系型数据库）离线抽取，flume作为非结构化日志接入；•数据存储层：Hadoop文件系统Hdfs大家都比较了解，而kafka作为流式数据总线应用也非常广泛；•计算与调度层，包括：o离线计算：离线计算主要是hive，spark，也有部分选用tezo实时计算：前些年storm，spark比较流行，最近几年大家纷纷往Flink转型o数据调度：除了像Airflow Azkaban Oozie等，易观开源的Dolphin-scheduler也非常活跃•数据引擎层：也就是我们常说的OLAP层，我们看到这一层里的选择非常多，就不一一列举了，（业务需求带动技术进步的典型，选择丰富主要是可以适配不同的数据应用场景）。

从概念上讲分为ROLAP、MOLAP以及两者混搭。

MOLAP提前做一些预计算，以生成Cube的方式，达到空间换取查询效率；而ROLAP是即查即用，效率完全取决于查询引擎的性能，我个人认为从将来看，ROLAP的趋势会更加明显，因为没有中间的数据链路。

但目前看来，没有一个统一的引擎足以支撑各类数据场景（这或许是将来的机会~）；•数据可视化层：比较主流的有Metabase、Superset、Redash，也可以选择阿里、百度的一些开源控件。

在开源技术的选择里，我们看到各层里都有越来越多国内开源的工具（也充分体现了我们在大数据技术领域的进步）。

除了以上列举的这些，整个Hadoop生态圈的技术选择非常多，可以结合自己的实际场景选择自己的架构，在选型层面可以参照的一些原则，比如：•是否有鲜活的成功案例，优先找自己类似业务场景；•接口的开放性，与其他组件的兼容性；•社区活跃性度&发展趋势。

当然，数据中台的选型不只是开源技术，开源本身也不是完美的，例如维护开发成本较高，升级迭代不好把控，通过开源技术去建立数据中台还是有一定研发门槛。

所以也有很多商业化的套件、以及基于云的数据组件可以选择，包括数据采集、处理、分析、数据可视化全过程，国内外有很多厂商都提供了丰富的选择。

尤其在大数据可视化这块，国内有许多非常专业的商业套件。

三、数据研发实践1、数据处理架构下面是一个简单的数据处理架构演进过程：最早数据仓库的计算只支持批处理，通常是按天定时处理数据，在后期逐步进化到准实时，本质上还是批处理，只是处理频度上得有提升，到小时级，或者15分钟这种。

随着技术不断进步，后期演化出一条新的流处理链路，这个链路和之前的批处理分别处理，然后在服务层面利用大数据的计算能力进行合并，向外提供离线+实时数据服务，这也是著名的lambda架构。

最近几年随着Flink等技术的发展，有一个趋势是流批一体化，在接入层统一采用流式接入，计算层采用统一套框架支持实时计算+离线计算，批处理仅仅作为流处理的一个特殊场景进行支持。

整体上可以做到流处理、批处理的自由切换。

流计算和批处理在需求场景上有一些本质区别，前者主要用于支持线上业务场景（比如互联网的推荐、搜索、风控等），而批处理更多是支持离线统计分析。

日出而作，日落而息，大家针对大数据的统计分析习惯不会发生根本性变化，最简单的T+1批处理方式也还是数据应用必不可少的环节。

在使用同一套架构上，由于数据源变化&维度变化的多样性，批处理往往面临一些复杂场景，这是采用同一套框架上的一些难点，充分支持好批处理也是将来流批一体框架的发展方向。

2、数仓分层与主题分类1）数仓分层与传统ETL不同的，我们采用的是ELT的数据架构，较为适合在互联网，总体分为业务数据层、公共数据层、应用数据层三大层次。

①业务数据层（ODS层）原始数据经过缓冲层（STG）的加载，会进入数仓的业务数据层，这一层采用范式建模，基本保持与数据源完全一致的结构，对于变化的数据，使用数据拉链加工与存储。