我的大数据之路 - 基于HANA构建实时方案的历程

2024-02-12 11:20

本文主要是介绍我的大数据之路 - 基于HANA构建实时方案的历程,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

产品内部前期有一个共识,依据业务要求的时效性来选择技术平台,即:

  • 实时类业务,时效性小于2小时,则使用HANA构建。
  • 离线类业务,时效性大于2小时,则使用大数据平台构建。

经过五月、六月两月的努力,离线类的业务已基本完成开发和验证完毕,后面待在生产环境对数完毕后,即可启动切换。
因此实时类业务的方案分析和梳理,成为当下最重要、最紧急的事情。
考虑到项目当前的痛点:

  • 直接从I层构建业务,没有复用主题层的模型和资产。
  • 缺少数据管家参与项目,帮助把关业务方案。
  • 前期欠缺资料,很多需求没有积累方案素材。
  • 项目开发团队大部分为新人,对业务的了解基本来自于代码,个别业务的理解由我或者项目PM传递,但考虑到我和项目PM的业务背景,效果非常一般。

因此在盘点完现有方案后,我基于如下原则,构建业务的实时方案:

  • 在HANA平台,完全复用主题层模型的数据架构和取数逻辑,仅裁剪掉业务不需要使用的字段和表。这样,当主题模型发生变更时,实时方案可直接同步。
  • 优先使用HANA的视图来承载业务。
  • 假如取数逻辑比较复杂,使用视图无法实现,则考虑使用HANA的存储过程。
  • 经验证,假如个别视图的性能无法达标,则考虑落增量实时表。

按照上述思路,技术方案会比较简单,基础表的清单和Mapping,可以直接复用各领域主题前期输出的材料。而下游使用的业务数据表,可以请各领域的SE协助输出Mapping和表的关联逻辑,项目组直接对数即可。
结果在技术评审会上,这个方案一经抛出,即被评审专家各种痛批。
我很无语。
。。。
领导安排首席SE投入项目,计划使用一个月,将实时业务交付上线。
不得不说,首席SE很有经验,做事很有章法:

  • 盘点现有业务。输出模板,要求我和项目PM在一周内完成梳理。当时由于某业务非常复杂,不得已还安排一个开发同事参与。
  • 整理技术方案和痛点。将整理过程中遇到的问题,梳理为技术类问题的清单和方案类问题的清单,分别找人确认。
  • 开工会、晨会、业务培训。
    • 开工会。明确项目目标和要求,和开发组成员交流,了解大家的情况和想法、个人诉求。
    • 晨会。将前期的电话会议,调整为现场会议,提高沟通效率,便于掌握交付进展。
    • 业务培训。晨会上常规的项目管理类内容完成后,即开始讲解业务,让开发同事快速入门。
  • 细化方案。输出Mapping,明确依赖的表清单和取数规则。
  • 周边协调。
    • 和产品内部、产品周边协调、确认问题。
    • 协调开发和验证、生产环境。

经过两周的努力后:

  • 环境,包括开发和生产已协调到位。
  • 前期整理的问题,已有初步结论。
  • 技术方案的细节基本明确。
  • 下游业务初步认可技术方案。

后续的重点工作,将从方案分析转变为交付工作。

后记1

在整理方案过程中,发现首席SE输出的方案其实和我输出的方案有某种相似性,比如:

  • 业务场景,都使用主题定义的场景。
  • 数据架构,都参照主题定义的模型。
  • 基础视图、表、存储过程的代码,基本上照搬模型表的实现代码。

但存在明显的差异点,首席SE在梳理方案时:

  • 按需出发。
    • 要求下游业务明确关键的字段和数据,进而裁剪了部分未使用到的字段。
    • 梳理实现不合理的方案细节,要求下游业务变更方案。
    • 不容易理解的方案细节,要求下游给出解释。假如下游业务团队说不清楚,则直接搁置相关特性,转需求跟踪。
  • 从经验出发。
    • 简化主题模型的取数实现,降低实现难度。
    • 依据经验,提前明确以HANA表实现的基础表的清单。
    • 依据经验,提前明确使用存储过程来实现的基础特性的清单。
    • 提前准备集成数据的方案。
    • 相关人力、环境等资源,提前协调到位。

另外一点,首席SE带队来设计方案:

  • 自身对业务非常了解,可以有效提高方案的输出效率,减少返工。
  • 评审方案的沟通成本下降很多。因为首席SE自己输出的方案,对细节很清楚,遇到评审专家的挑战,可以快速响应。
  • 和下游业务团队的沟通成本,同样下降很多。

不得不承认,功夫在诗外。假如由我来主导实时方案的实施,在上述差异点上,会花费大量的精力,可能存在较多的返工,对进度而言无疑是非常大的风险。

后记2

