“1+1+N”技术架构方案

集团数据中台

5.满足整个集团无独立中台成员公司BI报表驾驶舱取数&看数&用数需求

3.利用CK或者SR存储引擎的聚合模型、主键模型、明细模型等底层能力快速响应大屏Ad Hoc需求

数据源

2.浙商资产公司与集团公司数据中台之间数据同步

展示端

1.前端大屏应用与数据中台进行解耦合，确保大屏展示稳定性

使用ClickHouse或者StarRocks作为底层存储

1.基于浙商资产业务构建金融领域独立数据中台

集团中台

4.考虑集团实时+离线场景技术架构扩展

2.各个业务系统数据在集团数据中台以租户&资源组进行隔离

集团共享中台

无独立中台子公司...

2.前端大屏&驾驶舱&业务系统展示提升查询响应速度

浙金信托数据源

集团共享中台责任

2.信托公司与集团数据中台之间数据同步

2.作为成员公司与集团数据中台备库

1.作为无独立中台成员公司数据中台(以租户&资源组方式进行隔离)

资源负载问题解答：由于数据中台的底层架构都是分布式架构，天然支持弹性扩缩容操作，当集群资源负载上来时，我们可以通过增加计算节点的方式解决此问题，增加节点后会将集群运行的计算任务进行负载均衡均匀的调度至空闲节点。资源隔离问题解答：平台底层调度使用的是Yarn框架进行资源的调度，可以通过yarn的资源调度器做到计算资源的隔离(CPU + 内存)capacity调度器，公平调度器、FIFO调度器存储隔离问题解答：平台底层使用的是HDFS框架进行存储资源的管理，可以通过HDFS的任务隔离问题的解答：可以通过平台租户的方式进行任务资源的隔离计算量不大，计算资源充足的情况下，计算任务不多的情况下，分层调度，每一层能够控制在30分钟左右，2~3小时之间就能计算完成并在报表展示生产数据的链路会造成影响数据查询响应问题解答：CK或者SR等OLAP存储引擎能够做到前端响应毫秒级~秒级需要评估业务时效性要求是否合理，比如说我之前做电池安全的场景，由于电池老化经常会发生着火事件，所以在这种场景下必须要求做到毫秒级~秒级响应时效性问题解答：方案1：lambda架构，离线 + 实时，采用这套架构会带来以下问题：1.人力资源成本会特别高，因为离线架构采用的是 HIVE + Spark + CK 这套架构，实时架构采用的是kafka + flink + ck这套架构，这会带来开发人员需要实现两套代码2.两套代码的运行需要更多的存储+计算+网络IO的资源消耗3.数据一致性很难得到保证，经常会出现当天数据和历史数据不一致的情况方案2：中台直接对接业务系统在ODS层进行指标的计算，然后通过数据服务提供API接口供帆软调用，能够保证分钟级别的伪实时。灾备问题解答：平台底层都是分布式架构，均有容错机制，包括单节点多节点故障都能够稳定运行，基本上都能够保障集群不出故障，服务器发生故障的概率特别低。硬件部署时尽量异地部署以防整个机房断电。业务连续性解答：1.数据服务直接对接业务系统以提供API的形式供帆软进行调用能够快速响应报表或者驾驶舱中台可以提供数据服务API，业务连续性是通过业务系统之间的对接进行保证

3.满足集团共享中台抽数需求，服务无独立中台成员公司

1.汇集各个业务系统数据库数据

1.基于信托业务构建信托公司独立数据中台

浙商资产

BI展示库

浙商资产中台责任

...数据源

浙金信托

浙金信托中台责任

应用

浙商资产数据源

4.统管整个集团所有数据，规整整个集团数据体系建设

统建系统数据源

成员中台

外部系统数据源