Apache Spark

Flink 消息聚合处理方案 曹富强 / 张颖 Flink 中文社区 微博机器学习平台使用 Flink 实时处理用户行为日志和生成标签，并且在生成标签后写入存储系统。为了降低存储系统的 IO 负载，有批量写入的需求，同时对数据延迟也需要进行一定的控制，因此需要一种有效的消息聚合处理方案。 在本篇文章中我们将详细介绍 Flink 中对消息进行聚合处理的方案，描述不同方案中可能遇到的问题和解决方法，并进行对比。 基于 flatMap 的解决方案 这是我们能够想到最直观的解决方案，即在自定义的 flatMap 方法中对消息进行聚合，伪代码如下： 对应的作业拓扑和运行状态如下： 该方案的优点如下： 逻辑简单直观，各并发间负载均匀。 flatMap 可以和上游算子 chain 到一起，减少网络传输开销。 使用 operator state 完成 checkpoint，支持正常和改并发恢复。 与此同时，由于使用 operator state，因此所有数据都保存在 JVM 堆上，当数据量较大时有 GC/OOM 风险。 使用 Count Window 的解决方案 对于大规模 state 数据，Flink 推荐使用 RocksDB backend，并且只支持在 KeyedStream 上使用。与此同时，KeyedStream 支持通过 Count Window 来实现消息聚合，因此 Count

作者徐蓓，腾讯云容器专家工程师，10年研发经验，7年云计算领域经验。负责腾讯云 TKE 大数据云原生、离在线混部、Serverless 架构与研发。 背景 大数据发展至今，按照 Google 2003年发布的《The Google File System》第一篇论文算起，已走过17个年头。可惜的是 Google 当时并没有开源其技术，“仅仅”是发表了三篇技术论文。所以回头看，只能算是揭开了大数据时代的帷幕。随着 Hadoop 的诞生，大数据进入了高速发展的时代，大数据的红利及商业价值也不断被释放。现今大数据存储和处理需求越来越多样化，在后 Hadoop 时代，如何构建一个统一的数据湖存储，并在其上进行多种形式的数据分析，成了企业构建大数据生态的一个重要方向。怎样快速、一致、原子性地在数据湖存储上构建起 Data Pipeline，成了亟待解决的问题。并且伴随云原生时代到来，云原生天生具有的自动化部署和交付能力也正催化这一过程。本文就主要介绍如何利用 Iceberg [1] 与 Kubernetes 打造新一代云原生数据湖。 何为 Iceberg Apache Iceberg is an open table format for huge analytic datasets. Iceberg adds tables to Presto and Spark that use a

作者徐蓓，腾讯云容器专家工程师，10年研发经验，7年云计算领域经验。负责腾讯云 TKE 大数据云原生、离在线混部、Serverless 架构与研发。 背景 大数据发展至今，按照 Google 2003年发布的《The Google File System》第一篇论文算起，已走过17个年头。可惜的是 Google 当时并没有开源其技术，“仅仅”是发表了三篇技术论文。所以回头看，只能算是揭开了大数据时代的帷幕。随着 Hadoop 的诞生，大数据进入了高速发展的时代，大数据的红利及商业价值也不断被释放。现今大数据存储和处理需求越来越多样化，在后 Hadoop 时代，如何构建一个统一的数据湖存储，并在其上进行多种形式的数据分析，成了企业构建大数据生态的一个重要方向。怎样快速、一致、原子性地在数据湖存储上构建起 Data Pipeline，成了亟待解决的问题。并且伴随云原生时代到来，云原生天生具有的自动化部署和交付能力也正催化这一过程。本文就主要介绍如何利用 Iceberg [1] 与 Kubernetes 打造新一代云原生数据湖。 何为 Iceberg Apache Iceberg is an open table format for huge analytic datasets. Iceberg adds tables to Presto and Spark that use a

