6.1　基础架构

数据中台会出现的一个重要原因是，现有的大数据平台在架构上无法快速高效地支持数据能力的全局管理和共享复用。因此，采用合理的基础架构对于建立一个可持续发展的数据中台非常重要。

思考试验　考虑这样一个场景：某公司的广告部门想通过大数据平台来分析用户行为，实现广告的精准投放。因为该公司还没有大数据平台，所以广告部门就和IT部门一起安装了一个大数据平台，并开发了一些用户行为分析应用，形成了用户行为分析系统。这些应用实现了广告精准投放，带来了不错的效益，系统也开始稳定运行。用户增长部门看到这些应用效果不错，也想使用一下这个用户行为分析系统。问题是，如果它们在使用这个系统时出现问题，该由谁来负责？广告部门、用户增长部门还是IT部门？如果这个系统在建设时并没有考虑到其他部门的使用，那么修改系统的工作以及修改对系统造成的影响又由谁来负责？广告部门还是IT部门？

在面临上述问题时，我们经常看到，由于底层基础架构的支持不够，IT部门难以确定新功能会对现有生产系统造成什么影响。而由于新功能的影响不可预知，广告部门会对其有抵触情绪。这时一个能够快速落地的选择是，由IT部门在完全隔离的情况下再为用户增长部门设置一套集群，这样，各部门就可以独立开发，互不干扰。

还有一种情况是在同一个集群中重复开发。我们在一些实际场景中看到，部门A从一个生产数据库中采集了一些数据，建立了自己的数据仓库。部门B也有类似的数据仓库需求，但并不完全一致，由于部门A没有精力满足部门B的需求，但又不会将自己的数据仓库开放给部门B改动，于是部门B就自己采集数据，再建一套适合自己的数据仓库。这样，一些核心的业务数据库被重复采集许多遍。长久下去，每个部门都有一套自己的数据仓库，里面的语法和语义自成体系，导致整个数据的统一协调工作成为一项不可能完成的任务。

这种做法有其存在的合理性：在项目开始的阶段，大家可以快速独立开发，避免互相影响，加快落地的效率和迭代的速度。但是在使用大数据的部门增多之后，就会出现数据的重复使用、开发、存储，数据访问难以控制等问题，并且容易造成数据孤岛及应用孤岛，到数据运用达到一定规模时，数据就会变得难以管理。

我们认为，一个好的基础架构应当不仅能让项目快速落地，还能让企业的各个部门在现有系统上快速开发新功能、引入新数据，而不用担心与现有数据发生冲突。这个基础架构的核心需求是资源隔离、控制管理、可弹性扩充的资源和应用管理。因此，数据中台的基础架构应该有如下特征。

（1）云原生架构

用传统方式建设数据中台具有以下几个难点：

·传统的单体架构应用开发模式很难做到数据应用的快速落地、快速迭代，也很难保证数据应用能力的快速复用；

·新的大数据技术难以快速落地；

·难以解决多租户环境下的数据安全及性能问题；

·业务人员很难自助完成新的数据分析及探索工作；

·难以部署和运维分布式的计算框架和存储框架，以保证大数据分析的高性能。

基于这些原因，我们认为，数据中台的基础架构一定要是云原生的。云原生架构可以帮助我们快速开发、测试、迭代和上线大数据应用，轻松实现数据能力的共享和复用，实施统一的数据中台组件的标准化配置和管理，快速集成新的大数据、人工智能和机器学习开发工具，方便地部署和运行各种分布式计算框架和存储框架。

（2）多处理引擎支持

数据中台需要支持多种数据处理引擎来应对不同的数据分析场景。离线大规模数据的处理一般采用Hive或Spark计算引擎（Hive后台可以选择MapReduce或Spark引擎），而流数据的处理一般采用Kafka或Flink作为计算引擎。在海量的数据中，分析人员经常要进行随机查询，在这种场景下，Cassandra或HBase会表现得比Hive更出色。在传统的数据仓库中，分析人员基于多维数据模型（也称为数据立方体），利用OLAP技术进行多维度的数据分析，执行钻取、上卷、切片、切块及旋转等操作。

