大数据 SRE 体系能力建设（二）| 学习笔记-阿里云开发者社区

开发者学堂课程【大数据SRE体系能力建设：大数据 SRE 体系能力建设（二）】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/1203/detail/18170

大数据 SRE 体系能力建设

三、头部金融客户建设案例

在头部金融客户中，大部分客户会采用数据中台的大区产品的视图，在整个的数据中台体系里，会采用 dataworks 平台，采用 Max computer的离线处理， blink的实时计算， datahub 的数据总线， datav 的数据大屏， quickbi 交布式分析的能力， hologres 产品，当客户把离线和实时的任务，运行在数据中台的时候，首先客户是对于云内的大数据的任务，实时的或离线的，包括平台，水位的等等可用性的指标监控能够及时的发给客户自有的云平台，进行合理的管控，能够联动值班进行各种的处理。其实客户对于有效性和技术性的要求高，是客户在整个仲裁业务使用过程中的必不可缺的一个环节。同时，当大量离线数据来放到数仓时，数据在离线数仓里分配和使用率情况，对于已有的数据资源如何进行划分，从而保证新上线的时候有合理的分配和已有的资源的合理的调整，需要透视的项目级别的容量管理能力，对于业务方，开展数据中台的成本管控和资源的分配起到非常重要的作用。基于客户对于大数据可用性和稳定性，可提供运营巡检，流量管理提升顾问，变更的管控，业务的发布，故障应急的能力建设，整体链路的实时测试、互相保障等等内容来确保客户具备能力。使整个大数据业务稳定性能够得到提升。

大数据的任务监控对接的案例。大数据平台产品的监控，以及大数据平台业务监控。大数据技术平台的监控包括伏羲调度，盘古的存储，云网络和数据库，技术架构层面的监控基本具备。对于大数据产品是具备的，比如 ros ， maxcompute ， Flink ， data hub 。主流的大数据产品的监控能力具备，在云内都是具备的，但是都无法去自动的对接到金融客户自有的平台。对于监控可能还需要进一步增强的。对于大数据的平台的产品的监控能力，可以通过统一的采集或增强，能够推送到金融客户的基础平台。对于大数据的平台业务，分成离线计算和实时计算。离线计算主要是常用的 dataworks 平台，把失败任务，基线告警，数据告警，事件告警能够推送给业务方。对于 dataworks 的基线和数据质量实践都是平台本身提供的。可以通过界面进行使用。如果没有配置，同时目前的对接有一个兜底的功能， dataworks 里面失败的任务也可以及时的推荐给业务方。可以把 od ps 里面异常 SQL ，涉及到 TOP20 的资源开销， TOP20 运营层市场的任务能够及时发现推送。对于实时计算和延迟任务的 fail over 和任务的反压等异常情况能够推动给业务方。任务的反压本质上是任务的延迟的一种，比如计算处理能力，跟不上上游的数据的消费能力。通过整体的端到端的打通，及时的把大数据业务侧和核心的产品的容量水位，能够和客户的自有平台进行对接。

dataworks 离线任务告警能力， blink实时任务告警能力， maxcumpute 项目储备的能力， Holo GREs 实例可用性告警能力，及时的推送给金融客户的自有的平台，客户也基于告警对接，开展了有效的监控，及时的提升了整个的大数据平台的一个稳定性。

上面的流程图是统一的业务对接平台，把告警的项目名，任务名，告警时间 servert ，通过统一的业务金融平台，到达客户自有的告警系统。客户自有告警系统都可以基于发送的 projectname 做一些项目或任务名的切分。比如是产检的业务，也是授权的应用，也可能是个入户的应用，到达不同业务方，对不同的应用进行告警治理。当如果告警内容无法知道如何进行处理，可以去引入客户自有的运营团队或阿里的二线，专家团队的性能功能支持进行勘展对应的容量的治理工作和告警问题的治理工作。

