还差最后的技术选型和执行计划

readme.md

@@ -238,18 +238,15 @@ Apache Druid 特点：
 
 接下来将从架构能力方面说明中台的架构实施过程。先来看一张图：
 
+![image](./pics/中台架构能力说明.jpg)
 
+### 4.1 大数据保障体系
 
+大数据保障体系主要从两个角度来说：
+- 数仓建模规范体系
+- ~~保障数仓系统正常运行的运维和研发体系~~(离开技术什么都做不了，这里不赘述)
 
-
-
-
-小中台：少SQL，无事务， 规避以往 ETL 模式的弊端
-数据后台： rest api方式提供稳定，细粒度的数据接口
-
-<font color="red">这里需要补充一套完整的中台建设全景图， 包括Apache Druid之后的存储持久化， ES等的联合利用</font>
-
-## 5. 数仓建模规范体系
+#### 4.1.1 数仓建模规范体系
 
 数仓建模，所指不仅是指数据从一端到另一端的操作过程，更应遵循一套完整的规范体系。以期解决数据流转过程中的痛点：
 
@@ -275,7 +272,10 @@ Apache Druid 特点：
 
 >正如康威定律的核心思想：”组织形式等同系统设计“。作为架构设计者，我们不希望存在复杂而需求易变的系统，因此我们选择接收这种易变性，寄希望于降低系统建设的复杂度。阿里提出的大中台和小前台，虽然是个不错的选择，但更应注意的是，组织是需要管理的，管理就意味着额外的成本。
 
-## 6. 数据项目研发流程
+### 4.2 数据项目研发流程
+
+数据项目研发流程涵盖[整体架构设计](#4-%e6%95%b4%e4%bd%93%e6%9e%b6%e6%9e%84%e8%ae%be%e8%ae%a1)中的各个方面。
+
 
 数据模型的研发，和普通业务系统的研发大体雷同但又稍有区别。
 
@@ -283,7 +283,13 @@ Apache Druid 特点：
 
 因此，需**将数据研发部门和业务研发部门的协作方式迭代到原有研发流程规范中**，以确保实施过程顺利展开。
 
-## 7. 命令查询分离模式
+确定业务需求和流程后，数据研发部门需要确定数据粒度和维度，最终确定事实表（统指ODS,DWD,DWS,ADS等模型层次）。事实表的设计方案主要从应用需求、产出性能、存储成本、数据质量等几个角度考虑。
+
+### 4.3 统一计算过程
+
+**我们还应充分考虑统一计算过程的应用对平台架构的影响。**
+
+#### 4.3.1 命令查询分离模式
 
 根据[设计概要](#3-%e8%ae%be%e8%ae%a1%e6%a6%82%e8%a6%81)中有关架构的描述，将原有的业务数据库作为数据后台，将分析数据作为数据中台，势必会对原有的研发模式产生影响。
 
@@ -299,12 +305,54 @@ Apache Druid 特点：
 
 > 更多信息，参考：[浅谈命令查询职责分离(CQRS)模式](https://cloud.tencent.com/developer/article/1091868)
 
-## 8. 实时与离线ETL平台
+#### 4.3.2 实时与离线，流批一体化计算
+
+统一计算过程的另一个重要的影响就是实时与离线计算以及流批一体化计算过程。
+
+在某些情况下，统一计算过程很可能只是一个美好的理想。随着业务的展开和数据需求的丰富，在有限的资源和时间成本的考量下，降低研发成本快速交付成果始终是软件工程化的主要目标。大数据架构下统一计算过程的应用为工程目标带来了新的挑战。好在我们的平台架构是基于微服务思想搭建的，将“统一计算过程”沉淀为服务是一个看上去不错的解决方案。
+
+## 5. 技术选型
+
+目前我司的OLAP工作主要面临以下问题：
+
+- 直接基于MySql/Mongodb架构，查询效率低下
+- 业务间计算口径不一致，数据复用率低，开发周期长，维护成本高
+- 缺乏统一的维表和事实表，同主题下数据统计口径不一致
+- 新增业务需要投入较大的成本才能获得基础的OLAP能力
+
+经分析，我司现阶段用户的基础需求主要包括以下两点：
+
+- 报表能力
+- 初级阶段只需支持以“天”为维度的预计算
+
+前台业务研发的基础需求：
+
+- 降低研发人员学习和接入成本
+- 提供OLAP查询接口，支持各种即席分析
+
+为满足用户和各业务线的实际需求，参照小米和美团的大数据建设方案，制定了简化版本的OLAP方案，见[整体架构设计](#4-%e6%95%b4%e4%bd%93%e6%9e%b6%e6%9e%84%e8%ae%be%e8%ae%a1)。
+
+该方案中，[Apache Kylin](http://kylin.apache.org/cn/) 是 On [Apache Druid](https://druid.apache.org/docs/latest/design/index.html) 的，之所以做出这个选择，主要出于：
+
+- 维护HBase的成本高
+- HBase作为Kylin的存储方案时，Kylin无法被需要的下游服务直接读取数据
+
+新生代的 [Apache Druid](http://druid.io/docs/0.10.0/design/index.html) 有如下特性值得我们注意：
+
+- 列式存储，能够实现查询的投影下推，避免访问不需要的数据
+- 对维度字段建立倒排索引，从而支持快速过滤
+- 针对OLAP场景设计
+- 文档多，社区活跃
+- ETL方案成熟
+
+此外，数仓建设也遵循业界通用的分层治理原则，将治理过程划分如下层次：
+
+- ODS 操作数据层
+- DWD 明细数据层
+- DWS 汇总层
+- ADS 应用数据层
 
-<font color="red">继续进行技术方面的调研以丰富文档内容</font>
+>注：特定业务场景下，明细数据层和汇总数据层可并行计算处理
 
-## 9. 流批一体化计算
 
-## 11. 技术选型
 
-或许中台架构也不是银弹，但我们时刻准备好迎接新的挑战。