189 8069 5689
数据中台的典型功能架构：
广义的讲数据中台是直接服务于业务系统的数据服务工厂，狭义上讲，数据中台就是可复用的数据API。
站在企业架构的角度，从广义上来讲，数据中台(包含数据平台，数据仓库）应该提供的服务如下图所示：
1.数据资产的规划和治理
做中台之前，首先需要知道业务价值是什么，从业务角度去思考企业的数据资产是什么。数据资产不等同于数据，数据资产是唯一的，能为业务产生价值的数据。对于同一堆数据，不同业务部门所关注的数据指标可能完全不同，怎么让各个跨域的业务变成统一的标准，就需要规划企业的数据全景图，将所有有可能用上的、所有对企业有可能有价值的数据都规划出来，最终梳理出企业的数据资产目录。
在这个时候不需要考虑有没有系统、有没有数据，只需要关注哪些数据是对企业业务有价值的。这一层不建议做得太细，太细就难以形成标准，不能适用于多个场景了。
数据治理是数据中台很重要的一个领域，ThoughtWorks认为在现在业务边界消失、需求快速变化的情况下，企业需要具备精益数据治理的能力 — — Lean Data Governance。传统的中心化、事前控制式的数据治理方式，要改变为去中心化、事后服务式的治理方式。
2.数据资产的获取和存储
从广义上来讲，数据中台要为企业提供强大的数据资产的获取和存储的能力。但是这个能力不是数据中台的核心功能，很多企业可以基于原来的数据平台，数据仓库等已有的工具来提供数据采集和存储的能力。
3.数据的共享和协作
企业的数据中台一定是跨域的，需要让所有的人都知道数据资产目录在哪里。不能因为数据安全，就不让大家知道企业有什么数据。没有共享和开放，数据没有办法流动起来，没有流动的话数据的价值产生的速度就会非常慢。
所以在数据安全的基础上，企业的数据资产目录要对利益相关者、价值创造者开放，要让业务人员能够做到“Self-Service”。
数据资产目录是数据中台很核心的一个基础能力，但是往往目前很多的企业都尚未建立这个能力，这也是导致数据在企业内部不开放，不共享，不被利用的很重要的一个原因。
4.业务价值的探索和分析
数据中台不仅要建立到源数据的通路，还需要提供分析数据的工具和能力，帮助业务人员去探索和发现数据的业务价值。一个好的数据中台解决方案中需要针对不同业务岗位的用户提供个性化的数据探索和分析的工具，并且在此基础上一键生成数据API，以多样化的方式提供给前台系统。
5.数据服务的构建和治理
数据中台需要保证数据服务的性能和稳定性，以及数据质量和准确性，还需要具备强大的服务治理能力。数据服务要在一开始就有整体的顶层设计，从而能够将数据服务做分类，打标签，能够更方便的被搜索被调用，让好的服务浮现出来，让质量不高的服务自动的退市被销毁。
数据中台是一个生态平台，在数据中台上面会不断生长各种数据服务，所以从一开始就构建好数据服务的治理结构是非常重要的，就想经营一个市场一样。
6.数据服务的度量和运营
如果数据中台最终只是做到把数据给到业务人员，那它就只是一个搬运工的角色，数据中台的核心是为业务应用提供有业务价值的数据服务。所以度量和运营数据服务的能力是数据中台的业务能力。
数据中台应该能够对提供的数据服务及相关行为做持续跟踪和记录，包括哪些数据服务被哪个部门使用、用了多少次等，通过这些去度量每一个数据服务的业务价值。
数据中台是一个需要用互联网思维去经营的利润中心平台，数据中台的经营分析人员需要分析，了解为什么今天上午这个财务部门的人用了数据中台、调用了十次，下午他不用了，原因是什么，调用了这些数据服务的人通常还会调用哪些其他的数据服务。
这些都需要相应地做记录、做日志、做分析，要把数据当做像电商平台一样去经营，然后实时地根据这些业务行为数据去提醒数据服务提供方，调整、改变、优化数据服务，这才是可经营的数据中台，也只有这样业务部门才能得到最快的支持和响应。
一个数据中台的典型逻辑功能架构单初步定义：
企业数据中台的团队如何构建：
数据中台是距离业务更近的能力平台，数据中台是一个需要持续运营的数据服务业务平台，所以数据中台的团队不仅仅是一个技术团队，应该将数据中台当做一个产品团队来构建，整体的结构如下：
数据中台提供两类服务：
一类是数据资产目录，数据探索，数据分析等服务，让业务和应用部门的人员能够在数据中台上协作的玩数据。
一类是数据服务，让各个业务系统能够调用这些服务，包括决策分析类的非实时服务和实时的嵌入式交易规则服务。
对应到这两类服务，数据中台的团队应该包括以下三组：
中台运营团队：
将整个数据中台的服务和功能作为产品来运营，对应的绩效是用户满意度，用户存留，这些用户相关的指标。
中台开发团队：
负责数据中台的功能层开发，包括平中台本身的架构，中台上的应用（客户服务，业务监控等）功能的开发，对应的绩效是功能的稳定性和客户的满意度。
数据服务开发团队：
负责数据中台之上的数据服务的开发，包括数据处理链的开发，服务的开发等，对应的绩效是数据服务的稳定性， 性能和客户的满意度等。
参考这样的三个团队组成， 分别应该包括如下角色：
数据中台架构师：进行整体数据中台的技术架构设计，保证数据中台架构的可持续性，稳定性和扩容弹性。
DataOps工程师：从基础能力上保障数据中台的运行的稳定性和持续演进。
数据工程师：数据处理工程师，负责数据的获取，处理，建立数据处理链。
数据服务产品团队：数据服务的产品团队，包括产品经理(PO)，业务分析师，体验设计师，还有算法工程师，和数据工程师和数据运营分析师一起协作，创新、设计、生产数据服务。
数据运营分析师：将数据服务作为产品来运营的数据运营分析师，通过对数据服务上线后被调用的情况的分析来运营数据服务，像经营一个互联网产品一样来经营数据服务。
数据中台某种角度上，上是一个数据服务的创新、生产、交易的数据服务市场，那么企
业对于数据中台整体的绩效评价方法也就出来了，那就是：
企业评价数据中台的标准：数据中台服务的客户，也就是业务系统的满意度。
数据中台支撑技术：
建设数据中台一般需要一整套如下典型的支撑技术：
指标管理系统：指标是中台与前台之间最关键的接口，也是建设数据中台的牛鼻子，因为它是最核心的业务语言，且指标不一致、数据常出错是建设数据中台最常见的出发点。如果指标体系没有统一的方法论，进行统一建设，那么就很难说是数据中台。指标管理系统一般要实现一套一致的方法论（如原子 / 派生 / 复合指标、维度、修饰词等），做好指标的业务和技术口径管理，还需要支持指标的审批管理。数据中台的指标无法交给各前台业务自助式的建设。
数据服务系统：类似于在线业务中台需要通过API网关提供标准化的服务，数据中台也需要一个标准化的服务方式，通常称为数据服务系统，也可以说是数据网关或数据门户。类似于别的网关类产品，数据服务系统需要提供鉴权、日志审计、流控、协议转换（如SQL Dialect之间的转换）等功能，也应该发展多引擎融合查询、逻辑模型等扩展功能以提高服务接口的稳定性和实现的灵活性。
元数据管理系统：元数据管理是整个数据中台的基础和中心，所有的其他系统都依赖元数据管理。元数据管理首先要做好的当然是数据模式或目录（catalog）的管理，至少要知道中台里都有什么数据。对复杂的数据中台来说，数据血缘也很重要。没有血缘信息，不知道数据间的依赖关系，数据质量肯定管不好，因为不知道一个数据的质量问题怎么来，又进而会影响什么。
同样的，如果没有血缘，数据资产也肯定管不好，因为不知道什么数据有价值什么没价值，这就像如果你不知道一个函数被谁调用，你就不知道它是不是死代码一样。元数据管理系统往往也需要提供一个基础的访问界面，通常称之为数据地图。
数据仓库开发与管理系统：除了指标管理，数据仓库的开发是将一大堆初始数据建设梳理成一个漂亮的数据中台的核心过程。一般来讲数据中台更适合用Kimball的维度建模方法而非数据仓库之父Bill Inmon所提倡的方法，这是因为Inmon强调顶层设计，而Kimball强调至下而上。
如果要建设数据中台，肯定是因为前台业务复杂多变，这时强调顶层设计会导致中台建设缓慢、僵化。因为中台虽然应该是由组织高层决策，但目的却是为了支持前台业务，而不是为了控制。*支持而不是控制*，这一点绝不能本末倒置。
数据质量管理系统：所有复杂的系统都需要专业的质量管理，在线业务系统有一系列的弹力设计和APM等监控运维工具，数据中台也需要专业的质量管理。数据质量管理系统通常设计为支持丰富的稽核 / 校验 / 比对规则，监控数据是否准确、实时、一致，还要做到及时的报警，分析影响面，提供快速修复的手段等。
但这些手段只能发现和补救问题，不能预防问题，要预防问题，还要通过测试工具减少代码bug、通过资源弹性应对性能波动、通过优先级调度优先满足重要业务需求等。
相对来说，当前数据中台领域的质量管理没有在线业务领域的成熟，如在线业务领域的测试手段远比数据领域的精细，在线业务领域很常见的熔断、限流、服务降级等模式在数据领域都没有成熟的实践方法（优先级调度可以说是实现了部分的服务降级功能），随着数据中台越来越广泛和重要，这些技术应该也需要持续发展，但技术上的挑战不小。
数据安全管理系统：数据中台因为汇集了组织所有有价值的数据资产，因此良好的安全管理是必须的。细粒度的权限和审计是基础，一般的还需要隐私 / 敏感数据的脱敏处理、数据加密（特别是将数据托管在第三方平台之上时）、数据泄漏防护（比方说一种常见的方法是限制将数据下载到本地的数据量）等技术。发展到高级阶段甚至可能还需要联邦学习、数据沙盒等技术。
数据资产管理系统：在数据质量和安全单列的情况下，数据资产管理主要负责的是数据的生命周期管理、成本的统计分析与优化等工作。
同时，数据中台还需要强大的大数据计算引擎、数据集成 / 同步 / 交换引擎，还往往需要一套敏捷BI系统：
大数据计算引擎：数据中台要管理的数据规模和复杂度往往都很高（否则搞中台属于为赋新词强说愁），所以传统的数据库和数据仓库基本上支撑不了。当前的技术环境下，基于Hadoop MapReduce或Spark几乎是唯二的选择，当然这也包括了这两者之上的Hive和Spark SQL。能有SQL就用SQL，易于维护，也易于数据血缘的收集。除此之外，流处理可能还需要Flink，交互式查询可能要引入Impala或GreenPlum。
数据集成 / 同步 / 交换引擎：一方面数据中台需要强大的数据集成和同步能力才能吸纳各方数据。集成和同步的概念相近，同步更强调实时性。另一方面，数据中台往往由多种数据计算引擎构成，就需要同步或交换引擎实现不同引擎见的数据交换。
敏捷BI系统：建设数据中台通常最重要的目的是为了支持业务运营和决策，为此需要基于数据中台进一步开发数据产品。敏捷BI系统是开发数据产品快速、轻型的手段，能够尽快尽早的发挥数据中台的价值。
此外，对于互联网业务，统一的埋点引擎往往也是数据中台所需要的。如果埋点的逻辑都不统一的话，建数据中台的时候会发现数据的源头就是乱的，后续也都没法做。其他行业业务，数据采集也属于基础工作，也是要先做好的。
数据中台技术选型参考：
在搭建数据中台方面，基于开源技术的选型，尤其是Hadoop生态圈有非常多的选择，从数据整体流向来看各大层级的选型。
数据抽取层：sqoop和flume是两大主流工具，其中sqoop作为结构化数据（关系型数据库）离线抽取，flume作为非结构化日志接入；
数据存储层：Hadoop文件系统Hdfs大家都比较了解，而kafka作为流式数据总线应用也非常广泛；
计算与调度层，包括：
离线计算：离线计算主要是hive，spark，也有部分选用tez
实时计算：前些年storm，spark比较流行，最近几年大家纷纷往Flink转型
数据调度：除了像Airflow Azkaban Oozie等，易观开源的Dolphin-scheduler也非常活跃
数据引擎层：也就是我们常说的OLAP层，我们看到这一层里的选择非常多，就不一一列举了，（业务需求带动技术进步的典型，选择丰富主要是可以适配不同的数据应用场景）。从概念上讲分为ROLAP、MOLAP以及两者混搭。MOLAP提前做一些预计算，以生成Cube的方式，达到空间换取查询效率；而ROLAP是即查即用，效率完全取决于查询引擎的性能，我个人认为从将来看，ROLAP的趋势会更加明显，因为没有中间的数据链路。但目前看来，没有一个统一的引擎足以支撑各类数据场景（这或许是将来的机会~）；
数据可视化层：比较主流的有Metabase、Superset、Redash，也可以选择阿里、百度的一些开源控件。
在开源技术的选择里，我们看到各层里都有越来越多国内开源的工具（也充分体现了我们在大数据技术领域的进步）。除了以上列举的这些，整个Hadoop生态圈的技术选择非常多，可以结合自己的实际场景选择自己的架构，在选型层面可以参照的一些原则，比如：
是否有鲜活的成功案例，优先找自己类似业务场景；
接口的开放性，与其他组件的兼容性；
社区活跃性度&发展趋势。
互联互通社区
互联互通社区专注于IT互联网交流与学习，关注公众号：互联互通社区，每日获取最新报告并附带专题内容辅助学习。方案打造与宣讲、架构设计与执行、技术攻坚与培训、数据中台等技术咨询与服务合作请+微信：hulianhutongshequ