大数据的项目容量管理。当数据越来越多的涌入到大数据平台的时候，客户不仅仅是关心平台的水位，还会关心每个业务项目分配的情况和使用率的情况，客户会通过人工的分析 odps 的数仓来进行数据的加工处理。比如不同的环境有逻辑的生产和逻辑测试，不同的项目下可能是一个共享资源，也可能独占资源，来进行容量的计算和存储数据的分析。去识别出来资源费用率比较高，使用率比较低的情况来做合理的划分，需要把一些资源率使用比较低的一些项目规划到一个 share 的扩大组中，避免浪费。同时对于一些需要重保的项目，可以用独占的资源来确保业务的性能得到满足，但是独占的资源就会带来性能的浪费，基于 deal horseETR 流程，同时基于 KPI 的交互式的分析能力，可以构建一套整体的开箱即用的 od pi 中的解决方案。通过客户去输入一个启动时间，起始时间和结束时间，可获取目前的整的项目颗粒度的资源，比如存储计入的开销的情况。客户可以通过 BI ， data PS ， SQL ， dataworks 半屏化的下载，就可以直接把数据导出，大大减轻了容量分析的成本。同时对于客户开展成本的分析和资源使用率提升会起到很大的帮助。

维度统计的报表里会涉及到环境分类，在 OTX 划分逻辑的生产和逻辑的测试。同时可以基于项目归属的 odps 的， quota 是一个独占的资源，还是个共享的资源进行分析。对于每个项目，其项目空间存储开销和维权数量的开销，还有任务数量开销进行统计。整个颗粒度都是可以去到项目级别查看。整体来看，统一周期可以按照天级，周级，月级，半年级维度进行统计。右边图就是通过 QBL的一个数据电子表格和数据集对维度和度量进行分析整理。同时可以在 Dataworks 整个链路完成了处理分析。 dataworks 里面 ETL 的加工处理最终生成了 quickbi 的项目的存储和计算汇总的分析的集。业务方可以通过 dataworks ， OBS 进口的查询，表格的下载， Quick BI 电子表格，仪表盘获取数据。 QBI 的仪表盘里面左边展示的关于生产和测试的资源划分。另外中间是关于每个项目分配资源的情况。在右边列表 PS 的项目使用的占比。区分出来哪些项目分配的资源比较高，包括使用率的情况等等。有效的离线数仓的容量的存储计算的治理。

holoGres的案例，是目前比较流行的产品。客户针对 fologres 所归属的每个业务的实例的 CPU memory 开销，包括整理集群的存储，涉及到盘古的容量水位也是非常关切的。但是目前只能通过Henry bores。的页面，通过人肉统计进行分析。同时也需要人工整理server 表，划分不同的业务所归属的 hologres 的实例信息等等，是非常耗时的。最终团队帮助客户通过并继承 CMS 监控的信息和大数据管家的元数据信息，就可以帮客户实现这统计，来帮助客户 cover 掉两个 hologres 集群里面数个业务实例的容量管理。右边是一个整体的 quick Bi 的视图。

从左边看到整个维度统计，包含业务实例的 CP U memory 的分配和使用率。按照周级维度进行打点。对于业务的容量存储的使用量的统计，可以做市场统计，通过基于集群存储的总量和使用量的统计来计算，发现集群级别存储资源的一个风险，同时也可以定位出10亿级别的一个 CPU memory开销的走向。对于整体的大数据管家可以整合出每个 hologres 的业务实例和集群的归属，同时还可以对应出来每个 hologres 的实力和对应的一个项目映射。因为 call Grace 是没有逻辑没有意义的 estate ID。从对应的一个项目名的信息，及时的定位到实例和归属的业务去做对应的一个业务方面的分析。整个链路就下面所述的，通过一套完整的采集，把 ABM 元数据和 CM 元数据进行汇总，通过定时任务分析处理打点，最终通过数据库提供一个数据存储。通过 Quick BI 做一个数据量分析的展示。因为通过 bi可以做进一步的下转联动。通过 Holivoice 一个基于gbi的仪表盘，能够看到每个业务实例， CEO 的平均使用率的情况，降序进行排列。同时也能看到整个集群整体使用率趋势变高，需要进行关注是否业务在大量的投产，或者有些异常的资源开销。基于整体的存储的使用率，在全量级时间，有一个波动的上涨，后面趋于稳定。右面是关于整个分配的情况，所整理的链路都可以通过大盘来进行分析，做合理的 Hologres 业务实例级别的统计。