实践目的 通过操作一个开源例子，学习大数据的架构 及基本的使用，各种概念。不涉及自编码与创新。 环境搭建 需要建立 hadoop,hbase ,spark 等大数据环境 在10.30.2.5上建立六个docker , 分别对应 s141~s146 分别用于装大数据环境，具体操作步骤 参考本人 hadoop-spark https://blog.csdn.net/dualvencsdn/article/details/112007643?spm=1001.2014.3001.5501 habase https://blog.csdn.net/dualvencsdn/article/details/112905925?spm=1001.2014.3001.5501 学会操作hbase https://blog.csdn.net/dualvencsdn/article/details/113309385?spm=1001.2014.3001.5501 flume初步学习与使用 https://blog.csdn.net/qq_1018944104/article/details/85462011 /usr/local/flume/do.sh kafka与zookeeper的使用与编程 https://blog.csdn.net/dualvencsdn/article/details

在这个金灿灿的收获季节，经过 Apache DolphinScheduler PPMC 们的推荐和投票，Apache DolphinScheduler 收获了 5 位新Committer 。他们是：nauu(朱凯)、Rubik-W(温合民)、gabrywu、liwenhe1993、clay4444。 对于成为 Committer ，小伙伴们说道： 朱凯 ： 非常荣幸能够成为DolphinSchedule 的 Committer。这既是一份喜悦，也是一份责任。我将以终为始，继续打怪升级，助力 DS 早日毕业。 温合民 ： 很荣幸成为DS Committer团队的一员。通过技术调研了解到DS，最终选型决定引入DS，高效的社区支持使项目最终顺利落地。DS是我参与开源的第一个项目，深受益于开源，同时也想为开源做一些力所能及的贡献，希望未来能更多的为DS添砖加瓦，愿DS顺利毕业。 社区介绍： Apache DolphinScheduler 是一个非常多样化的社区，至今贡献者已近100名， 他们分别来自 30 多家不同的公司。 微信群用户3000人。 Apache DolphinScheduler 部分用户案例(排名不分先后) 已经有300多家企业和科研机构在使用DolphinScheduler，来处理各类调度和定时任务，另有 近500家 公司开通了海豚调度的试用： Apache

论文地址 spark-core 论文地址 http://nil.csail.mit.edu/6.824/2018/papers/zaharia-spark.pdf spark-sql 论文地址 https://amplab.cs.berkeley.edu/wp-content/uploads/2015/03/SparkSQLSigmod2015.pdf spark streaming 论文地址 people.csail.mit.edu/matei/papers/2013/sosp_spark_streaming.pdf 下载方法 使用wget <地址>直接下载 来源： oschina 链接： https://my.oschina.net/u/4489002/blog/4943843

前言 Presto是一款Facebook开源的MPP架构的OLAP查询引擎，可针对不同数据源执行大容量数据集的一款分布式SQL执行引擎。因为工作中接触到Presto，研究它对理解SQL Parser、常见算子的实现（如SQL中table scan,join,aggregation）、资源管理与调度、查询优化（如向量化执行、动态代码生成）、大数据下各个组件为何适用不同场景等等都有帮助。我希望通过这个系列可以了解一条SQL在大数据场景下该如何高效执行。233酱准备不定时持续更新这个系列，本文主要从Presto的使用举例，Presto的应用场景、Presto的基本概念三个部分来初步介绍Presto。 Presto的使用举例 比如说，你想对存储在不同数据源中的数据，如HDFS、Mysql、HBase等通过一个SQL做查询分析，那么只需要把每一个数据源当成是Presto的Connector，对应实现Presto SPI暴露出的Connector API就可以了。 hbase 和 es 的Join查询举例 Presto官方版 和 Presto社区版 已经支持了很多Connector，社区版略胜一筹。至于两者有何区别，吃瓜群众可以前往文末参考资料[4]。简而言之，都主要由Facebook那帮大佬核心维护。社区版更新更为频繁，但高版本需要JDK11才能支持；官方版JDK8就行