在大数据环境下，类似的OLAP计算引擎有Apache Kylin。如果分析人员要进行基于时序数据模型的分析，则可以采用InfluxDB等时序计算引擎。图计算也是大数据分析中常用的一种分析方式，应用领域包括社交网络、舆情分析、用户推荐等，目前流行的图计算引擎是Neo4j。

在引入这些计算引擎时需要注意的是，要将它们组织成整个组织中统一的全局计算框架，并纳入统一的多租户安全管理系统和全局数据资产管理系统。只有这样，我们才能实现全局的数据安全策略，并准确地评估这些计算引擎所消耗的资源和所产生的价值。

（3）集成的数据及应用管理

如上所述，数据中台应该可以同时管理批处理数据和流数据，以及多种处理引擎和分布式数据存储。我们经常看见在一些企业的实施环境中，各种集群、系统都有各自的管理界面、报警系统、元数据系统，这在后期会导致数据资产不明确、使用复杂、效益不明确等问题。为了避免这种情况，我们必须通过这种统一的管理模式进行统一的数据应用资产管理，全局把握数据、资源、中台使用者以及应用之间的关联关系，实现高效的集群资源利用，使分析人员可以快速进行大数据应用的开发、迭代、共享和复用。

（4）灵活方便的多用户支持

多用户是数据中台必须支持的一个功能。在多用户的环境下实现数据和应用的隔离，才能让各业务部门有意愿在数据中台的安全环境下进行数据能力的开发和迭代，把部门的私有数据隔离保护起来，同时把可以公开的数据能力抽象并共享，供其他部门复用。

数据中台的多用户支持一定要灵活方便，应该可以通过通用的LDAP或OpenID协议直接对接公司的用户系统，而不需要另建一套独立的用户系统。使用同一套用户系统管理一家公司内所有IT平台架构的好处是，当公司发生人员变化的时候，只要在一个用户系统内进行人员或组织架构的更新，就可以将这种更新覆盖到公司所有的IT系统中。在不同的IT平台架构中使用不同用户系统的安全隐患是显而易见的，如果IT部门在更新时遗漏了某一个平台的用户系统，则会在这个平台中留下安全漏洞。

数据中台的多用户支持还要与全局的数据资产管理结合起来，数据中台的用户是组织的一种资产，通过分析这些用户与数据、应用、资源的关联关系，可以准确地评估公司各业务部门在数据中台中所使用的资源及其产生的价值。公司可以将这种评估纳入数据中台的绩效管理，进一步激发各业务部门使用数据中台驱动业务发展的积极性。

（5）端到端的安全审计

在数据中台的建设过程中，实现端到端的安全审计是保证数据中台安全性的必要手段。但是在大数据的环境下，数据类型、计算引擎的多样性以及不断增长的海量数据和数据应用，使得安全审计的实施具有很大挑战。一般来说，数据中台的安全审计要重点关注以下几个功能的实现。

·兼容性：首先是支持不同的数据类型，包括结构化数据和非结构化数据、批处理数据和实时数据、存储在各种不同存储系统中的数据；其次是支持不同的数据采集及数据处理引擎，例如批处理和实时处理引擎。

·快速检索：安全审计数据是一种大数据，因此数据中台要提供安全审计数据的快速检索，并能够提供整个事件端到端的回溯，直观地分析整个事件的关联性。

·敏感数据处理：审计数据会包含一些敏感数据，因此要对审计数据进行安全认证和授权管理，避免敏感数据泄露。

·安全报警：对于海量的安全审计数据，很难通过人工监控，因此数据中台一定要实现安全审计数据监控和报警的自动化，当发生违反安全规范的事件时，能够自动通知安全管理人员及时处理。

（6）高效的开发及运维流程

在云原生架构下构建的数据中台是以容器化的方式来部署大数据的基础组件，而大数据应用则是在微服务架构下进行开发并以容器化的方式在数据中台中运行，云原生的DevOps和CI/CD流程可以使开发团队快速迭代和更新大数据应用，并轻松进行数据中台的运维工作。