Flink 是目前最流行的实时计算的框架平台，基于 Flink 产品， Flink 在 316 版本包括 314 版本之后，当 K8 进行部署，就意味着 Flink 里面服务好，比的一些 job 的计划都是部署在 K8S powder 里面的。怎么去实时的有效的把 K8S powder 分任务的资源的开销及时统计，同时能够联动一些原始信息，及时的把 flink 内部 space的队列项目空间，对应以前的 Blink 项目队列情况进行统计分析。客户会提到记忆查询的需求，因为需要对于已有的资源进行划分，同时需要对新业务上线进行容量的分配的评估。通过调用 K8S 接口来实现 Flink 内部 space 项目级别分配，比如最大和使用保障信息的统计，包含分配，申请，资源保障最大化等等。同时也通过采集任务的开销做整体的 namespeak级别的资源开销的 Max 和 AVG 统计，最终通过 quick BI的方式，帮助客户能够及时的开展 Flink 项目区的流量统计。

整体的维度信息可以通过主编来看到。比如队列中 namespace的名称，状态， owner 归属者，甚至包含保障和最大资源。保障资源大概理解成队列里面可以申请的最小资源保障。每个队列里面申请的是ucpu ，在flink去里面 ecu 就等于1G， 1G 等于一盒 10 内存。可以统计项目里面的 CPU memory 的周级维度的平均使用量的情况。基于信息，就可以构建电子表格进行分析。同时可以构建仪表盘，比如基于 Flink 每一个实例， CEO 的 CPU 的开销和申请的情况进行分析。有效地帮助客户把 Flink namespace 队列级别的容量的分析管理，可以有些数据支撑。 odps 容量治理的案例。有一个银行客户的整个 odps 的存储水位已经达到了85%。 odps 的存储达到 90% 是会有进血的风险。同时odpi的计算也存在一些高峰期竞争的问题，因为没有划分独立的 quota 。基于不同业务，也是一个大的 share 的quota ，客户需要既能规避竞争，同时又能够不影响动当前的金融率的使用。不建议通过一些独立资源划分来导致的资源使用率下降。共享的扩大肯定是资源使用率更高的，独占的扩大使用率会更低一些，但稳定性会好一些。首先对于业务的 odps 的业务进行梳理。客户是有一个 odpsedw 基础数据平台和基础数仓层。另外还有统一数据应用和服务平台，包括审计和积分平台，这都是在于基础数仓之上的一个应用平台。

基于整个容量分析，第一个阶段，存储分析，整个的离线的数仓里面到底是否存在同名表，有的客户在建设数据仓库的时候，不同业务可能在消费同样的数据，也就意味着数仓里面在 OTI 这一层可能是有冗余数据的。在一个合理的划分里面，应该是所有的业务会共享数据，共享一套数仓的元层数据进行后面的处理加工。如果存在的透明表，意味着存在着重复建设的，对于 oti 的存储空间是一种浪费。第二阶段，对于 odps 所有表的生命周期，分析识别出有些生命周期没有设置生命周期，如果生命周期设置的不合理或不设置，会带来一些存储的开销。通过对于客户的一年以内的odps 的任务的 cu 开销和任务数的分析，可以看到整体的任务数在上升， odps 的cu 开销也在上升，所以整体的竞争趋势是在加大。可以解释最近的整体的计算竞争在加大。但是视图是不足以进行分析的，还需要下钻到quota 某一天的不同项目的里面任务的开销，任务数的占比。需要对接数据进行分析之后，为后面做切分需要支撑。比如项目占用整体资源的 70%，切分的时候就可以使用 70% ，留一些 buffer 方式进行切分。

