结构上还需要整理

cbb93df6 · 张鹏 · fb9feb61 · cbb93df6
--- a/readme.md
+++ b/readme.md
@@ -30,6 +30,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 蓝图

 出于平台应用架构在面向<font color="red">数据分析需求</font>和<font color ="red">研发效率提升</font>方面并不乐观的事实，团队需要做出架构上的适应性调整，以同时满足上述两个方面的需求。
@@ -95,7 +96,7 @@ Apache Druid 特点：

 通过分析、沉淀数据的公用属性，抽象公共业务能力到中台，使得快速支撑前台业务研发成为可能。

-![image](https://git.allhome.com.cn/debuglife/DataDevCenter/raw/54ba965b7729983fd58a24ba747c8e89fb0ec784/pics/20190107-%E4%B8%AD%E5%8F%B0%E6%9E%B6%E6%9E%84%E5%B1%82%E6%AC%A1.jpg)
+![image](https://git.allhome.com.cn/debuglife/DataDevCenter/raw/master/pics/20190107-%E4%B8%AD%E5%8F%B0%E6%9E%B6%E6%9E%84%E5%B1%82%E6%AC%A1.jpg)

 ### 3.1 平台工作流

@@ -123,7 +124,7 @@ Apache Druid 特点：

 **除定义业务流程外，流程中各节点产生的数据，也可以在工作流定义时配置并进行信息发布和消费，从而降低数据提取过程中对业务系统的侵入。**

-### <span id=32>3.2 前台</span>
+### 3.2 前台

 前台系统直接面向用户，以往的开发模式中，开发阶段无中台能力可用，前台业务开发人员不得不自行解决从大前端到大后端的所有问题，如聚合分析运算，依赖方接口的硬编码引入等。这样一来，每当需求发生变更，开发人员不得不去项目中修改代码甚至修改流程。开发成本居高不下。

@@ -137,7 +138,7 @@ Apache Druid 特点：

 ### 3.3 公共业务接口（业务中台）

-业务中台的公用能力沉淀问题，如 [3.2 前台](#32)提到的例子，应收应付业务因其具备公用能力并提供业务服务，可将该能力提炼到**业务中台**，我称之为**统一计算过程**。之后，再充分利用**工作流系统**的节点编排能力，将“应收应付”这个“统一计算过程”能力编排到需要的业务系统中，实现真正意义上的**业务中台**。
+业务中台的公用能力沉淀问题，如 [3.2 前台](#32-%e5%89%8d%e5%8f%b0)提到的例子，应收应付业务因其具备公用能力并提供业务服务，可将该能力提炼到**业务中台**，我称之为**统一计算过程**。之后，再充分利用**工作流系统**的节点编排能力，将“应收应付”这个“统一计算过程”能力编排到需要的业务系统中，实现真正意义上的**业务中台**。

 >继续延伸，该应收应付中台服务，可在不侵入前台业务的情况下将数据进一步下沉至数据分析数据库，实施进一步的分析聚合，直接为上层用户提供决策分析依据。

@@ -183,21 +184,23 @@ Apache Druid 特点：

 维护数据中台过程中，一个需要设计师时刻保持警觉的问题是：数据公用能力的提炼太过随意，将业务个性化的数据随意提炼到中台，最后发展成专门面向某一领域或项目特有的“数据集市”，随着业务的变化和扩张，该集市体量越来越大，服务范围却越来越”专一“，最终不得不进行分拆或重建以适应新的领域需求。

-因此，**数据公用能力的提炼不能仅依靠架构师的个人能力，需要制定明确边界的操作规范，避免上述情况的发生。**
+因此，**数据公用能力的提炼不能仅依靠架构师的个人能力，需要制定边界明确的操作规范，避免上述情况的发生。**

 #### 3.5.3 降低或压缩SQL的使用影响和范围

-业务中台的数据直接落地到数据后台，与数据后台基于 API 进行同步阻塞（确保事务性）或异步非阻塞(非事务性)通讯，目的是为了解耦具体技术产品和数据模型。基于后台服务返回结果集完成各类SQL等效操作，**降低或者压缩SQL的使用影响和范围。**
+根据以往的经验，面向特定领域或项目的“数据集市”，通常会有自我闭环的趋势，力图减少对其他系统的依赖，逐步积累数据后必然进一步扩充功能。通过SQL批量集成数据的方式为基于集市的业务系统膨胀提供的土壤。
+
+前台系统的数据直接落地到数据后台，中台与数据后台基于 API 进行同步阻塞（确保事务性）或异步非阻塞(非事务性)通讯，目的是为了解耦具体技术产品和数据模型。基于后台服务返回结果集完成各类SQL等效操作，**降低或者压缩SQL的使用影响和范围**，使前台不容易积累数据以独自完成业务需求，避免为“数据集市”的滋生提供土壤和养分，

 >SQL是一种领域特定语言（DSL），虽然**很强大但并不是很好的工程语言**。由于它不能在内存中定义和操作复杂的数据结构，如果要做模块化的逻辑封装，模块的输入输出必须是数据库表，这就带来了 I/O 损耗，大量的模块化，必然带来导致 I/O 性能的显著下降。而这些模块存在的方式只是脚本，缺少治理工具，大量零散的模块如何管理也是一个难题。系统实施者必须在模块化和性能间权衡，性能是显性的，直接影响用户体验且有明确的度量指标；模块化是隐形的，而且缺少度量工具。因此实际工程中，很少真正做到逻辑的模块化，数据库表的层次不规范，甚至出现数千行 SQL 语句从源表加工数据直接写入结果表。由于缺少治理工具，规范难以执行，久而久之大家也就默认了这样的事实。

 >**大范围使用SQL的代价是可测试性极差**，每次逻辑的变化都要通过对代码的修改来实现而并不是新增逻辑。试想一段上千行、逻辑纵横交错的 SQL 语句，要在其中修改某个单点逻辑，没有高覆盖率的单元测试用例，如何确保正确性，最终只能依靠细心和运气，代码质量必定是脆弱的，不能称为真正的工程化项目，治理和敏捷都无从谈起。

-因此，**降低或者压缩SQL的使用影响和范围**成为建设中台数据设施的必选项。
+因此，**降低或者压缩SQL的使用影响和范围，用API代替SQL**成为建设中台数据设施的必选项。

 #### 3.5.4 降低数据存储冗余

-数据中台应“降低数据存储冗余”。前面提到，数据由前台系统直接落地到数据后台进行保存，中台数据由后台数据反哺而来。中台只保留用户、机构等维度数据，用于提升处理效率。
+数据中台应“降低数据存储冗余”。前面提到，数据由前台系统直接落地到数据后台，中台数据由后台数据反哺而来。中台只保留用户、机构等维度数据，用于提升处理效率。

 水平方向上来说，系统间数据冗余是业务逻辑重复开发的土壤；垂直方向来说，数据中台和后台之间的数据冗余，同样是数据孤岛的成因，因此，需要在顶层架构设计中尽量规避。

@@ -205,56 +208,88 @@ Apache Druid 特点：

 ### 3.6 数据后台

-数据后台直接存储来自前台系统的业务数据，提供 API 供上层系统使用。
-
+数据后台以直接暴露数据连接方式为前台和中台系统服务。与中台数据不同，可以将后台数据看作是企业未经任何加工的元数据。各个数据采集系统将采集到的数据存放在后台，在反哺到中台的过程中加工成用户想要的各维度数据。

+>出于性能考虑，我们可以建设配套缓存设施，以提高数据服务效率。其所处层次，很可能覆盖后台和中台，属于基础技术设施，不在这里多说。

 ### 3.6 离线数据计算中心

---
+对于实时要求不高的分析需求来说，离线数据计算已被证明是一种有效节约计算成本的方法。但无论是实时、准实时或是定时计算，均应使用同样的计算过程。见 [3.4 统一计算过程](#34-%e7%bb%9f%e4%b8%80%e8%ae%a1%e7%ae%97%e8%bf%87%e7%a8%8b)

-<font color="red"> 阐述技术在数据中台和后台的作用</font>
+---

-技术中台服务于其他中台，包括：
+建设数据中后台的过程中，中台技术部门除建设和维护基础设施外，还应关注业务领域的用户需求，从水平方向上提炼系统功能，垂直层面上构建抽象层次，以建设更具扩展性和维护性的中台应用层，为用户节约研发成本，提高研发效率。

- 服务于数据的数据技术中台，如聚合分析和计算能力等
- 提炼自业务的公用计算能力
- 服务于研发自身的组件库，标准库，以及各公用服务及各自的SDK开发包等
+在数据流转的各个环节设置相应的规范，约定各类操作，以保障“大中台，小前台”架构的持续性，并作为质控部门审查的依据。

-技术中台的终极目标只有一个关键词：效率。将提高研发速度和质量作为第一要务，在企业中起着不可或缺的重要作用。是一个研发平台的基石。
+**无论是当下正在讨论的中台架构，还是以往传统的大数据架构，其目标都是为了服务于用户的决策效率、研发效率。**

 ## 4. 整体架构设计

-前面阐述了中台相关的关键概念，总结下来，中台的概念主要体现在两个方面：
+前面章节解释了[设计概要](#3-%e8%ae%be%e8%ae%a1%e6%a6%82%e8%a6%81)的架构示意图中各个组件的含义和边界。总结下来，中台的概念主要体现在两个方面：

- 源于对业务场景的抽象、提炼、沉淀的“共享服务能力”
- 前中后三层体系架构，在前台和后台之间插入中台架构，以实现更平缓的过渡，兼顾整个架构的灵活与稳定
- 
+- 对业务场景的抽象、提炼、沉淀的**共享服务能力**
+- 前中后三层体系架构，在前台和后台之间插入中台架构，以实现更平缓的过渡。**平衡前台业务系统和后台服务的灵活与稳定**

+接下来将从架构能力方面说明中台的架构实施过程。

+小中台：少SQL，无事务， 规避以往 ETL 模式的弊端
+数据后台： rest api方式提供稳定，细粒度的数据接口

-接下来将从架构能力方面说明中台的架构实施过程。
+<font color="red">这里需要补充一套完整的中台建设全景图， 包括Apache Druid之后的存储持久化， ES等的联合利用</font>

+## 5. 数仓建模规范体系

+数仓建模，所指不仅是指数据从一端到另一端的操作过程，更应遵循一套完整的规范体系。以期解决数据流转过程中的痛点：

+- 缺乏一套统一的研发体系来管理整个数据的研发过程
+  >各种工具的堆积使用复杂繁乱，时间长了，数据的来源和去向谁都搞不清楚
+- 不同数据操作人员对指标的理解不一致，导致计算口径有误
+- 大数据组件开发要求高，普通业务去直接使用Hbase、ES等技术组件会产生如**数据孤岛**等各种问题
+- 数据的批计算和流计算使用不同的计算模型，难以保持一致且研发成本高，应使用[统一计算过程](#34-%e7%bb%9f%e4%b8%80%e8%ae%a1%e7%ae%97%e8%bf%87%e7%a8%8b)
+- 缺乏平台级别的统一规划，同一条数据实时和离线难以复用计算，每次开发任务都要重新梳理

-小中台：少SQL，无事务， 规避以往 ETL 模式的弊端
-数据后台： rest api方式提供稳定，细粒度的数据接口
+正是由于上述**痛点**的存在，我司建设数据中台首先应：

+- 成立数据研发部门，物理隔离业务开发人员和大数据操作环境
+  >避免各个研发团队直接使用HBase,ES等技术组件，从源头上避免数据孤岛的产生
+- 建立数据研发团队管理制度
+  >工作有日志，遇到问题能找到日志和对应的负责人
+- 建立数据操作规范，维护统一计算口径
+- 登记[统一计算过程](#34-%e7%bb%9f%e4%b8%80%e8%ae%a1%e7%ae%97%e8%bf%87%e7%a8%8b)，复用数据计算过程

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

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

-这里需要补充一套完整的中台建设全景图， 包括Apache Druid之后的存储持久化， ES等的联合利用
+## 6. 数据项目研发流程

+数据模型的研发，和普通业务系统的研发大体雷同但又稍有区别。

-## 5. 数仓建模规范体系
+数据模型来源于业务需求，类似考勤类的指标的用户需求非常明确，而有的指标在用户侧来说是实验性质的，生成指标的数据还没有开始采集，这个时候，中台研发部门和业务研发部门可能需要同时启动各自的项目，一个负责出具指标需求，一个负责具体的数据采集项目研发。业务研发过程中，结合现有设施将数据ETL到目标设施，供数据研发部门分析。这是一个跨部门协作的过程。
+
+因此，需**将数据研发部门和业务研发部门的协作方式迭代到原有研发流程规范中**，以确保实施过程顺利展开。
+
+## 7. 命令查询分离模式
+
+根据[设计概要](#3-%e8%ae%be%e8%ae%a1%e6%a6%82%e8%a6%81)中有关架构的描述，将原有的业务数据库作为数据后台，将分析数据作为数据中台，势必会对原有的研发模式产生影响。

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

-## 7. 数据开发方式
+针对这个问题，我的建议是，在原有架构的研发模式上，增加CQRS（命令查询分离）模式。并由专人封装成开发友好的SDK工具包，降低业务研发人员的学习和使用成本。
+
+**CQRS模式没必要到处使用，只在必要的时候使用。**
+
+>CQRS最早来自于Betrand Meyer（Eiffel语言之父，开-闭原则OCP提出者）在 Object-Oriented Software Construction 这本书中提到的一种 命令查询分离(Command Query Separation,CQS) 的概念。其基本思想在于，任何一个对象的方法可以分为两大类：
+>- 命令(Command):不返回任何结果(void)，但会改变对象的状态。
+>- 查询(Query):返回结果，但是不会改变对象的状态，对系统没有副作用
+
+> 更多信息，参考：[浅谈命令查询职责分离(CQRS)模式](https://cloud.tencent.com/developer/article/1091868)

 ## 8. 实时与离线ETL平台

+
+
 ## 9. 流批一体化计算

 ## 10. 元数据-大数据体系基石