首页 文章 精选 留言 我的

精选列表

搜索[数据库知识开放麦],共10000篇文章
优秀的个人博客,低调大师

mapreduce知识点记录

selfMapper extends Mapper< LongWritable, Text, Text, IntWritable> 其中LongWritable是某一行起始位置相对于文件起始位置的偏移量 FileSplit 继承extends InputSplit FileSplit fileSplit=(FileSplit) context.getInputSplit(); Stringpathname=fileSplit.getPath().getName();//获取目录名字 intdepth=fileSplit.getPath().depth();//获取目录深度 Classclass1=fileSplit.getClass();//获取当前类 longlength=fileSplit.getLength();//获取文件长度 SplitLocationInfo[]locationInfo=fileSplit.getLocationInfo();//获取位置信息 String[]locations=fileSplit.getLocations();//获取位置 longstart=fileSplit.getStart();//Thepositionofthefirstbyteinthefiletoprocess. 多文件输入与输出 1.多文件输入 FileInputFormat.setInputPaths() 方法:static void setInputPaths(Job job, Path... inputPaths)、 static void setInputPaths(Job job, String commaSeparatedPaths) 2.多文件输出(MultipleOutputs) public static class AlphabetOutputFormat extends MultipleOutputFormat { @Override protected String generateFileNameForKeyValue(Text key, IntWritable value, Configuration conf) { charc = key.toString().toLowerCase().charAt(0); if(c >='a'&& c <='z') { returnc +".txt"; } return"other.txt"; } } Combiner 作为map和reduce的中间环节,它的作用是聚合map task的磁盘,减少map端磁盘写入,减少reduce端处理的数据量,对于有大量shuffle的job来说,性能往往取决于reduce端。因为reduce 端要经过从map端copy数据、reduce端归并排序,最后才是执行reduce方法,此时如果可以减少map task输出将对整个job带来非常大的影响。 什么时候可以使用Combiner? 比如你的Job是WordCount,那么完全可以通过Combiner对map 函数输出数据先进行聚合,然后再将Combiner输出的结果发送到reduce端。 什么时候不能使用Combiner? WordCount在reduce端做的是加法,如果我们reduce需求是计算一大堆数字的平均数,则要求reduce获取到全部的数字进行计算,才可以得到正确值。此时,是不能使用Combiner的,因为会其会影响最终结果。 注意事项:即使设置Combiner,它也不一定被执行(受参数min.num.spills.for.combine影响),所以使用Combiner的场景应保证即使没有Combiner,我们的MapReduce也能正常运行。 shuffle与排序 Mapreduce的map结束后,把数据重新组织,作为reduce阶段的输入,该过程称 之为shuffle---洗牌。 而数据在Map与Reduce端都会做排序。 Map •Map 的输出是由collector控制的 •我们从collect函数入手 Reduce •reduce的Shuffle过程,分成三个阶段:复制Map输出、排序合并、reduce处理。 •主要代码在reduce的 run函数 JVM重用 启动JVM是一个比较耗时的工作,所以在MapReduce中有JVM重用的机制。 •条件是统一个作业的任务。 •可以通过mapred.job.reuse.jvm.num.tasks定义重用次数,如果属性是-1那么为无限制 StringTokenizer 1、构造函数。 1.StringTokenizer(String str):构造一个用来解析str的StringTokenizer对象。java默认的分隔符是“空格”、“制表符(‘\t’)”、“换行符(‘\n’)”、“回车符(‘\r’)”。 2.StringTokenizer(String str, String delim):构造一个用来解析str的StringTokenizer对象,并提供一个指定的分隔符。 3.StringTokenizer(String str, String delim, boolean returnDelims):构造一个用来解析str的StringTokenizer对象,并提供一个指定的分隔符,同时,指定是否返回分隔符。 2、方法。 说明: 1. 所有方法均为public; 2. 书写格式:[修饰符] <返回类型> <方法名([参数列表])> 如: static int parseInt(String s) 表示:此方法(parseInt)为类方法(static),返回类型为(int),方法所需参数为String类型。 1.int countTokens():返回nextToken方法被调用的次数。如果采用构造函数1和2,返回的就是分隔符数量(例2)。 2.boolean hasMoreTokens():返回是否还有分隔符。 3.boolean hasMoreElements():结果同2。 4.String nextToken():返回从当前位置到下一个分隔符的字符串。 5.Object nextElement():结果同4。 6.String nextToken(String delim):与4类似,以指定的分隔符返回结果。 待续。。。。。。。。。。。。。。。

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