调度也是重要的。首先蓝色的线是0点到7点左右的离线任务的均开销和 c 开销，黄色的线上是整体的天级别的开销。整体的离线任务在 0- 7点的开销是很低的，在全天的占比里面比重非常低，也在 20% 左右，非常不合理。整个离线的数仓的任务都是在凌晨 0-7点进行完成的，对整个入仓，后面的下游的拉齐，一般的离线报表都要在 10 点或 11点半之前要产出，此时数据就非常不合。所以引起关注。通过整个的任务调度数据分析，会发现9点的时候有一个提交任务的数量高峰，再往后就不断的下降。在 0到7点的时候，整体的任务提交数量其实也是比较低的。经过客户明确，其供述其实是在早上 9点完成的，就导致下游是在 9点之后同时被拉齐，也导致了竞争的加剧。

因此建议客户可以把整个调度，尤其是数据入湖的调度，能够迁移到凌晨来规避，能够把白天的营造器资源充分的利用，同时可以把任务的错峰打散，来规避后面的资源竞争，来减缓问题。最终基于整体的分析，分发了客户重组治理，计算治理和任务治理三个维度的分析报告。首先第一个是分析 odps 的无数据无生命周期的表，占据了大概 3.7 PB ，比例非常高，占用整个平台 80% 左右。需要建议客户对于定义 dwd ，把日程包括 edi 不同层进行合理的一个生命周期的设置。没有主进展可以设置不同的一个生命周期可进行设置。同时发现有 16461个同名表需要治理。也建议客户尽量能够消费。odpsedw 项目的数据，来规避风险。对于计算治理来讲，建议客户能够把整个业务提交到 9点－13 点、 14 点、18 点来规避业务高峰期的问题。同时可以通过 odps 的 co 的划分，来提升整个平台的资源划分，保证重要任务不受商务经验的影响。同时对于任务治理，也识别客户其实有大量的群表扫描的浪费，也存在着 max 阶段等小文情况，可以通过一些参数的设置来进行优化。另外在整个的任务交易阶段，建议通过 MAP JM 对效率进行缓存，通过小表校验大表的方式来校验大表的方式来进行性能提升。

通过数据中台的环境账号划分，来确保整个中台的账号权限体系和环境是符合安全监管需求的，所以需要设置几个测试，一个 UAT 预发环境和生产环境，通过环境隔离租户带来的账号的环境，包括资源的环境的隔离，去划分整体的整理数据集市， Delaware 产品，培训产品，可以通过 odps 的白名单，可以通过 DOS 的调度资源组的划分，来确保一级调度和数据集成资源的开销，确保整个的资源是不能够跨环境进行访问的。

实际可以通过整体的全链路的新测试，基于 Bilink消费、data hub和 hologres 进行业务，做特点的业务大屏的场景。可以通过整体的链路，把整个梯度的测试，通过不同的数据量的写入不同的 data hub 下载分片数量，包括 Bilink 资源， Audigrace的资源，提取全链路的压测，做测摸天花板的梯度测试。同时可以通过长达 6 小时到8小时的持续稳定测试，按照稳定性的指标，最终 QPS RPS 是远远超过客户需求的，确保整个链路是能够满足业务需求或发布之后不会有问题。

实施全链路性能测试优化的案例，当时的客户针对于怎么整个全入整个链路上，因为耗比较长，通过全入打点，包括一些性能优化和客户问题的排查，最终定位问题，确保了反欺诈场景是符合预期的。主要的问题在于客户的测试数据重复。数据重复会带来一些算子的膨胀，可以通过一些优化，比如打开 partition final ，通过 Mini basis 的打开去规避 stick 访问来增加冲突等。