整体架构设计-数据服务

4a47b3b1 · 张鹏 · ff977499 · 4a47b3b1 · ff977499 · 4a47b3b1
--- a/pics/大数据研发中的部门协作.jpg
+++ b/pics/大数据研发中的部门协作.jpg
--- a/pics/数据流程.jpg
+++ b/pics/数据流程.jpg
--- a/readme.md
+++ b/readme.md
@@ -38,7 +38,7 @@
 ![image](https://git.allhome.com.cn/debuglife/DataDevCenter/raw/master/pics/%E4%BB%A5%E6%97%A5%E6%8A%A5%E4%B8%BA%E4%BE%8B%E7%9A%84%E7%8E%B0%E6%9C%89%E9%A1%B9%E7%9B%AE%E7%A0%94%E5%8F%91%E6%B5%81%E7%A8%8B.jpg)


-### 2.2 蓝图
+### 2.2 愿景

 出于平台应用架构在面向<font color="red">数据分析需求</font>和<font color ="red">研发效率提升</font>方面“力有不逮”的事实，团队需要做出架构上的适应性调整，以同时满足上述两个方面的需求。

@@ -142,10 +142,13 @@ Kappa数据架构的核心在于实时计算和批处理过程使用同一套代
 对于工作流的核心理解，主要在于三个方面：

 - 管理产品线流程
+  
  >在用户侧，以高度灵活的方式定义业务流程
 - 解除接口耦合
+  
  >从架构设计的角度对系统进行解耦，解除接口依赖
 - 灵活控制数据流向
+  
  >数据的流向和接口间调用关系可在工作流中进行定义，不再需要由前台业务端硬编码，也无需使用ETL工具到各个业务中抽取数据

 下图演示了不依赖工作流的业务系统，业务流转过程中接口间的调用完全依赖硬编码。
@@ -190,45 +193,42 @@ Kappa数据架构的核心在于实时计算和批处理过程使用同一套代

 接下来将从架构能力方面说明中台的架构实施过程。先来看一张图：

-![image](./pics/中台架构能力说明.jpg)
-
+<span id="jiagoutu">![中台架构能力说明](./pics/中台架构能力说明.jpg)</span>
 上图比较详细的规划了中台架构的层次和构件：
- 大数据保障体系
-  >数仓建设过程中需要完备的体系说明和操作规范
- 前台业务
-  >大前端企业数据收集应用，如各类业务系统。
- 数据仓库
-  - 数据模型
-    >面向业务需求的数据说明，以明细和汇总的形式存储
-  - 数据计算
-    >统一计算过程能够保障不同业务系统数据的一致性，降低研发成本
-  - 数据服务
-    >基于数据模型和统一计算过程得到的面向数据应用的统一数据服务接口层
- 数据应用
-  >面向数据分析的前台应用，该类应用的用户群体通常为企业决策层。
+
+| 分层一         | 分层二   | 说明                                                         |
+| -------------- | -------- | ------------------------------------------------------------ |
+| 大数据保障体系 |          | 数仓建设过程中需要完备的体系说明和操作规范                   |
+| 前台业务       |          | 大前端企业数据收集应用，如各类业务系统                       |
+| 数据仓库       | 数据模型 | 面向业务需求的数据说明，以明细和汇总的形式存储               |
+|                | 数据计算 | 统一计算过程能够保障不同业务系统数据的一致性，降低研发成本   |
+|                | 数据服务 | 基于数据模型和统一计算过程得到的面向数据应用的统一数据服务接口层 |
+| 数据应用       |          | 面向数据分析的前台应用，该类应用的用户群体通常为企业决策层   |

 ### 4.1 大数据保障体系

-大数据保障体系主要从两个角度来说：
+大数据保障体系主要从两个方面来说：
 - 保障数仓系统正常运行的运维和研发体系
 - 数仓建模规范体系

 #### 4.1.1 数仓系统运维和研发体系

-大数据研发体系是一套依赖业务研发，又独立于业务研发的生态体系。无论是对团队自身，还是对提供数据的业务研发团队，要求都更高。相较于业务研发团队，大数据研发团队对自身的要求，主要围绕业务流程和数据规范来展开。多数情况下，出于对数据规格的要求，还会对业务研发团队提出一系列的有关数据规格和业务流程方面的需求。
-
-大数据体系建设是一个相对复杂的系统工程，涉及到数据集成，数据开发，数据质量管理，数据服务，数据管理，数据运维，数据安全等多个方面的工作。这些模块相互依存、环环相扣，同时对研发人员的技术要求也水涨船高，需要服务端工程师、大数据平台工程师、BI工程师、分析师、各种方向的算法工程师、前端工程师等来参与整个系统的建设。
+大数据研发体系是一套依赖业务研发，但又独立于业务研发的生态体系。无论是对团队自身，还是对提供数据的业务研发团队，要求都更高。相较于业务研发团队，大数据研发团队对自身的要求，主要围绕业务流程和数据规范来展开。多数情况下，出于对数据规格的要求，还会对业务研发团队提出一系列的有关数据规格和业务流程方面的需求。

-具体的数据流程如下图所示：
+从研发的视角来看，`数仓系统运维和研发体系`如下图所示：

 ![大数据研发视角下的数据流程](./pics/数据流程.jpg)

+由上图可见，大数据体系建设是一项复杂的系统工程，涉及到数据集成，数据开发，数据质量管理，数据服务，数据管理，数据运维，数据安全等多个方面的工作。这些模块相互依存、环环相扣，同时对研发人员的技术要求也水涨船高，需要服务端工程师、大数据平台工程师、BI工程师、分析师、各种方向的算法工程师、前端工程师等来参与整个系统的建设。
+
+正是由于大数据体系建设工程的复杂性，先期制定针对数据研发工作的操作流程和规范就显得尤为重要，并在后续的工作中不断迭代完善，

 #### 4.1.2 数仓建模规范体系

-数仓建模，所指不仅是指数据从一端到另一端的操作过程，更应遵循一套完整的规范体系。以期解决数据流转过程中的痛点：
+数仓建模，所指不仅是指数据从一端到另一端的操作过程，更应在操作数据前制定严格的数据指标规范，数据研发团队成员严格遵循，以期解决数据流转过程中的痛点：

 - 缺乏一套统一的研发体系来管理整个数据的研发过程
+  
  >各种工具的堆积使用复杂繁乱，时间长了，数据的来源和去向谁都搞不清楚
 - 不同数据操作人员对指标的理解不一致，导致计算口径有误
 - 大数据组件开发要求高，普通业务去直接使用Hbase、ES等技术组件会产生如**数据孤岛**等各种问题
@@ -238,43 +238,92 @@ Kappa数据架构的核心在于实时计算和批处理过程使用同一套代
 正是由于上述**痛点**的存在，我司建设数据中台首先应：

 - 成立数据研发部门，物理隔离业务开发人员和大数据操作环境
+  
  >避免各个研发团队直接使用HBase,ES等技术组件，从源头上避免数据孤岛的产生
+  
 - 建立数据研发团队管理制度
-  >工作有计划和日志，遇到问题能找到日志和对应的负责人
+  
+  >工作有计划、有步骤，记录日志，遇到问题能及时追踪操作
+  
 - 建立数据操作规范，维护统一计算口径
+
+  > 针对特定业务领域的字段规格和精度甚至命名保持统一，尽可能避免二义性
+
 - 登记[统一计算过程](#34-%e7%bb%9f%e4%b8%80%e8%ae%a1%e7%ae%97%e8%bf%87%e7%a8%8b)，复用数据计算过程

+  > 数据计算后最头痛的问题，就是数据对不上
+
 **数据治理**是保障数据开发工作有序进行的基础，目前有许多优秀的开源数据治理工具，可以考虑针对这些开源工具进行适合我司的二次开发以接入自研的MIS平台。

 建立**数据事业部(组织机构设施)**，并辅以相应的**管理制度，操作流程和规范**，使工作可追溯。将用户的业务痛点和研发痛点扼杀在摇篮中，物理隔离前台和后台，并以技术手段衔接前台系统研发和后台元数据，真正意义上提高研发效率。

->正如康威定律的核心思想：”组织形式等同系统设计“。作为架构设计者，我们不希望存在复杂而需求易变的系统，因此我们选择接收这种易变性，寄希望于降低系统建设的复杂度。阿里提出的大中台和小前台，虽然是个不错的选择，但更应注意的是，组织是需要管理的，管理就意味着额外的成本。
+><font color="red">正如康威定律的核心思想：”组织形式等同系统设计“。</font>作为架构设计者，我们不希望存在复杂而需求易变的系统，因此我们选择接收这种易变性，寄希望于降低系统建设的复杂度。阿里提出的大中台和小前台，虽然是个不错的选择，但更应注意的是，组织是需要管理的，管理就意味着额外的成本。

+#### 4.1.3 部门协作

-### 4.2 数据项目研发流程(<font color="red">[见图4.1.1](#411-%e6%95%b0%e4%bb%93%e7%b3%bb%e7%bb%9f%e8%bf%90%e7%bb%b4%e5%92%8c%e7%a0%94%e5%8f%91%e4%bd%93%e7%b3%bb)这里和4.1.1重复了，需要重新安排文档结构</font>)
+数据项目研发流程贯穿[整体架构设计](#4-%e6%95%b4%e4%bd%93%e6%9e%b6%e6%9e%84%e8%ae%be%e8%ae%a1)中的各个方面。

-数据项目研发流程涵盖[整体架构设计](#4-%e6%95%b4%e4%bd%93%e6%9e%b6%e6%9e%84%e8%ae%be%e8%ae%a1)中的各个方面。
+数据模型来源于业务需求，类似考勤类的指标的用户需求非常明确，而有的指标在用户侧来说是实验性质的，生成指标的数据还没有开始采集，此时，中台研发部门和业务研发部门需要同时启动各自的项目，中台研发部门负责出具指标需求，业务研发部门负责具体的数据采集项目研发。这是一个跨部门协作的过程。

-
-数据模型的研发，和普通业务系统的研发大体雷同但又稍有区别。
-
-数据模型来源于业务需求，类似考勤类的指标的用户需求非常明确，而有的指标在用户侧来说是实验性质的，生成指标的数据还没有开始采集，这个时候，中台研发部门和业务研发部门可能需要同时启动各自的项目，一个负责出具指标需求，一个负责具体的数据采集项目研发。业务研发过程中，结合现有设施将数据ETL到目标设施，供数据研发部门分析。这是一个跨部门协作的过程。
+![大数据研发中的部门协作](./pics/大数据研发中的部门协作.jpg)

 因此，需**将数据研发部门和业务研发部门的协作方式迭代到原有研发流程规范中**，以确保实施过程顺利展开。

 确定业务需求和流程后，数据研发部门需要确定数据粒度和维度，最终确定事实表（统指ODS,DWD,DWS,ADS等模型层次）。事实表的设计方案主要从应用需求、产出性能、存储成本、数据质量等几个角度考虑。

-### 4.3 统一计算过程
+综上，大数据保障体系主要包括数仓系统运维和研发和建模规范两个重要的方面。兵马未动粮草先行，没有配套的管理措施和数据规范，任何组织内的工作都将是一团乱麻，更何况是大数据研发这项格外复杂的系统工程。
+
+### 4.2 数据应用层
+
+[整体架构图](#jiagoutu)中描述的**数据应用层**所展示的数据即是`大数据平台`输出的结果。用以辅助用户进行决策分析。该层应用的本质，是通过接口的方式调用中台数据，以图表的形式展示数据。
+
+目前网络上有很多开源或者商用的图形化报表工具，如Superset，davinci，Caravel等可视化工具均可归类到数据应用层的系统。
+
+构建该层应用的流程和规范，采用业务系统研发的流程和规范即可。值得一提的是，用户在构建数据应用之前可能并不明确知道自己需要的数据指标，需要在研发过程中不断调整，由此带来的负面影响则是应用后台所对应的数据中台接口的频繁变更，此时，**尤其应注意沉淀数据的公用能力，避免造成专门面向某一领域的“数据集市”，形成不可复用的数据孤岛。**
+
+### 4.3 前台业务层
+
+[整体架构图](#jiagoutu)中描述的**前台业务层**，是企业为满足业务需要而进行的数据采集、流程控制、简单报表等功能的集合。该类应用的底层通常直接为CRUD的模式操作关系型数据库。以满足事务性（OLTP）的操作需求。

-**我们还应充分考虑统一计算过程的应用对平台架构的影响。**
+目前平台MIS系统内的各类业务应用，均属于该层范围。

-#### 4.3.1 命令查询分离模式
+**这里需要强调的是，在不断推出新产品的过程中，要迭代全局唯一的”业务地图“，捋清各业务系统的数据指标，并使平台内各业务系统的数据指标在含义和规格上保持一致，为后续的数据进入数据仓库提前做好准备。**
+
+### 4.4 数据仓库层
+
+该层自下而上由数据模型、数据计算、数据服务3个部分组成。
+
+#### 4.4.1 数据模型
+
+数据模型是数据研发团队结合用户最终确定需求后，经由数据建模过程，最终生成的支持数据由业务系统抽取到数据仓库的完整的数据规格和指标定义。
+
+研发团队依据该模型，分析数据属性，将其存储在仓库的合理位置，进行计算和分析。
+
+具体数据建模过程，后面章节会详细说明。<font color="red">这里加数据建模链接</font>
+
+#### 4.4.2 数据计算
+
+数据分析过程的本质即是对采集到的数据进行计算的过程。通常分为即时计算和离线计算两种类型。不论是哪种计算形式，这里尤其需要注意的一点，是`计算过程的一致性`。
+
+##### 4.4.2.1 统一计算过程
+
+定义见[3.6 统一计算过程](#36-%e7%bb%9f%e4%b8%80%e8%ae%a1%e7%ae%97%e8%bf%87%e7%a8%8b)。
+
+如同数据的公用属性需要分析和沉淀，计算过程的公用能力同样需要研发人员的分析，对于不具备通用计算场景的方法和函数，开发人员应将其抽象提升为具备复用能力的接口。
+
+此外，应建立计算过程登记手册并配备相应的描述（如领域，系统，计算目标，计算指标，登记日期，登记人等关键字段），方便随时查阅。
+
+>统一计算过程的另一个重要的影响就是实时与离线计算以及流批一体化计算过程。
+
+>在某些情况下，统一计算过程很可能只是一个美好的理想。随着业务的展开和数据需求的丰富，在有限的资源和时间成本的考量下，降低研发成本快速交付成果始终是软件工程化的主要目标。大数据架构下统一计算过程的应用为工程目标带来了新的挑战。好在我们的平台架构是基于微服务思想搭建的，将“统一计算过程”沉淀为服务是一个看上去不错的解决方案。
+
+##### 4.4.2.2 命令查询分离模式（简称CQRS，下同）

 根据[设计概要](#3-%e8%ae%be%e8%ae%a1%e6%a6%82%e8%a6%81)中有关架构的描述，将原有的业务数据库作为数据后台，将分析数据作为数据中台，势必会对原有的研发模式产生影响。

 通常来讲，研发前台业务系统只需使用简单的CRUD（增删改查）即可满足一般的用户数据写入和简单的查询统计需求。纳入数据分析体系后，对原有研发模式的挑战在于分析数据和业务数据将分别取自不同的数据源，且不能跨库查询。

-针对这个问题，我的建议是，在原有架构的研发模式上，增加CQRS（命令查询分离）模式。并由专人封装成开发友好的SDK工具包，降低业务研发人员的学习和使用成本。
+针对这个问题，我的建议是，在原有架构的研发模式上，增加CQRS模式。并由专人封装成开发友好的SDK工具包，降低业务研发人员的学习和使用成本。

 **CQRS模式只在必要的时候使用。**

@@ -284,11 +333,11 @@ Kappa数据架构的核心在于实时计算和批处理过程使用同一套代

 > 更多信息，参考：[浅谈命令查询职责分离(CQRS)模式](https://cloud.tencent.com/developer/article/1091868)

-#### 4.3.2 实时与离线，流批一体化计算
+#### 4.4.3 数据服务
+
+数据服务层，

-统一计算过程的另一个重要的影响就是实时与离线计算以及流批一体化计算过程。

-在某些情况下，统一计算过程很可能只是一个美好的理想。随着业务的展开和数据需求的丰富，在有限的资源和时间成本的考量下，降低研发成本快速交付成果始终是软件工程化的主要目标。大数据架构下统一计算过程的应用为工程目标带来了新的挑战。好在我们的平台架构是基于微服务思想搭建的，将“统一计算过程”沉淀为服务是一个看上去不错的解决方案。

 ## 5. 技术选型

@@ -343,10 +392,13 @@ Kappa数据架构的核心在于实时计算和批处理过程使用同一套代
 ![image](./pics/数据仓库发展的三个阶段.jpg)

 - 简单报表
+  
  >系统的主要目标是解决一些日常的工作中业务人员需要的报表，以及生成一些简单的能够帮助领导进行决策所需要的汇总数据。这个阶段的大部分表现形式为数据库和前端报表工具
 - 数据集市
+  
  >主要是根据某个业务部门的需要，进行一定的数据的采集，整理，按照业务人员的需要，进行多维报表的展现，能够提供对特定业务指导的数据，并且能够提供特定的领导决策数据
 - 数据仓库
+  
  >主要是按照一定的数据模型，对整个企业的数据进行采集，整理，并且能够按照各个业务部门的需要，提供跨部门的，完全一致的业务报表数据，能够通过数据仓库生成对对业务具有指导性的数据，同时，为领导决策提供全面的数据支持


@@ -356,12 +408,16 @@ Kappa数据架构的核心在于实时计算和批处理过程使用同一套代
 数据仓库的建设和数据集市、简单报表建设的主要区别就在于数据模型的支持。

 - 进行全面的业务梳理，改进业务流程
+  
  >
 - 建立全方位的数据视角，消灭信息孤岛和数据差异
+  
  >
 - 解决业务的变动和数据仓库的灵活性
+  
  >
 - 帮助数据仓库系统本身的建设
+  
  >

 尤其是基于当前微服务架构平台中多产品线同时研发的状况下，数据模型的建设，对于建设以数据中台为中心的业务中台，有着不可或缺的决定性的意义。
@@ -458,14 +514,17 @@ MySql作为关系型数据库，主要负责事务数据的落地，确保事务

 Apache Druid 特点：
 - 列式存储
+  
    >可以将列作为索引，为仅查看几列的查询提供了巨大的速度提升
 - 高可用，高并发
 - 集群扩展、缩小、删除、宕机都不会停止服务，全天候运行
 - HA、Sql的并行化执行，可扩展、容灾等
 - 支持1000+的并发用户，并提供隔离机制支持多租户模式
 - 低延迟
+  
    >Druid采用了列式存储、倒排索引、位图索引等关键技术，能够在亚秒级别内完成海量数据的过滤、聚合以及多维分析等操作
 - 存储的同时聚合,采集数据的同时做好Sum,Count等操作
+  
    >无论是实时数据消费还是批量数据处理，Druid在基于DataSource结构存储数据时即可选择对任意的指标列进行聚合操作

 实施聚合分析的时机实际上取决于场景需求，一方面是实时性的需求，另一方面则是数据的公共能力是否需要提炼、沉淀；又或者，沉淀数据和聚合分析并返回数据是同时进行的。