【原创】HBase 基础知识

特点 1. 在 HDFS 之上开发的; 2. 面向列(实际是面向列族)的存储器 3. 实时读写 4. 随机读写 5. 针对超大规模数据集 6. 不支持 SQL 基本概念 单元格(cell) 由行和列的坐标交叉决定,有版本号; 版本号默认为自动分配,为 HBase 向单元格插入数据时的时间戳; 单元格中的内容为未解释的字节数组 行的键 表中行的键为字节数组; 表中的行根据行的键值(即表的主键)进行排序; 排序依据为字节序; 所有对表的访问都要通过表的主键(二级索引问题); 列族(column family) 行中的列会被划分成不同的列族; 同一列族中成员具有相同的前缀; 列族的前缀必须是可打印字符构成的; 列族修饰符,即结尾字符,可以为任意字符; 在 HBase 中,规定使用冒号来分隔列族和列族修饰符; 一个表的列族必须作为表模式定义的一部分预先给出,但是心的列族成员可以随后按需要加入; 物理上,所有的列族成员都一起存放在文件系统中; HBase 的调优和存储都在列族这个层次上进行的,所以最好使所有列族成员都有相同的访问模式(access pattern)和大小特征。 区域(region) HBase 自动把表水平划分成区域; 每个区域由表中行的子集构成; 一开始,一个表只有一个区域,随着表变大,区域的个数也会增加; 区域是在 HBase 中分布数据的最小单位; 在线的所有区域按次序排列就构成了表的所有内容; 锁 无论对行进行访问的事务牵涉多少列,对行的更新都是原子的; 构成 HBase 模型为一个 Master 节点负责协调管理一个或多个 Regionserver 从属机; Master 负责:启动(bootstrap)、全新的安装、将区域分配给注册的 Regionserver 、恢复 Regionserver 的故障。 Regionserver 负责:零个或多个区域的管理,响应客户端的读写请求,区域的划分,通知 Master 有新子区域(daughter region)产生; HBase 依赖于 Zookeeper ,默认情况下,HBase 管理一个 Zookeeper 实例,用于作为集群的权威(authority); HBase 负责管理根目录表(root catalog table)的位置、当前集群 Master 地址等重要信息; 相关文件 conf/regionservers -- 可以查看 Regionserver 节点信息 conf/hbase-site.xml 和 conf/hbase-env.sh -- 集群站点配置 持久化接口 本地文件系统接口(默认) KFS 文件系统接口 Amazon S3 接口 HDFS 接口 若要使用 HBase 集群,则通常要把 HBase 的存储配置为指向 HDFS 集群; 特殊表(涉及数据定位过程问题) -ROOT- 表包含 .META. 表的区域列表; .META. 表包含所有用户空间区域(user-space region)的列表; 在 Regionserver 上进行读写操作 写操作 追加方式写入提交日志(commit log),提交日志存放在 HDFS 中(保证高可用); 写入内存中的 memstore ; 若 memstore 满,则刷入(flush)文件系统; 读操作 查看区域(region)的 memstore ; 若在 memstore 中找到需要的版本则直接返回,否则按照次序从新到旧检查 flush file ; Regionserver 上存在一个后台进程负责在 flush file 数量达到阈值后,对其进行压缩处理(将多个文件的内容处理后写入一个文件中) HBase 提供的对外接口 Avro REST Thrift 通过上述接口和 HBase 集群进行双向交互时,需要 HBase 客户端实例进行代理,故比直接 JAVA 客户端交互更慢。 服务的启动和停止 hbase-daemon.sh <start|stop> <rest|thrift|avro> 对比 HDFS 和 MapReduce 适用于对大数据集进行批处理,但对于读或写单独的记录,效率很低;而 HBase 可以高效完成; HDFS 和 MapReduce 不擅长在有更新到达时维护索引(虽然 MapReduce 作业可以用于建立索引以支持随机访问),所以不符合低延时查询需求,而 HBase 可以; 大数据集需求 -> 排除 RDBMS 的使用(可能有点绝对) 低查询延时 -> 排除直接使用 HDFS ;

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

Android 冷门知识点汇总:你知道哪些Android中的冷门知识?