近期过的并不太平,几件事情挤在一起,让本来明朗的项目周边形势,又紧张起来。

  • 第一件事,将现有业务迁移至HANA的方案,在评审会上被周边专家痛批了一通,意味着方案要重新做,重新评审。
  • 第二件事,基础维表的数据出现了错误,导致X业务的数据出现了大面积缺失,影响到了下游一片业务。其实这事情放平时,把数据修复好,然后和下游业务团队说说好话,事情就过去了。结果大BOSS正好在客户那边交流,于是这件事情被当成典型,BOSS从客户那边带回来,作为重点任务关注。
  • 第三件事,下游Y业务要放开推广,正在验证数据,发现某些设备的数据缺失现象比较突出。恰好近期Y业务自身的问题比较多,压力比较大,于是借本事件小小发挥一下,转嫁部分压力出来。于是这件事情被当成典型,BOSS要求马上处理。

这三件事情恰好发生在同一天,产品经理对于我和项目组的表现非常不满,非常不放心,于是连夜安排首席SE到项目组异地支持一个月,将业务迅速切换至HANA平台,一次性解决项目当前遇到的问题。
平心而论,我没有使用HANA做过项目,所以将业务迁移至HANA的方案,做的相对比较粗,不是首席SE想要看到的可以体现细节的技术方案;此外缺少业务背景,有很多细节说不清楚。考虑到我欠缺做数据仓库类项目的实战经验,因此领导不放心是正常的,可以理解。但也加重了我的工作量,评审方案时,从材料到讲解,均存在被炮火覆盖的可能。
首席SE空降项目组之后,快速进入角色,拉着我和项目PM以及个别项目组开发同事,一起梳理现有方案。
此时生产环境连续出现意外:

  • 周日早晨,我在例行检查跑批任务的状态时,意外发现某些任务运行失败,联系同事检查后,发现跑批任务出现了大量失败的现象。相关情况上报产品经理,领导决策兵分两路,由首席SE带队定位、解决问题,其余的人则分头修复数据。我的周末就这样报销了。
  • 接下来的周一的早晨,我收拾电脑出门前,随手检查了一下任务跑批情况,发现平时在6点前可以跑完的任务,居然发生了严重的延迟。考虑到近期正好是月结、半年结,数据类的问题要求及时上报,于是赶紧汇报领导。结果和周日一样的分工,首席SE带队定位、处理问题,其余的人则分头修复数据。周一上午就这么过去了。

接连发生意外事件,再加上项目组接手的业务的实现方案确实很复杂,在和项目组一起参加了几次周边的沟通会议后,首席SE后来私下里表示,终于体现到项目组的不易了。

这篇关于我的大数据之路 - 基于HANA构建实时方案的历程的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/702491

相关文章

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

无人叉车3d激光slam多房间建图定位异常处理方案-墙体画线地图切分方案

墙体画线地图切分方案 针对问题:墙体两侧特征混淆误匹配,导致建图和定位偏差,表现为过门跳变、外月台走歪等 ·解决思路:预期的根治方案IGICP需要较长时间完成上线,先使用切分地图的工程化方案,即墙体两侧切分为不同地图,在某一侧只使用该侧地图进行定位 方案思路 切分原理:切分地图基于关键帧位置,而非点云。 理论基础:光照是直线的,一帧点云必定只能照射到墙的一侧,无法同时照到两侧实践考虑:关

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

高效+灵活,万博智云全球发布AWS无代理跨云容灾方案!

摘要 近日,万博智云推出了基于AWS的无代理跨云容灾解决方案,并与拉丁美洲,中东,亚洲的合作伙伴面向全球开展了联合发布。这一方案以AWS应用环境为基础,将HyperBDR平台的高效、灵活和成本效益优势与无代理功能相结合,为全球企业带来实现了更便捷、经济的数据保护。 一、全球联合发布 9月2日,万博智云CEO Michael Wong在线上平台发布AWS无代理跨云容灾解决方案的阐述视频,介绍了

嵌入式QT开发:构建高效智能的嵌入式系统

摘要: 本文深入探讨了嵌入式 QT 相关的各个方面。从 QT 框架的基础架构和核心概念出发,详细阐述了其在嵌入式环境中的优势与特点。文中分析了嵌入式 QT 的开发环境搭建过程,包括交叉编译工具链的配置等关键步骤。进一步探讨了嵌入式 QT 的界面设计与开发,涵盖了从基本控件的使用到复杂界面布局的构建。同时也深入研究了信号与槽机制在嵌入式系统中的应用,以及嵌入式 QT 与硬件设备的交互,包括输入输出设

【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯,先赞后看哦~🎈🎈 🏆 作者简介:景天科技苑 🏆《头衔》:大厂架构师,华为云开发者社区专家博主,阿里云开发者社区专家博主,CSDN全栈领域优质创作者,掘金优秀博主,51CTO博客专家等。 🏆《博客》:Python全栈,前后端开发,小程序开发,人工智能,js逆向,App逆向,网络系统安全,数据分析,Django,fastapi