首页 文章 精选 留言 我的

精选列表

搜索[文件对比],共10000篇文章
优秀的个人博客,低调大师

Android内置GPS与腾讯地图定位技术对比分析

移动端定位技术是LBS(Location-Based Services)应用的基础设施。Android平台自诞生起便提供了基于系统框架的定位能力,随着Google Play Services的引入,融合定位(Fused Location Provider)进一步提升了原生定位的可用性。然而,在复杂的实际业务场景中——特别是室内定位、弱信号环境、高合规要求等场景下——系统原生定位能力的边界逐渐显现。

优秀的个人博客,低调大师

Vera 1.1 VS 主流文生视频模型,写实风格输出对比

写实风格是文生视频商业化落地占比最高的赛道,覆盖电商物料、实景短视频、数字人、实景宣传素材等业务。在实际生产中,模型不只是看画面静态画质,时序抖动、人物崩坏、物理逻辑错误、算力成本、私有化适配能力都会直接影响项目交付。很多团队选型仅参考公开样例,缺少本地标准化环境下的量化观测,上线后出现批量产出不合格、算力成本超预期等问题。

优秀的个人博客,低调大师

Apache Doris 事务保障:技术能力、选型对比与企业实践

Apache Doris 打破"OLAP 无需事务"认知,通过轻量级强一致事务机制支持 READ COMMITTED 隔离级别。存算一体采用三阶段提交(PREPARE→COMMITTED→VISIBLE),存算分离引入 FoundationDB 原生 ACID。Label 机制确保数据不重不丢,StreamLoad 2PC 对接 Flink 提供金融级可靠性。某支付机构写入提升 2-5 倍,ELT 提升 3-12 倍,查询提升 10-15 倍。

优秀的个人博客,低调大师

SQL、Pandas和Spark:常用数据查询操作对比