四大组件相关: 1.启动一个Activity,在应用进程至少需要两个Binder线程。 2.启动一个launchMode为singleTask的Activity,它并不一定会运行在新的Activity栈中。 3.两个不同应用的Activity,可以运行在同一个Activity栈中。 4.同一个应用进程中的所有Activity,共享一个WindowSession。 5.弹出一个AlertDialog,不一定需要Activity级别的Context,而且任何地方都有办法弹出一个AlertDialog,只要是在Application的attachBaseContext之后。 下面是一个简单的demo演示: 首先看DemoApplication,然后看Alert类: 在Application中初始化: import android.app.Application; public class DemoApplication extends Application { @Override public void onCreate() { Alert.alertAnyWhere(); super.onCreate(); } } 下面这个类是对AlertDialog的封装类: import android.app.AlertDialog; import android.content.Context; import android.content.DialogInterface; import android.os.Build; import android.os.Handler; import android.os.Looper; import android.view.WindowManager; import java.lang.reflect.Method; public class Alert { public static void alertDialog() { Context mAppContext = null; try { Class<?> clazz = Class.forName("android.app.ActivityThread"); Method method = clazz.getDeclaredMethod("currentApplication", new Class[0]); mAppContext = (Context) method.invoke(null, new Object[0]); } catch (Throwable e) { e.printStackTrace(); return; } AlertDialog.Builder builder = new AlertDialog.Builder(mAppContext); builder.setTitle("Hi") .setMessage("Hello World"); .setPositiveButton("确定", new DialogInterface.OnClickListener() { @Override public void onClick(DialogInterface dialog, int which) { dialog.dismiss(); } }) .setNegativeButton("取消", new DialogInterface.OnClickListener() { @Override public void onClick(DialogInterface dialog, int which) { } }); AlertDialog dialog = builder.create(); if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { dialog.getWindow().setType(WindowManager.LayoutParams.TYPE_TOAST); } else { dialog.getWindow().setType(WindowManager.LayoutParams.TYPE_PHONE); } dialog.show(); } private static Handler handler; public static void alertAnyWhere() { if (Looper.myLooper() == Looper.getMainLooper()) { alertDialog(); } else { if (handler == null) { handler = new Handler(Looper.getMainLooper()); } handler.post(new Runnable() { @Override public void run() { alertDialog(); } }); } } } 6.可以通过设置Activity主题android.R.style.Theme_NoDisplay,来启动一个不显示的Activity,在某些需要过渡的地方很实用。 7.Activity、Service、Receiver在没有配置intent-filter的action属性时,exported默认为false,配置了intent-filter的action属性时,exported默认为true。稍有不慎,很可能埋下越权、Intent攻击等安全隐患。 8.当从最近使用应用列表中移除某个App时,四大组件只有Service拥有神奇的onTaskRemoved回调,但是并不一定回调,还与stopWithTask属性等有关。 9.四大组件都运行在主线程,是因为它们在ActityThread中(或Instrumentation)实例化;它们的生命周期也运行在主线程,是因为通过ActivityThread.H将消息从Binder线程发送到主线程,然后执行回调。 10.TaskStackBuilder的出现基本上解决了所有构造Activity回退栈的问题。 11.ContentProvider的onCreate()方法先于Application的onCreate()方法执行,晚于Application的attachBaseContext()方法,所以在ContentProvider的onCreate()时候也是有办法弹出一个AlertDialog的(参考5)。 12.BroadCastReceiver回调onReceive(Context context,Intent intent)中的context类型各种场景相差很大,静态注册的receiver回调的Context都是ReceiverRestrictedContext,动态注册的receiver有可能是Activity或Application。 13.ServiceRecord和BroadcastRecord自身就是Binder。 14.同一个provider组件名,可能对应多个provider。 Handler、Message相关: 1.MessageQueue.addIdleHandler可以用来在线程空闲的时候,完成某些操作,比较适合那种需要在将来执行操作,却又不知道需要指定多少延迟时间的操作。 2.Message.what尽量不要设置成0,因为postRunnable的方式会生成Message.what为0的消息,如果删除了what为0的Message,也会将runnable方式创建的Message删掉。 3.Handler可以设置同步异步(默认是同步的),他们的区别在于异步不会被Barrier阻塞,而同步会被阻塞。 4.Handler的消息分发流程是如果Message的callback不为空,通过callback处理,如果Handler的mCallback不为空,通过mCallback来处理,如果前两个都为空,才调用handleMessage来处理。在DroidPlugin中,便是利用ActivityThread.H的这一特性,拦截了部分消息,实现Activity的插件化。 5.Java层和Native层Looper、MessageQueue的创建时序,Java层Looper—>Java层MessageQueue—>Native层NativeMessageQueue—>Native层Looper。 6.Java层通过Handler去发送消息,而Native层是通过Looper发消息。 Window、View相关: 1.硬件加速在Window级只能开不能关,View级只能关不能开。 2.自android2.3删除MidWindow后,PhoneWindow成了Window的唯一实现类。 3.WMS管理Window的过程中涉及4个Binder,应用进程只有ViewRootImpl.W一个Binder服务端。 4.MotionEvent、KeyEvent、DragEvent等具有相似的链式缓存,类似Message。 5.在View的状态保存、恢复过程中,ActionBar中所有View共享一个SparseArray容器,ContentView中所有View共享一个SparseArray容器。当前获取焦点的View会额外存储。 6.设置ViewTreeObserver的系列监听方法需要确保View在attachToWindow之后,否则可能因为add监听和remove监听不是作用于同一个对象而引起内存泄漏等。 Binder、IPC、进程等相关 1.可以通过文件锁来实现进程间互斥(参考:RePlugin),在处理某些只需要单进程执行的任务时很实用。 2.Binder设计架构中,只有Binder主线程是由本进程主动创建,Binder普通线程都是由Binder驱动根据IPC通信需求被动创建。 3.oneway与非oneway,都需要等待Binder Driver的回应消息(BR_TRANSACTION_COMPLETE),区别在于oneway不用等待BR_REPLY消息。 4.mediaserver和servicemanager的主线程都是binder线程,但system_server的主线程不是Binder线程,system_server主线程的玩法跟应用进程一样。 5.同一个BpBinder可以注册多个死亡回调,但Kernel只允许注册一次死亡通知。 6.应用进程由Zygote进程孵化而来,在它真正成为应用进程之前,系统通过抛异常的方式来清理栈帧,并反射调用ActivityThread的main方法。 7.在Binder通信的过程中,数据是从发起通信进程的用户空间直接写到目标进程内核空间,内核空间的数据释放是由用户空间控制的。 好了,文章到这里就结束了,如果你觉得文章写得不错就给个赞呗?如果你觉得那里值得改进的,请给我留言。一定会认真查询,修正不足。谢谢~

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

