最近一直在写关于数据中台的文章，我发现大家都很感兴趣，今天就从数据中台的建设方针来解决各位的疑惑。
横向规划即在数据中台规划初期，需要打通企业各个业务系，打破数据孤岛现象，其实就是我们建设数据仓库的阶段。
数据中台建设过程中涉及到大数据平台建设、数据仓库建设、模型算法、数据治理、数据服务等一系列工程，不可能一蹴而就，我们需要梳理业务场景，看他们需要什么样的服务先找一个业务场景，搭建起数据中台的服务能力，然后依次迭代，各个击破。
一、总体规划
数据集成
首先我们需要确认平台接入哪些数据，确认数据接入的方式是实时接入还是离线抽取。离线抽取的话是全量抽取还是增量抽取。抽取频次数每天抽取还是每小时抽取。
实时接入可以使用 kafka 实时写入数据到 HDFS 集群上。
离线数据可以使用 Sqoop 抽取关系型数据库到 HDFS。
模型建设
模型建设是数据中台的重要部分，可以说数据中台的成败在于模型建设的好坏。模型分为我们常指的数据仓库的分析模型和我们的一些通用算法模型。
分析模型
数据接入到数据仓库中，我们需要对数据进行加工，按照我们规划的业务域，对各个业务的数据汇总聚合，形成我们的数据模型。
这其中涉及到数据仓库建设，在这简单说下。
这是一个简单的数据分层结构。原始数据 ODS，经过清洗成为数仓中的明细数据 DWS 和维度数据 DIM，各个业务的明细数据按照业务域和维度数据关联形成我们的数据模型 DW，不同的 DW 经过聚合形成各个业务指标数据 APP 层。
在数仓的建设中我们声明业务粒度，粒度能够精确的表明业务含义。同时还要确定维度，是用户维度还是商品维度等，最终形成我们的主数据，也就是模型数据的基础。
算法模型
我们在业务开发过程中会形成一些通用的算法，可以是封装好的随机森林、回归等通用算法，也可以是我们业务算法，比如用户商品推荐算法等。通过把这些算法总结，形成我们的算法模型，供各个业务直接调用。
ETL 平台
在开发数据模型时，我们必须有一个统一的平台，能够像流水线一样，把数据一步步加工成数据模型。这其中涉及到数据萃取、数据聚合、作业调度等。
与业务研发不同，数据研发一般很少写详细的需求涉及文档，通常就是和业务人员简单的沟通，但是慢慢的你会发现开发完的任务会一改再改。为了避免此种现象，我们可以根据自己的实际业务整理一份需求模板。其中包括数据来源字段，数据口径，任务调度周期，字段 mapping。
数据资产
通俗的来说，我们在数仓中开发的模型就是数据资产，数据资产需要规范的管控和治理。
资产管理最基础的工作是做好元数据的管理，元数据包含了数据的口径，数据模型的释义，模型之间的血缘等等，详细的可以看之前的元数据文章《数据仓库元数据》。将元数据和数据模型统一有序的管理起来形成企业的数据资产。
数据资产治理不是在事后管控的，在我们建设模型的过程中需要形成一套自己的数仓开发规范进行管理。
数据服务
俗话说，酒香也怕巷子深。我们做好数据资产后，要推销我们的资产，为更多部门使用，这也是数据中台建设的初衷。因此提供一套数据服务能力，对外统一对接是一件很重要的工作。
数据服务标准：数据结构标准化、在线查询实时化、数据开发可视化。
数据结构标准化
针对数据交互，我们需要提供统一的接口视图，可进行数据的查询、权限管控。
在线查询实时化
针对各业务的调用，我们需要提供指标级数据口径统一的实时数据结果。
数据开发可视化
提供数据接口的可视化统一管理页面，开发人员通过通过可视化管理 API，降低接口理解的难度，易于维护。
二、数据湖引擎
其实讲到数据中台，必然绕不开整个企业的数据架构，但由于内容实在是太多，我只能挑着讲，今天就来讲讲一个比较新颖且重要的概念，数据湖引擎。
数据湖引擎介于管理数据系统、分析可视化和数据处理工具之间。数据湖引擎不是将数据从数据源移动到单个存储库，而是部署在现有数据源和数据使用者的工具 (如 BI 工具和数据科学平台) 之上。
数百万数据消费者使用的工具，如 BI 工具、数据科学平台和仪表板工具，假设所有数据都存在于一个高性能的关系数据库中，当数据在多个系统中，或者在非关系存储 (如 ADLS、Amazon S3、Hadoop 和 NoSQL 数据库) 中，这些工具的能力就会受到影响。
BI 分析工具，如 FineBI/Tableau/Python 和机器学习模型，是为数据生活在一个单一的、高性能的关系数据库中的环境而设计的。
然而，多数组织使用不同的数据格式和不同的技术在多种解决方案中管理他们的数据。多数组织现在使用一个或多个非关系型数据存储，如云存储 (如 S3、ADLS)、Hadoop 和 NoSQL 数据库 (如 Elasticsearch、Cassandra)。
当数据存储在一个独立的高性能关系数据库中时，BI 工具、数据科学系统和机器学习模型可以很好运用这部分数据。然而，就像我们上面所说的一样，数据这并不是存在一个地方。
因此，它的任务是将这些数据转移到关系环境中，创建多维数据集，并为不同的分析工具生成专用视图。数据湖引擎简化了这些挑战，允许公司将数据存放在任何地方。
三、总结
对于大型集团企业，中台方法论很实用，打破了集团各版块的数据孤岛，形成了统一的数据服务能力。
但是慢慢的很多人提出了，对于中小企业，中台方法论是不是太繁琐了，对于他们来说是负担，中小企业需要的也许是更快捷的迭代形式的数据服务。
那么关于中台建设，你怎么看呢？你的企业会选择中台吗？最后给大家介绍一个?商用级的saas 系统的开源项目，有兴趣的小伙伴可以研究研究！