网站架构分析工具,一定火网站建设定制,推广竞价托管费用,管理咨询公司起名字很多同学问我为什么要发这些大数据前沿汇报#xff1f;
一方面是自己学习完后觉得非常好#xff0c;然后总结发出来方便大家阅读#xff1b;另外一方面#xff0c;看这些汇报对你的面试帮助会很大#xff0c;特别是面试前可以看看即将面试公司在大数据前沿的发展动向
一方面是自己学习完后觉得非常好然后总结发出来方便大家阅读另外一方面看这些汇报对你的面试帮助会很大特别是面试前可以看看即将面试公司在大数据前沿的发展动向我曾经就有过一次经历面试网易云音乐前我在B站看了一个大佬分享的网易云实时数仓刚好在面试的时候就碰见他了最后反问就主动跟他说我看过他的汇报然后还提出了自己的一些思考面试官当场就给我通过了
蔚来汽车
以下内容来自蔚来汽车Flink架构师的分享
用户背景
蔚来是一家全球化的智能电动汽车公司于2014年11月成立。蔚来致力于通过提供高性能的智能电动汽车与 极致用户体验为用户创造愉悦的生活方式。 平台建设
实时计算在蔚来汽车的发展主要经历了如下几个阶段
2018年5月份蔚来汽车开始接触实时计算并采用Spark Streaming做一些简单的流式计算数据的处理2019年9月份蔚来汽车引入了 Flink通过命令行的方式进行提交包括管理整个作业的生命周期2021年1月份蔚来汽车上线了实时计算平台 1.0并开始进行 2.0 版本的开发。 蔚来汽车实时计算平台 1.0 的生命周期如上图。任务写完之后打成 jar 包进行上传提交后续的开启任务、停止、恢复和监控都能够自动进行。作业管理主要负责作业的创建、运行、停止、恢复和更新。日志主要记录 Flink 任务提交时的一些日志如果是运行时的日志还是要通过 Yarn 集群里的 log 来查看稍微有点麻烦。关于监控和告警模块首先 metrics监控主要是利用Flink内置的指标上传到 Prometheus然后配置各种监控的界面告警也 是利用Prometheus 的一些指标进行规则的设置然后进行告警的设置。Yarn 负责整体集群资源的管理。
上图是实时计算平台 2.0。相对于 1.0最大的区别是蓝色的部分。对于实时计算平台的形态可能并没有一 个统一的标准它与每个公司本身的情况息息相关比如公司本身的体量和规模、公司对实时计算平台的资 源投入等最终还是应该以适用于公司本身的现状为最佳标准。2.0 版本主要增加从开发到测试两个阶段功能 的支持具体包括
FlinkSQL它是很多公司的实时计算平台都支持的功能它的优点在于可以降低使用成本也比较简单易用空间管理不同的部门和不同的组可以在自己的空间里进行作业的创建、管理。有了空间的概念之后可以利用它做一些权限的控制比如只能在自己有权限的空间里进行一些操作UDF 管理使用了 FlinkSQL 的前提下就可以基于 SQL 的语义用 UDF 的方式扩充功能。此外UDF 还能用于 Java 和 Schema 任务可以把一些公用的功能包装成 UDF降低开发成本。它还有一个很重要的功能就是调试可以简化原有的调试流程做到用户无感知。 实时计算平台 2.0 的核心目标是减轻数据团队的负担。只要把实时计算平台做得足够完善、易用和简单数 据中台团队就可以使用 FlinkSQL 完成数据的同步和处理理想的情况下他们甚至不需要知道 Flink 的相关概 念就可以完成这些工作并且不需要依赖数据团队大大降低沟通成本进度会更快。这样在部门内可以形 成闭环产品经理的工作也会变得更轻松在需求的阶段不需要引入太多的团队效率也会大大提升。
业务场景
1.实时看板 上图是实时看板业务的架构图主要分为三层。第一层是数据层即 Kafka 的实时数仓通过 Flink 对这些数据进行处理后将它们实时地推到后台后台再实时地把它们推到前端。后台与前端的交互是通过 web socket 来实现的这样就可以做到所有的数据都是实时推送。
2.CDP CDP 是一个运营平台负责偏后台的工作。蔚来汽车的 CDP 需要存储一些数据比如属性的数据存在 ES 里、行为的明细数据包括统计数据存在 Doris 里、任务执行情况存在 TiDB。其中主要有两个实时场景的应用第一个是属性需要实时更新否则可能造成运营效果不佳第二个是行为的聚合数据有时候也需要实时更新。
3.实时数仓 上图是蔚来汽车目前的实时数仓架构图。它整体上与离线数仓非常相似也是有ODS层、DWD 层、DWS 层和Application 层。不同之处在于它有一个维度层 (DIM 层)里面有很多不同的存储介质维度信息可以放在TiDB并通过 AIO 的方式访问维度表也可以放在 Hive用 Temporal Join 的方式去进行关联有一些数据是一直在变化的或者需要做一些基于时间的关联可以把数据放到 Kafka 里然后用 Broadcast 或者Temporal Join 去进行关联。
未来规划
实时数据的场景越来越多大家对实时数据的需求也越来越多未来蔚来汽车会继续进行实时数据方面的探索。目前在流批一体的实时和离线存储统一上已经有了一些产出后续也会在这方面投入更多精力包括 Flink CDC 是否真的可以减少链路提高响应效率等。
汽车之家
以下内容来自汽车之家Flink架构师的分享
用户背景
汽车之家成立于2005年致力于为消费者提供一站式的看车、买车、用车服务提供优质的汽车消费和汽车生活服务。助力中国汽车产业蓬勃发展。在历经媒体化、平台化、智能化的转型后全方位服务C端消费者和B1端主机厂、B2端汽车生态各类参与方全面融入平安车生态战略打造车辆交易的完整闭环。
平台现状
汽车之家实时计算平台的应用场景与其他公司很类似涵盖了实时指标统计、监控预警、实时数据处理、实时用户行为、实时入湖、实时数据传输这几个方面 随着业务不断庞大现有平台升级的需求不断扩大。 首先由于实时计算离线的存储资源是混用的离线 Hadoop 集群单独为实时计算拆出了一部分服务器并单 独部署了一套 Yarn 供实时计算使用这部分服务器的磁盘用来支持离线数据的存储CPU 内存主要用来支持运行 Flink 任务所以 Flink 计算资源并没有独占服务器汽车之家也没有对计算资源作严格的管控所以导致有很多任务分配的资源是不合理的通常是申请了过多的 CPU 资源但实际的利用率却比较低。随着公司容器化建设的逐步推进离线和在线混部并错峰分配资源的方式成为可能这也就意味着 Hadoop 集群的 CPU内存除了支持 Flink 实时计算也可以支持在线业务的部署从而使得对 Flink 计算资源管控的重要性及紧迫程度凸显出来。 其次推动用户做资源的调优。这部分工作对用户来说存在一定难度。首先要理解 CPU 内存和并行度的调整对任务的影响就是有成本的而且通常修改任务资源、重启任务就需要几分钟此外用户还需要持续观察是否对业务产生了影响比如出现延迟或内存溢出等。简单来说用户的调优成本是比较高的。 接下来现有的基于 Hive 的数仓架构需要升级。t1 或 h1 的时效性已经无法满足很多业务场景的需求。 最后早期实时计算平台支持的生态不够完善。汽车之家的人工智能团队主要以 Python 语言为主基于 SQLUDF 的方式显然对他们不够友好。
平台建设 1.预算资源管控和Flink自动伸缩容
为了提高资源利用率汽车之家做的第一步就是启用预算的强控机制与内部的资产云系统做对接并确定团队的可用预算超出预算后任务将无法启动。同时对此定义了规范用户需要先优化团队内的低利用率任务来释放预算原则上资源利用率低的任务数应该控制在 10% 以内。如果无法优化可以在资产云系统上发起团队间预算调拨的流程也就是借资源如果还是失败则会由平台开白名单临时支持业务。 平台还上线了Flink任务健康评分机制针对 CPU 使用率、内存使用率和空闲 slot 这几个核心规则来识别低利用率任务同时会展示出低利用率的原因及解决方案。 此外汽车之家通过开发Flink作业自动伸缩容功能来降低用户的调优成本。用户可以指定自动伸缩容的触发时间比如可以指定在夜里低峰时期执行降低伸缩容对业务的影响支持指定 CPU 并行度、内存维度伸缩容的策略每次执行伸缩容都会通过钉钉和邮件通知任务负责人并且会记录伸缩容的触发原因和伸缩容之后的最新资源配置。 总结起来汽车之家通过引入强控流程来严控计算资源的用量通过制定规范来提升用户主动优化资源的意 识通过开发自动伸缩容功能降低用户的调优成本。最终达到的收益是在实时计算业务稳步增长的前提下全 年没有新增服务器。
2.建设湖仓一体 基于 Hive 的数据仓库主要存在以下几个痛点
首先是时效性目前基于 Hive 的数仓绝大部分是 t1数据产生后至少要一个小时才能在数仓中查询到。随着公司整体技术能力的提升很多场景对数据的时效性要求越来越高比如需要准实时的样本数据来支持模型训练需要准实时的多维分析来帮助排查点击率下降的根因其次是Hive 2.0 无法支持 upsert 需求业务库数据入仓只能 t1 全量同步数据修正成本很高同时不支持 upsert 意味着存储层面无法实现批流一体最后Hive的Schema属于写入型一旦数据写入之后 Schema 就难以变更。 经过一番选型汽车之家决定选择基于 Iceberg 来构建湖仓一体架构如下图所示 最底层是基于 Hive Metastore 来统一 Hive 表和 Iceberg 表的元数据基于 HDFS 来统一 Hive 表和Iceberg 表的存储这也是湖仓一体的基础。往上一层是表格式即 Iceberg 对自身的定位介于存储引擎和计算引擎之间的开放的表格式。再往上是计算引擎目前 Flink 主要负责数据的实时入湖工作 Spark 和 Hive 作为主要的产品引擎。最上面是计算平台 Autostream 支持点击流和日志类的数据实时入湖AutoDTS 支持关系型数据库中的数据实时入湖离线平台与Iceberg 做了集成支持像使用 Hive 表一样来使用 Iceberg在提升数据时效性的同时尽量避免增加额外的使用成本。 通过FlinkIceburgHive实现湖仓一体架构流量、内容、线索主题的数据时效性得到了大幅提升从之前的 天级/小时级提升到 10 分钟以内数仓核心任务的 SLA 提前两个小时完成同时特征工程得以提效在不改 变原先架构的情况下模型训练的实效性从天级/小时级提升到 10 分钟级从业务视角来看大幅提升了数 据分析的效率体验和机器学习推荐的实效。
3.PyFlink实践
引入 PyFlink主要是想把 Flink 强大的实时计算能力输出给人工智能团队。人工智能团队由于技术本身的特点 大部分开发人员都是基于 Python 语言开发而 Python 本身的分布式和多线程支持比较弱他们需要一个能快速上手又具备分布式计算能力的框架来简化他们日常的程序开发和维护。通过集成 PyFlink 汽车之家实现了对 Python 生态的基础支持解决了 Python 用户难以开发实时任务的痛点。同时也可以方便地将之前部署的单机程序迁移到实时计算平台上享受 Flink 强大的分布式计算能力。
未来规划 未来汽车之家会持续优化计算资源让计算资源的利用更加合理化进一步降低成本。一方面充分利用自动伸缩容的功能扩展伸缩容策略实现实时离线计算资源的混部利用实时离线错峰计算的优势进一步降低实时计算的服务器成本。同时团队也会尝试优化 Yarn 的细粒度资源调度比如分配给 jobmanager 和taskmanager 少于一核的资源做更精细化的优化。在流批一体方面汽车之家准备利用 Flink 的批处理能力小范围做批处理的应用和 web 场景的试水。同时在数据湖架构的基础上继续探索存储层面批流一体的可能性。最近汽车之家也在关注 FLIP-188 提案它提出了一个全新的思路将流表和批处理表进行一定程度的统一可以实现一次 insert 就把数据同时写入到Logstore 和 Filestore 中让下游可以实时消费 Logstore 的数据做实时 Pipeline也可以使用 Filestore 的批式数据做 ad_hoc 查询。后续团队希望也能做类似的尝试。