【直播系列之一】1篇文章看懂峰值带宽、流量、转码、连麦、截图五大直播计费方式

产品简介 阿里云视频直播服务(LiveVideo)是基于领先的内容接入与分发网络和大规模分布式实时转码技术打造的音视频直播平台,提供便捷接入、高清流畅、低延迟、高并发的音视频直播服务。 视频直播服务提供Web管理控制台、API和软件开发工具包。您可以通过它们使用、管理视频直播服务,也可以与您自己的应用和服务集成。 所有服务按使用付费,服务能力自动伸缩,告别复杂的架构设计和编程开发,维护成本几近于零,使您可以专注于业务逻辑实现及最终用户体验的提升。 产品优势 完善的解决方案 提供从推流,转码,分发到播放的全套技术解决方案。提供上行码率自适应,窄带高清转码,截图,录制,时移等功能和服务。 最流畅,低延时,高并发 业内最低的播放卡顿率,提供全网最流畅的直播观看体验。使用最优质的BGP机房和带宽降低直播时延,保证直播的实时交互。千万级直播并发能力,可动态

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

开放签电子签 3.5.1 版本更新内容

一、 新增功能 (New Features) [API] 增加默认业务线:当 API 调用未指定业务线 ID 时,自动启用默认业务线执行签署流程。 [UI] 签署图层设置:支持配置签名/签章图片层级,可选择置于文字上方或下方。 [印章] 矩形印模生成:新增通过矩形印模直接生成印章的功能。 二、 问题修复 (Bug Fixes) [修复]签署时间控件:解决时间格式解析错误问题。 [修复]数据处理逻辑:修复签署流程数据处理漏洞,并增加数据补偿机制。 [修复]填写控件处理:修正签署流程中填写控件的逻辑处理问题。 三、 优化改进 (Improvements) [体验] 多任务衔接:优化用户填写与签署多任务时的自动跳转流程。 [UI] 模板初始化:优化模板控件的初始化显示大小。 [UI] 颜色一致性:统一填写控件与签署控件的颜色显示。

资源下载

更多资源
Nacos

Nacos

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

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

WebStorm

WebStorm

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

用户登录
用户注册