摘要： 主要介绍如何通过官方 ETL 工具 Exchange 将业务线上数据从 Neo4j 直接导入到 Nebula Graph 以及在导入过程中遇到的问题和优化方法。 本文首发于 Nebula 论坛： https://discuss.nebula-graph.com.cn/t/topic/2044 1 背景 随着业务数据量不断增长，业务对图数据库在线数据实时更新写入和查询的效率要求也不断增加。Neo4j 存在明显性能不足，Neo4j 社区开源版本只支持单机部署，扩展能力存在比较大的问题，无法满足读写性能的线性扩展以及读写分离的业务需求，并且开源版本 Neo4j 对点和边的总数据量也有限制；而 Neo4j 企业版因果集群也存在单机主节点 Cypher 实时写入的性能瓶颈。 相比于 Neo4j，Nebula Graph 最大的特色便是采用 shared-nothing 分布式的架构，无单主写入瓶颈问题，读写支持线性扩展，擅长处理千亿节点、万亿条边的超大规模数据集。 本文主要介绍如何通过官方 ETL 工具 Exchange 将业务线上数据从 Neo4j 直接导入到 Nebula Graph 以及在导入过程中遇到的问题和优化方法。其中绝大部分问题都已经通过论坛发帖的方式得到社区的支持和解决，本文会结合问题进行逐一列举。 2 部署环境 系统环境： CPU name：Intel(R)

1 什么是kafka Kafka是分布式发布-订阅消息系统，它最初是由LinkedIn公司开发的，之后成为Apache项目的一部分，Kafka是一个分布式，可划分的，冗余备份的持久性的日志服务，它主要用于处理流式数据。 2 为什么要使用 kafka，为什么要使用消息队列 缓冲和削峰： 上游数据时有突发流量，下游可能扛不住，或者下游没有足够多的机器来保证冗余，kafka在中间可以起到一个缓冲的作用，把消息暂存在kafka中，下游服务就可以按照自己的节奏进行慢慢处理。 解耦和扩展性： 项目开始的时候，并不能确定具体需求。消息队列可以作为一个接口层，解耦重要的业务流程。只需要遵守约定，针对数据编程即可获取扩展能力。 冗余： 可以采用一对多的方式，一个生产者发布消息，可以被多个订阅topic的服务消费到，供多个毫无关联的业务使用。 健壮性： 消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进行。 异步通信： 很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。 3.Kafka中的ISR、AR又代表什么？ISR的伸缩又指什么 ISR:In-Sync Replicas 副本同步队列 AR:Assigned Replicas 所有副本

开发调优 调优概述 Spark性能优化的第一步，就是要在开发Spark作业的过程中注意和应用一些性能优化的基本原则。开发调优，就是要让大家了解以下一些Spark基本开发原则，包括：RDD lineage设计、算子的合理使用、特殊操作的优化等。在开发过程中，时时刻刻都应该注意以上原则，并将这些原则根据具体的业务以及实际的应用场景，灵活地运用到自己的Spark作业中。 原则一：避免创建重复的RDD 通常来说，我们在开发一个Spark作业时，首先是基于某个数据源（比如Hive表或HDFS文件）创建一个初始的RDD；接着对这个RDD执行某个算子操作，然后得到下一个RDD；以此类推，循环往复，直到计算出最终我们需要的结果。在这个过程中，多个RDD会通过不同的算子操作（比如map、reduce等）串起来，这个“RDD串”，就是RDD lineage，也就是“RDD的血缘关系链”。 我们在开发过程中要注意：对于同一份数据，只应该创建一个RDD，不能创建多个RDD来代表同一份数据。 一些Spark初学者在刚开始开发Spark作业时，或者是有经验的工程师在开发RDD lineage极其冗长的Spark作业时，可能会忘了自己之前对于某一份数据已经创建过一个RDD了，从而导致对于同一份数据，创建了多个RDD。这就意味着，我们的Spark作业会进行多次重复计算来创建多个代表相同数据的RDD