暂无个人介绍
之前已经写过一篇文章,StreamingPro 支持Spark Structured Streaming,不过当时只是玩票性质的,因为对Spark 2.0+ 版本其实也只是尝试性质的,重点还是放在了spark 1.6 系列的。
有的时候我们只要按条处理,追求实时性而非吞吐量的时候,类似Storm的模式就比较好了。Spark 在流式处理一直缺乏改进,而Flink在流式方面做得很棒,两者高层的API也是互相借鉴,容易形成统一的感官,所以决定让StreamingPro适配Flink,让其作为StreamingPro底层的流式引擎。
我们知道StreamingPro 是一个完全SQL/Script化的,基于Spark平台的一套生产力工具。但是不可避免的,我们可能希望直接操作SqlContext或者使用原生的DataFrame API。 这里我们通过script 让大家支持这个功能.
一个开源产品,用户才是自己的最关键的。用户只关注了一个新的版本有什么新的功能,解决了老的什么痛点,并且提高了多少稳定性和速度,如此而已。至于内核的重构,API的统一,这不能成为自己全身心去投入的事情。
如何在命令行中指定StreamingPro的写入路径?如何命令行指定输如输出的参数?本文就给出了详细的操作步骤。
之前因为仅仅是把HBase当成一个可横向扩展并且具有持久化能力的KV数据库,所以只用在了指标存储上,参看很早之前的一篇文章基于HBase做Storm 实时计算指标存储。这次将HBase用在了用户行为存储上,因为Rowkey的过滤功能也很不错,可以很方便的把按人或者内容的维度过滤出所有的行为。
前些天可以让批处理的配置变得更优雅StreamingPro 支持多输入,多输出配置,现在流式计算也支持相同的配置方式了。另外未来等另外一个项目稳定,会释放出来配合StreamingPro使用,它可以让你很方便的读写HBase,比如可以为HBase 表 添加mapping,类似ES的做法,也可以不用mapping,系统会自动为你创建列(familly:column作为列名),或者将所有列合并成一个字段让你做处理。
最近正好有个需求,就是从不同的数据库以及表里拉出数据,经过一定的处理放到ES里供查询,最好还能放个到parquet里,这样可以支持更复杂的SQL。之前StreamingPro是只能配置一个数据源的,所以做了些改造,方便配置多个数据源,以及多个写出。
CarbonData已经发布了1.0版本,变更还是很快的,这个版本已经移除了kettle了,使得部署和使用 变得很简单,而且支持1.6+ ,2.0+等多个Spark版本。StreamingPro可以使得你很简单通过一个命令就能体验Carbondata,并且支持Http/JDBC的访问形态。
很多事物本身是有好有坏的,我们只要挑出里面好的,然后充分为我所用即可。“物尽其用”大体就是这个意思。
其实Job,Stage,Task都是Spark Core里就有的概念,Batch则是Streaming特有的概念。同一Stage里的Task一般都是并行的。同一Job里的Stage可以并行,但是一般如果有依赖则是串行,可以参考我这篇文章Spark 多个Stage执行是串行执行的么?。
一个神经网络就和人类的大脑一样,一开始它什么都不是,没办法解决任何任务,为了能够让它具体完成一些任务,成为某个领域的专家,我们也要像对待学生一样,不断的灌输数据,以及我们要达到的目标,那么神经网络内部就会自动学习,完成内部数量庞大的参数选择,最后神奇的将自己变成了一个可以执行特定任务的机器了。
所谓产品观,其实也就是全局观的一个具体实施策略,只是这种实施策略执行在某一个产品的生命周期里。前面我们提到,一件事情最重要的部分其实是找到如何衡量做的好不好的标准,产品观给我们找到了这个衡量标准,就是我们做的一切,都是以最后对产品是不是好的,而不是我做的这件事情本身好不好。
这半个月除了工作上的事,一直忙于学习机器学习基础理论,每天背着四五本书上下班,还蛮有读书时的感觉。之前写了一篇文章,叫基于用户画像的实时异步化视频推荐系统,应该说只是完成了一个心脏,整个数据集经过心脏的起博,开始流动起来,并且能够对外提供服务。
上次花了点时间让CarbonData集成到StreamingPro中,方便大家更快速的体验到CarbonData的好处,集成完毕后就写了篇文章:让CarbonData使用更简单 文章里面有下载链接,下载下来就能用,基本不需要你了解carbondata的知识就可以直接用。
这个月做的事情还是蛮多的。上线了一个百台规模的ES集群,还设计开发了一套实时推荐系统。 标题有点长,其实是为了突出该推荐系统的三个亮点,一个是实时,一个是基于用户画像去做的,一个是异步化。
Apache CarbonData是一种新的高性能数据存储格式,针对当前大数据领域分析场景需求各异而导致的存储冗余问题,CarbonData提供了一种新的融合数据存储方案,以一份数据同时支持“任意维度组合的过滤查询、快速扫描、详单查询等”多种应用场景,并通过多级索引、字典编码、列存等特性提升了IO扫描和计算性能,实现百亿数据级秒级响应。
Structured Streaming 的文章参考这里: Spark 2.0 Structured Streaming 分析。2.0的时候只是把架子搭建起来了,当时也只支持FileSource(监控目录增量文件),到2.0.2后支持Kafka了,也就进入实用阶段了,目前只支持0.10的Kafka。
之前在研究ElasticSearch的时候,发现竟然已经有七篇文章了。这些文章通常都是遇到了问题,于是去研读相关代码,试图搞清楚里面的机制,顺带记录下来而成文的。如果加上一些黏边的文章,譬如ELK的崛起等,则应当在十篇左右。
为了提高效率,我特别重视如下几点:工具化、预见和练习、打破惯性和让你身边的人也高效起来。
运维理论上不应该那么依赖于人的技能。但是现实情况是,你必须要有好的运维,才能保证系统更加稳定。而对于一个初创企业,显然陷入了一个困难的处境。如何让一个普通的开发也能搞好的运维呢? 核心是一个 一站式的运维平台。
运维的发展日新月异,曾几何时,运维仅仅是被认知为跑机房,装系统,设计网络,给开发擦屁股。但是现在运维变得极度重要,运维职责也更加细化,譬如稍大点的公司就将运维划分为基础运维,网络运维,DBA, 应用运维,架构师。其实我个人认为系统架构师应该都安排在运维里,开发团队应该率属于运维团队才好。
SQL 在解析字符串方面,能力还是有限,因为支持的算子譬如substring,split等有限,且不具备复杂的流程表达能力。我们内部有个通过JSON描述的DSL引擎方便配置化解析,然而也有一定的学习时间成本。
Facebook 60TB+级的Apache Spark应用案例 里大体有两方面的PR,一个是Bug Fix,一个是性能优化。这篇文章会对所有提及的Bug Issue进行一次解释和说明。也请期待下一篇。
上次在做内部培训的时候,我讲了这么一句:一个Job里的Stage都是串行的,前一个Stage完成后下一个Stage才会进行。 显然上面的话是不严谨的。
elasticsearch-sql 增加 jdbc支持
Elasticsearch-SQL 语句
Spark 2.0 将流式计算也统一到DataFrame里去了,提出了Structured Streaming的概念,将数据源映射为一张无线长度的表,同时将流式计算的结果映射为另外一张表,完全以结构化的方式去操作流式数据,复用了其对象的Catalyst引擎。
我们知道Spark2.0 ,Spark 1.6还有Spark 1.5 三者之间版本是不兼容的,尤其是一些内部API变化比较大。如果你的系统使用了不少底层的API,那么这篇文章或许对你有帮助。我们介绍的兼容相关一些技巧,主要包括动态编译以及反射等方式,也用到了Scala的一些语言特性。
StreamingPro使用教程
根据昨天的URL上报数据生成ALS模型。之后将模型加载到流式计算中,对实时URL的访问用户进行内容推荐。整个流程只需要你写写SQL(做解析),弄弄配置就搞定。
结构化数据加上一个支持schema变更的存储,加上一个高效易用的支持SQL的数据处理和查询的引擎,简直无所不能和极度高效。
Spark DataSource API 的提出使得各个数据源按规范实现适配,那么就可以高效的利用Spark 的计算能力。典型如Parquet,CarbonData,Postgrep(JDBC类的都OK)等实现。本文则介绍如何利用Spark DataSource 对标准Rest接口实现读取
虽然做的是大数据,但是毕竟是在一家云公司,而且是家具有视频基因的公司,对直播相关的技术却知道的很少,很汗颜,晚上阅读了一些文章给自己做些概念上的准备,顺带记录下来,如能节约大家的时间,便是极好的了。
StreamingPro有非常多的模块可以直接在配置文件中使用,本文主要针对流式计算中涉及到的模块。
StreamingPro目前已经涵盖流式/批处理,以及交互查询三个领域,实现配置和SQL化
StreamingPro目前已经涵盖流式/批处理,以及交互查询三个领域,实现配置和SQL化
这篇文章是给Spark初学者写的,老手就不要看了。文章谈及如何和HBase/Redis/MySQL/Kafka等进行交互的方法,主要是为了让大家明白其内部机制。
StreamingPro目前已经涵盖流式/批处理,以及交互查询三个领域,实现配置和SQL化
官方提供了一个快速上手的 Quick-Start ,不过是采用spark-shell local模式的。我这里在实际集群环境做了下测试,并且记录了下过程,希望对大家有所帮助。
上周出现了一次故障,recovery的过程比较慢,然后发现Shard 在做恢复的过程一般都是卡在TRANSLOG阶段,所以好奇这块是怎么完成的,于是有了这篇文。
如何衡量一个国家是不是真的富裕了 我总结出了一个标准: 一个没什么专业技能的人是否能够较为容易获取一份还算不错的收入。所谓不错的收入指的是除了满足基本生活需求,还能有闲钱买点电子产品之类的。
Apache Spark Future 吐槽Spark,其实我看了半天没看懂他在说啥。不过总体而言DataBricks公司目前很多的做法其实蛮合我的理念的。
之前我在微信朋友圈发了一段话,说明Spark Streaming 不仅仅是流式计算,也是一类通用的模式,可以让你只关注业务逻辑而无需关注分布式相关的问题而迅速解决业务问题.
随着开源组件的日益增多,整个开源社区就像一个超级大的沃尔玛,琳琅满目的开源组件让人挑花了眼。这里,我们就谈谈如何进行选型的问题。
现在依然很多人使用Azkaban/Oozie等工具衔接各个系统,通过外力让数据进行流转。而随着流式计算慢慢成熟与稳定,数据必然如河水一般,天生就是流式的。
这是一篇去年发的文章,但是有些见解目前来看,我觉得还是不错的。用户总是希望Docker能把什么工作都做了,提供自己的虚拟文件系统,提供强大的网络空间隔离,提供配套的编排工具。。。然而,这也为自己埋下了无数的坑
StreamingPro is not a complete application, but rather a extensible and programmable framework for spark streaming (also include spark,storm)that can
Spark Streaming 非常适合ETL。但是其开发模块化程度不高,所以这里提供了一套方案,该方案提供了新的API用于开发Spark Streaming程序,同时也实现了模块化,配置化,并且支持SQL做数据处理。