readme

1d6964e2 · 张鹏 · 936d4877 · 1d6964e2
--- a/readme.md
+++ b/readme.md
-千家研中心数据中台设计概要
\ No newline at end of file
+[toc]
+
+# 千家研发中心数据中台设计概要
+
+## 1. 建设背景
+
+为快速说明企业业务，千家研发中心自成立以来，一直在以微服务的形式持续迭代业务项目。并在一年的时间内采集了大量的业务数据。虽然在一定时间内支撑了企业的运营，但也带来了如下挑战：
+
+### 1.1 数据规格不一致
+
+由于各产品线在研发初期缺乏统一规划，各业务项目之间的数据规格不一致且缺乏有效的管理方法，落地的数据分散在各个业务数据库中且规格不一致，为后续的统计分析工作造成相当大的困扰。
+
+### 1.2 新业务研发效率降低
+
+由于业务数据保存在各业务系统数据库中，没有将公共数据以及处理这些公数据的能力进行沉淀，也造成了团队在数据服务能力方面的欠缺。无法为新业务的研发提供简洁、快速、有效的支撑。新开展的业务需要频繁和已有业务进行对接以获取所需数据，这在很大程上限制了研发效率的提升，随着业务系统越来越多的上线，需要对接的接口也越来越多，研发效率将会越来越低。
+
+因此，为了保障研发效率，以及数据分析工作的顺利开展，千家研发中心将本着服务业务的主旨，围绕业务，展开企业中台建设。
+
+## 2. 调研方案
+
+中台建设并不是一个纯技术方面的概念。
+
+### 2.1 现状
+
+如下图所示，团队建设初期，为了快速说明业务，各业务系统数据库相互独立。虽然快速上线了很多项目，但数据拓扑结构繁杂，耦合严重。
+
+这也是当前很多团队在建设初期遇到的问题。
+
+![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>方面并不乐观的事实，团队需要做出架构上的适应性调整，以同时满足上述两个方面的需求。
+
+![image](https://git.allhome.com.cn/debuglife/DataDevCenter/raw/master/pics/%E6%95%B0%E6%8D%AE%E4%B8%AD%E5%8F%B0%E6%99%AF%E8%A7%82.jpg)
+
+上述蓝图所描述的场景，即是当今大数据时代获得广泛应用的Kappa数据架构。兼容离线和实时两种数据处理方式。
+
+tips：
+>数据从底层的数据源开始，经过各种各样的格式进入大数据平台，在大数据平台中经过Kafka、Flume等数据组件进行收集，然后分成两条线进行计算。一条线是进入流式计算平台（例如 Storm、Flink或者Spark
+Streaming），去计算实时的一些指标；另一条线进入批量数据处理离线计算平台（例如Mapreduce、Hive，Spark SQL），去计算T+1的相关业务指标，这些指标需要隔日才能看见。
+
+前面提到，各业务系统缺乏统一规划，数据规格不统一，需要在产品线设计层面花费更多精力，但这显然与怀抱急切需求的用户期望不符，对于初创团队来说，也几乎不可能具备完备的架构设计对系统元数据加以管控。
+
+Kappa数据架构的核心在于实时计算和批处理过程使用同一套代码，这对微服务架构
+主导的研发平台来说，可谓是天作之和。我们完全可以采用平台工作流机制来避免各业务系统间的，各业务方法之间的强耦合。从而为`使用同一套代码`提供可能 。降低对业务系统的侵入性。
+
+而针对数据规格不统一的问题，则可以采旁处理器的方式，单独开发项目管理系统，代码生成器方式进行规避。
+
+这种架构模式并非银弹，对于大数据量的实时数据来说，可能在窗口期来不及完成所有数据的处理，然而作为一种过渡架构，避免在架构设计变革的过程中对现有开发工作造成过大侵入，也不失为一种妥协的办法。
+
+### 2.4 组织机构
+
+中台首先是企业组织机构的变革，广义来说，对服务型企业来说，企业要对市场变化做出快速反应，就必须要具备快速调整能力，而具备这些能力的，服务于一线员工的所有部门均可称为中台。
+
+狭义的说，中台建设首先应成立中台研发部门，主要职责将是沉淀业务数据的公共能力，并研发数据接口，为前端业务系统提供支持。
+
+### 2.3 数据流和聚合分析
+
+结合企业现状，最终选择了 <font color="blue">`MySql + Kafka + Apache Druid`</font> 模式来快速支撑上层用户的决策分析需求。
+
+![image](https://git.allhome.com.cn/debuglife/DataDevCenter/raw/master/pics/%E4%B8%AD%E5%8F%B0%E6%8A%80%E6%9C%AF%E8%B7%AF%E7%BA%BF.jpg)
+
+Apache Druid 特点：
+- 列式存储
+    >可以将列作为索引，为仅查看几列的查询提供了巨大的速度提升
+- 高可用，高并发
+- 集群扩展、缩小、删除、宕机都不会停止服务，全天候运行
+- HA、Sql的并行化执行，可扩展、容灾等
+- 支持1000+的并发用户，并提供隔离机制支持多租户模式
+- 低延迟
+    >Druid采用了列式存储、倒排索引、位图索引等关键技术，能够在亚秒级别内完成海量数据的过滤、聚合以及多维分析等操作
+- 存储的同时聚合,采集数据的同时做好Sum,Count等操作
+    >无论是实时数据消费还是批量数据处理，Druid在基于DataSource结构存储数据时即可选择对任意的指标列进行聚合操作
+
+## 3. 设计概要
+
+<font color="red">采用统一计算过程，处理离线和实时数据。</font>
+
+中台从来都不是一个单一的技术概念。所有的中台都是业务中台，而业务中台，更是离不开技术和数据的支撑，因此有了下面的公式：
+
+**业务中台=技术中台+数据中台+公共业务**
+
+通过沉淀数据的公用能力，抽象公共业务能力到中台，使得快速支撑前台业务研发成为可能。
+
+![image](https://git.allhome.com.cn/debuglife/DataDevCenter/raw/master/pics/%E4%B8%AD%E5%8F%B0%E5%BB%BA%E8%AE%BE%E6%A6%82%E8%A6%81-%E5%B1%82%E6%AC%A1%E5%9B%BE.jpg)
+
+
+### 3.1 平台工作流
+### 3.2 前台系统
+### 3.3 业务中台
+### 3.4 数据中台
+### 3.5 技术中台