本文首先介绍SQL查询操作的一般流程,对标SQL查询语句的各个关键字,重点针对Pandas和Spark进行介绍,主要包括10个常用算子操作。 01 SQL标准查询 谈到数据,必会提及数据库;而提及数据库,则一般指代关系型数据库(RMDB),操作关系型数据库的语言则是SQL(Structured Query Language)。SQL本质上仍然属于一种编程语言,并且有着相当悠久的历史,不过其语法特性却几乎没怎么变更过,从某种意义上讲这也体现了SQL语言的过人之处。 在最新TIOBE排行榜中,SQL位居第10位 一般而言,一句标准的SQL语句按照书写顺序通常含有如下关键词: select:指定查询字段 distinct:对查询结果字段进行去重 from:明确查询的数据库和表 join on:指定查询数据源自多表连接及条件 where:设置查询结果过滤条件 group by:设置分组聚合统计的字段 having:依据聚合统计后的字段进一步过滤 order by:设置返回结果排序依据 limit:限定返回结果条数 这是一条SQL查询语句中所能涉及的主要关键字,经过解析器和优化器之后,最后的执行过程则又与之差别很大,执行顺序如下: from:首先找到待查询的表 join on:如果目标数据表不止一个,则对多表建立连接关系 where:根据查询条件过滤数据记录 group by:对过滤结果进行分组聚合 having:对分组聚合结果进行二次过滤 select:对二次过滤结果抽取目标字段 distinct:根据条件进行去重处理 order by:对去重结果进行排序 limit:仅返回排序后的指定条数记录 曾经,个人一度好奇为何不将SQL语句的书写顺序调整为与执行顺序一致,那样更易于理解其中的一些技术原理,但查询资料未果后,就放弃了…… 当然,本文的目的不是介绍SQL查询的执行原理或者优化技巧,而仅仅是对标SQL查询的几个关键字,重点讲解在Pandas和Spark中的实现。 02 Pandas和Spark实现SQL对应操作 以下按照SQL执行顺序讲解SQL各关键字在Pandas和Spark中的实现,其中Pandas是Python中的数据分析工具包,而Spark作为集Java、Scala、Python和R四种语言的通用分布式计算框架,本文默认以Scala语言进行讲述。 1)from。由于Python和Scala均为面向对象设计语言,所以Pandas和Spark中无需from,执行df.xxx操作的过程本身就蕴含着from的含义。 2)join on。join on在SQL多表查询中是很重要的一类操作,常用的连接方式有inner join、left join、right join、outer join以及cross join五种,在Pandas和Spark中也都有相应关键字。 Pandas:Pandas实现join操作有两个主要的API:merge和join。其中merge是Pandas的顶层接口(即可直接调用pd.merge方法),也是DataFrame的API,支持丰富的参数设置,主要介绍如下: defmerge( left,#左表 right,#右表 how:str="inner",#默认连接方式:inner on=None,#SQL中on连接一段,要求左表和右表中公共字段 left_on=None,#设置左表连接字段 right_on=None,#设置右表连接字段 left_index:bool=False,#利用左表索引作为连接字段 right_index:bool=False,#利用右表索引作为连接字段 sort:bool=False,#join结果排序 suffixes=("_x","_y"),#非连接字段有重名时,可s何止后缀 copy:bool=True, indicator:bool=False, validate=None, )->"DataFrame": 上述参数中,可以设置on连接条件的方式主要有3种:即若连接字段为两表共有字段,则可直接用on设置;否则可分别通过left_on和right_on设置;当一个表的连接字段是索引时,可设置left_index为True。 与merge操作类似,join可看做是merge的一个简化版本,默认以索引作为连接字段,且仅可通过DataFrame来调用,不是Pandas的顶级接口(即不存在pd.join方法)。 另外,concat也可通过设置axis=1参数实现横向两表的横向拼接,但更常用于纵向的union操作。 Spark:相较于Pandas中有多种实现两个DataFrame连接的方式,Spark中接口则要单一许多,仅有join一个关键字,但也实现了多种重载方法,主要有如下3种用法: //1、两个DataFrame有公共字段,且连接条件只有1个,直接传入连接列名 df1.join(df2,"col") //2、有多个字段,可通过Seq传入多个字段 df1.join(df2,Seq("col1","col2") //3、两个DataFrame中连接字段不同名,此时需传入判断连接条件 df1.join(df2,df1("col1")===df2("col2")) //注意,上述连接条件中,等于用===,不等于用=!= 3)where。数据过滤在所有数据处理流程中都是重要的一环,在SQL中用关键字where实现,在Pandas和Spark中也有相应的接口。 Pandas。Pandas中实现数据过滤的方法有多种,个人常用的主要是如下3类: 通过loc定位操作符+逻辑判断条件实现筛选过滤。loc是用于数据读取的方法,由于其也支持传入逻辑判断条件,所以自然也可用于实现数据过滤,这也是日常使用中最为频繁一种; 通过query接口实现,提起query,首先可能想到的便是SQL中Q,实际上pandas中的query实现的正是对标SQL中的where语法,在实现链式筛选查询中非常好用,具体可参考Pandas用了一年,这3个函数是我的最爱…… where语句,Pandas以API丰富而著称,所以自然是不会放过where关键字的,不过遗憾的是Pandas中的where和Numpy中的where一样,都是用于对所有列的所有元素执行相同的逻辑判断,可定制性较差。 Spark。Spark中实现数据过滤的接口更为单一,有where和filter两个关键字,且二者的底层实现是一致的,所以实际上就只有一种用法。但在具体使用中,where也支持两种语法形式,一种是以字符串形式传入一个类SQL的条件表达式,类似于Pandas中query;另一种是显示的以各列对象执行逻辑判断,得到一组布尔结果,类似于Pandas中loc操作。 4)group by。group by关键字用于分组聚合,实际上包括了分组和聚合两个阶段,由于这一操作属于比较规范化的操作,所以Pandas和Spark中也都提供了同名关键字,不同的是group by之后所接的操作算子不尽相同。 Pandas:Pandas中groupby操作,后面可接多个关键字,常用的其实包括如下4类: 直接接聚合函数,如sum、mean等; 接agg函数,并传入多个聚合函数; 接transform,并传入聚合函数,但不聚合结果,即聚合前有N条记录,聚合后仍然有N条记录,类似SQL中窗口函数功能,具体参考Pandas中groupby的这些用法你都知道吗? 接apply,实现更为定制化的函数功能,参考Pandas中的这3个函数,没想到竟成了我数据处理的主力 Spark:Spark中的groupBy操作,常用的包括如下3类: 直接接聚合函数,如sum、avg等; 接agg函数,并传入多个聚合算子,与Pandas中类似; 接pivot函数,实现特定的数据透视表功能。 5)having。在SQL中,having用于实现对聚合统计后的结果进行过滤筛选,与where的核心区别在于过滤所用的条件是聚合前字段还是聚合后字段。而这在Pandas和Spark中并不存在这一区别,所以与where实现一致。 6)select。选择特定查询结果,详见Pandas vs Spark:获取指定列的N种方式。 7)distinct。distinct在SQL中用于对查询结果去重,在Pandas和Spark中,实现这一操作的函数均为drop_duplicates/dropDuplicates。 8)order by。order by用于根据指定字段排序,在Pandas和Spark中的实现分别如下: Pandas:sort_index和sort_values,其中前者根据索引排序,后者根据传入的列名字段排序,可通过传入ascending参数控制是升序还是降序。 Spark:orderBy和sort,二者也是相同的底层实现,功能完全一致。也是通过传入的字段进行排序,可分别配合asc和desc两个函数实现升序和降序。 //1、指定列+desc df.orderBy(df("col").desc) //2、desc函数加指定列 df.orderBy(desc("col")) 9)limit。limit关键字用于限制返回结果条数,这是一个功能相对单一的操作,二者的实现分别如下: Pandas:可分别通过head关键字和iloc访问符来提取指定条数的结果; Spark:直接内置了limit算子,用法更接近SQL中的limit关键字。 10)Union。SQL中还有另一个常用查询关键字Union,在Pandas和Spark中也有相应实现: Pandas:concat和append,其中concat是Pandas 中顶层方法,可用于两个DataFrame纵向拼接,要求列名对齐,而append则相当于一个精简的concat实现,与Python中列表的append方法类似,用于在一个DataFrame尾部追加另一个DataFrame; Spark:Spark中直接模仿SQL语法,分别提供了union和unionAll两个算子实现两个DataFrame的纵向拼接,且含义与SQL中完全类似。 03 小节 对标SQL标准查询语句中的常用关键字,重点对Pandas和Spark中相应操作进行了介绍,总体来看,两个计算框架均可实现SQL中的所有操作,但Pandas实现的接口更为丰富,传参更为灵活;而Spark则接口更为统一,但一般也支持多种形式的方法重载。另外,Spark中的算子命名与SQL更为贴近,语法习惯也与其极为相似,这对于具有扎实SQL基础的人快速学习Spark来说会更加容易。

优秀的个人博客,低调大师

ElasticSearch结合MySQL的两种架构模式对比

数据库同步的管道架构 MySQL作为数据库的核心能力范围就是在线业务的事务处理和查询访问。因此无论单体应用也好,微服务也好,都会以多连接请求的形式,将业务数据写入MySQL;作为专业的Elasticsearch,往往在整个过程中,扮演着从MySQL复制数据、建立索引、提供搜索的角色。这是最普遍存在的一种应用场景。 往往从MySQL同步数据到Elasticsearch的过程,就属于异构系统之间的协作了,这块无论从技术选型也好,运维复杂性也好,都比单独解决两边的问题要麻烦。 解决MySQL和Elasticsearch两边数据复制的过程,就是需要用到管道架构了。目前看MySQL数据管道架构就是分为两种,我给它的定义(1)简单粗暴的客户端模式,(2)伪装成从属的副本模式 第一种简单粗暴的客户端模式 其实这种模式也很好理解,就是用SQL定时轮训数据表,抓取增量,然后写入Elasticsearch。常见的技术例如:logstash-jdbc-input插件 上述是logstash-jdbc-input插件定时查询MySQL,并且将数据表中变化的insert、update结果抓取到Logstash。然后Logstash就可以进行过滤等操作,并通过Logstash-output-elasticsearch插件输出给Elasticsearh索引。 这种简单粗暴的客户端模式,最大的优势就是简单!属于老少咸宜那种,缺点x也很明显,首先在这种模式下几乎所有的解决方案,都没有直接解决delete的好办法,一般需要业务操作上来同步支持。另外也可以看到logstash-jdbc-input有个schedule选项,最小时间间隔是1分钟。那么从实时性来看,也是客户端这种模式的最大问题。这个就不是说logstash-jdbc-input做不到1秒,甚至更短的间隔,而是这种模式不适合太短的间隔。 除了logstash-jdbc-input插件之外,还有elasticsearch-jdbc,太老了,不推荐。 第二种伪装成从属的副本模式 这种架构模式下的管道技术,设计机制就比较精巧。充分利用了MySQL的主从模式,将自己伪装成slave节点,然后通过CDC方法(数据变更捕获)获取binlog推送的变更数据,然后再用管道的思路,封装成消息推送到Kafka这样的变更分发平台,让Elasticsearch从Kafka上订阅,一会儿说加上kafka的优势,我们先看看这种伪装模式的代表——阿里的canal的具体样子 这张架构图,来自canal的github官网,基本上很形象的绘制了canal的架构角色,我就不单独画了。 图中的Master、I am a slave,就是canal把自己伪装成了MySQL Master的一个从属节点。那么主节点的binglog只要接收到数据,就会推送给canal,然后canal作为一个管道可以将binglog数据再次推送给Kafka、elasticsearch、HBase ...... 我们先看看这种模式的优缺点,优势非常明显,首先捕获数据的过程是实时的,你完全可以把它当成一个MySQL的从库对待,其次增、删、改的数据表操作基本上都涵盖到了,这也是伪装成MySQL从库的好处;缺点就是架构比较复杂,因为这种binlog需要使用Row模式,日志量会很大。 一般不推荐直接写Elasticsearch,很多文章都只是告诉你用canal的架构是MySQL+canal+kafka+elasticsearch,但从来不去加上kafka的原因,实际上canal完全可以通过自定义类直写ES。其实加上Kafka主要目的就是将MySQl-ES的同步过程的强依赖改为松耦合的异步过程。有一个原则,希望大家能记住,若参与协作的异构系统环节太多,尽量用异步,否则任何一个环节出了事,就堵死了。 上述的模式就是复杂,MySQL需要打开binglog(当然即便是单库运行,也强烈建议打开),无论canal需要考虑HA,还是构建Kafka集群,都要构建zookeeper集群。而且Kafka的分区模式要自定义为业务主键Hash存放,目的是让业务主键相同的操作都在一个分区上,若数据想长期存放在Kafka一份,尽量用Kafka的业务主键折叠策略,也就是相同主键消息事件,保留最新的。推送给Elasticsearch的过程中,还要再架上一个管道,例如用Logstash进行管道过滤。 数据事件分发架构 其实并不存在Elasticsearch为主,MySQL为辅的数据同步方式。原因很简单,Elasticsearch并不是一个事务型实时操作的数据库,它的设计就是面向大吞吐量的写入,并且构建全文索引,以及集群节点的分片搜索,结果聚合。因此如果让Elasticsearch为主库的需求,基本上都是事件流驱动的数据处理了,例如:日志采集、设备数据采集、操作事件记录等。那么在事件流驱动的架构体系下,消息中间件就是数据分发的中枢,而MySQL、Elasticsearch都作为此中枢的一个分发持久层客户端而存在。 上图就是数据事件的一个典型分发架构: 各个微服务对自己产生的业务操作事件封装成日志消息推给Kafka,那么微服务就实时地完成了日志任务,对于kafka作为分发平台,对于日志一方面由Streams Process(流处理)任务进行实时聚合计算,并将聚合结果推送给MySQL,这时候的MySQL就是作为BI统计的一个基准库。流处理系统有很多,Spark streaming、Flink、Storm、Kafka Streams,当然也可以自己写个简单的线程阻塞队列来实现。另一头分发给Logstash管道,管道对日志进行元数据打标签、过滤操作后写入到ES索引,那么BI在统计过程中,下钻到明细搜索的时候,就可以通过ES查询来完成海量日志的分片并行查询与结果聚合。 上述的数据事件分发架构就很好地解决了既要给Elasticsearch写数据,又要给MySQL存计算结果的双重问题。当然不止是这些数据库了,还可以继续加入HDFS、HBase、MongoDB等等。只要你有需求,这就是数据事件的分发架构,其实前面提到的canal走到kafka的时候,也就成了这种架构。 我们可以理解第一种数据库同步的管道架构,就是解决MySQL这样的事务型数据库的复制问题,通过binglog机制,是可以做到实时性的;第二种数据事件分发架构,其实就是典型的流式计算架构,也就是大数据技术范畴的计算架构了,通过消息中间件平台,例如Kafka,当然也可以考虑RocketMQ,将原本并发事务型的计算问题,转换成了解决数据事件流吞吐量的实时计算问题,其应对的环节应该是大量且频繁的数据写入情况。 本文分享自微信公众号 - 读字节(read-byte)。如有侵权,请联系 support@oschina.cn 删除。本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册