网站备份和备案的区别,帝国cms7.0模板 绿色企业网站模板(整站带数据),wordpress文章excerpt字数,wordpress调用外部接口引言SQL的全称是Structured Query Language(结构化查询语言)#xff0c;是一种古老而简洁的程序设计语言。看似平平无奇#xff0c;一直被各种吐槽#xff0c;但却有着众多语言所难得的漫长寿命#xff0c;并展现出极好的拓展性#xff0c;在不同时期衍生出不同的子语言。… 引言SQL的全称是Structured Query Language(结构化查询语言)是一种古老而简洁的程序设计语言。看似平平无奇一直被各种吐槽但却有着众多语言所难得的漫长寿命并展现出极好的拓展性在不同时期衍生出不同的子语言。笔者作为腾讯TDW体系下的SQL现役运动员对日常工作中常用的基础知识和展开的业务实践予以了总结可供读者参考。结构化查询语言顾名思义它的基础在于结构化的数据库表最主要的应用场景在于数据查询虽然SQL也可以像其它语言一样有一些高级的写法但它的主战场并不在此仍要回归到对数据库表的操作和处理中。以下分为基础知识篇和业务实践篇展开介绍其中基础知识篇盘点了一些常用的技能点业务实践篇则总结了几点日常工作里的思考。第一部分 基础知识篇围绕着数据库表可以展开许多的主题工作有些是比较专业性的领域如事务处理和权限管控等这些更多是面向底层的技术基础部分属于DBA的工作范畴。对于使用SQL的很大部分用户群体来说则集中于对数据库表的增删查改聚合汇总里这些是面向业务的数据工作。针对这一块的内容继续将其细分到不同的子场景里逐一展开介绍。1.库表基本操作库表预览SQL最基础和最核心的两个对象便是数据库和数据表基于一个业务场景可以有N个数据库在一个数据库里面又可以有N张数据表。数据库的连接与切换数据表的创建与删除是使用SQL进行库表预览的基本操作。这些基本操作可以通过前端的可视化界面进行也可以从后台直连数据库展开需由使用者所拥有的权限级别来选择。数据增删除了一些常规的每日运行的计算任务外很多时候我们只是单纯地想对一张表进行处理比如插入几条数据更新某个字段值或者剔除几条数据。这些操作往往是单次的局部的目的清晰所以掌握几个关键字就可以实现如INSERT/UPDATE/DELETE等。视图应用视图的引入相当于在统计逻辑和实际库表之间提供了一种折中的方案。完成这个功能逻辑上是必须有这么几道工序的但又不想在每一道工序里都落地一张实际的数据表显得繁琐而臃肿那就引入视图吧把这些中间的工序用视图的形式去实现和替代。关键字其实SQL真的是一门很简洁的语言市面上也不会有大本的书籍专门讲述SQL的书写方式因为相对于其它语言来说SQL归根到底只是围绕着几个关键字的一些基础语句而已。只要把这几个关键字掌握了SQL的大部分内容其实就已经展开了。2.数据查询语句SQL作为面向数据库表的基础语言用户群体具有多样性从技术底层往业务层走往往会有DBA数据开发数据分析产品经理等这些用户角色。不同用户群体对SQL的侧重点是有差异的但无论是哪一个群体基本都绕不开数据查询语句是一块必要内容。简单查询能写一个简单查询语句其实就已展开了和数据库表的对话过程。不管是哪种SQL的拓展语言简单查询里的语法基本都还是一致的。比如用*代表全量查询用distinct去重用top和limit对数据条数做基本限制以及用as对原表字段名进行替换更新等。过滤查询在简单查询的基础上添加一些约束条件也就是过滤查询。比如你可以用关键字where查看其中某天的数据用between或者in来限制一个范围用like或者relike来做正则匹配也可以用and或者or这两个通配符对这些约束条件进行排列组合。排序查询排序查询可以细分为两个场景一个是在查询内部的排序即根据某个字段的属性值进行表内部分区对分区进行排序查询后输出可以用row_number的形式来实现另一个是把整个查询当做一个整体对结果表进行排序查询后输出用order by来实现即可。3.数据聚合与连接前面讲数据查询语句不管怎么查询其实并不影响原生的表结构即原来的表是按照什么逻辑写的数据查询结果里的数据也是基于这种逻辑只是筛选了局部数据而已。但数据聚合与连接就不一样了聚合会在纵向上改变原生表结构连接则在横向上拓展了表结构。数据聚合要对一张表做数据聚合其实理解了两个概念即可维度和指标。维度是你要基于哪些字段来做聚合指标是在这个维度之上你想用什么汇总函数生成哪些指标。数据聚合的关键字是group by维度里的属性值仍来自于原生表指标则是新生成的汇总值。数据连接对两张表或者N张表做连接是SQL里面非常重要的一个内容也是最容易埋坑的一个坑点。尽管数据连接只涉及四种方式七个语法但其仍然是绝大部分SQL脚本的核心内容。选择合适的可靠的数据连接方式应该是一个SQL运动员的基本功了。4.函数应用函数库其实就像是一个数据处理与分析的百宝箱收藏着各种场景下需要用到的车轮子。对函数库的熟悉和掌握可以较好地提升工作效率也让计算脚本显得轻量而简洁。毕竟站在通用的函数的肩膀上很多统计逻辑是可以一步到位的不需要沉迷于山重水复的自主构造里。以下参考TDW的函数库分类将日常所用的函数细分为几个子类别。4.1数学函数SQL里的数学函数主要和数值处理有关有取值函数和变换函数等。取值函数包括round四舍五入abs取绝对值ceil向上取整等主要用于对具体数值的细节调整变换函数则会改变该字段的数据分布形态如正弦sin余弦cos或者开根号sqrt等。4.2聚合函数在数据聚合中选择了具体字段作为聚合维度后之后便是应用各种聚合函数得到汇总值的过程。其中有简单聚合函数如count计数sum求和avg求平均也可以基于分布特征max/min取极值std取标准差variance取方差另外若在聚合过程中涉及分区处理的话也有rankfirst/last_valuerow_number等函数可以应用。4.3时间和日期函数对时间数据的处理同样也是SQL里的一个重要课题主要细分为时间的加减取值和转换这么三类。其中时间加减里又涉及不同的时间维度比如按日维度有date_diffdate_adddate_sub等按月维度有month_betweenadd_months等。时间取值函数则是在一个详细的时间戳里取出自己想要的部分如yearmonthdayhour等。时间转换函数则是时间形式的切换如日期格式格林尼治时间戳格式等。4.4文本处理数据类型可以粗糙地分为数值数据和文本数据对于文本数据的处理也有很多对应的函数。其中有一些简单取值函数如通过length和size获得字段长度和数组大小通过upper和lower可以切换大小写字符串的切割与拼接由浅入深有splitsubstrconcatwm_concat等最后正则表达式也是文本处理中一个特别重要的模块。4.5其它函数除了以上所盘点的一些通用函数外其实在日常工作中会有很多垂直的业务场景在这些特定场景下也有一些特定的函数逻辑。比如涉及数组结构拆分与重构时可以应用later view函数涉及字段编码时也有加密与解析函数除此之外还有逻辑函数转换函数等多种特殊函数在特定的场景下这些函数其实也是必要的。5.具体开发环境的注意点和其它众多语言一样SQL的编写也不能脱离其自身的开发环境不同的数据库形态不同的IDE都会有一些差异点和新特性。同样的一段脚本在A环境下可能跑的疾速如飞在B环境下却可能满屏报错可以拿出来讨论的往往只是一些通用的逻辑和思考。除此之外具体开发环境里的注意事项一些细节的加速点则是要在具体环境里去发现和探索。第二部分 业务实践篇一种语言一个函数库就像是厨房里的各种厨具它们可能或优良或劣质但本质上还是一些标准化的组件。基于这些公共的组件如何去烹制自己的美食以及在烹制过程中的心得和思考则属于业务实践的篇章。在业务实践的过程中不管怎样去规范化标准化每个人输出的脚本内容难免还是要带上私人的特质的这同样也是一个需要修习的部分。以下通过三个问题点来引出笔者在实际工作中的一些反思。其中如何尽量地少给未来挖坑介绍了一些反面的案例这些反面的细节在积累之后容易引起整个系统的不稳定性如何健康地做数据规划则是从一个创建者的身份展开几点数据规划的思考但不管做了多么缜密和丰富的准备随着时间推移总还是会出现变化的所以在破旧与立新之间要找到平衡点。这些反思是基于工作实践的层面难免会有幼稚和纰漏之处还请读者轻拍。1.如何尽量地少给未来挖坑不要起一些奇奇怪怪的名字SQL里的数据库表就像是其它语言里的对象往往是数量极大的并在时间的推进业务的发展中基数会持续放大。所以对于数据库名数据表名字段名尤其是一些主键索引的命名务必要有一套相对统一的规范。缺乏规范的约束时你无法想象人的想象力会多么发散这些奇奇怪怪的名字最终会把人深深地困住的。不要并行维护多个版本的数据因为业务的拓展数据背后的口径可能有所变更基于旧有的数据报表简单修改后出一份新数据是一种成本较低的实现方式。但最好不要并行维护多个版本的数据当版本超过3个的时候维护的成本是直线拉升的。所以当要做数据变更时一方面可以降低变更的频率另一方面尽量在原有报表里修改并替换掉原有口径。不要在单个脚本里写过多内容统计逻辑的实现就像是传统工业里的不同工序这个过程里存在两种极端。一种是把一个逻辑在横向/纵向细分为太多的工序部署过多计算任务形成很大冗余另一种是完全打包在一个大脚本里这种情况也不利于问题定位和中间数据处理。所以不要在单个脚本里写过多内容可以将它拆分进最优数量的计算任务中。要有一些基本的约束条件做一些事情时不仅要立足于眼下的问题点也要考虑一下未来可能发生的变化。就像是造一座桥修一条路总要考虑极限情况下的压力。很多的数据异常往往是在业务变化时旧有的逻辑不能适应当前的场景。所以在一开始写脚本时要考虑一下未来的场景有一些基本的约束条件这样会让所部署的任务会有较好的稳定性。要采用尽量简洁的写法能够一步到位的统计逻辑就采用尽量简洁的写法千万不要去绕圈子。尤其是一些核心脚本是要在不同环节不同阶段的同事之间传承的很多人并不了解当时的业务背景和需求逻辑如果写法太绕圈子的话最终就把大家一起绕进去了。2.如何健康地做数据规划数据规划是一个层级比较中等的概念往下一层做需求开发时往往只聚焦于特定的需求点并不涉及其它内容往上一层做数据工程的话又是基于整个部门整个产品形态的框架搭建。但数据规划更多是应对一个相对独立的业务场景所做的规划与设计。一个不够好的数据规划可能会引发后续的诸多问题点比如痛点1PM提出要在视图上扩展一个细分字段觉得很简单。我也觉得很简单但就是更改不了因为这个字段在数据源处理中就舍弃了无法从上一层数据表中获得。痛点2想要重跑一个时间范围内的数据但这张表不是分区表无法并行处理想要剔除某个日期内的数据但不同表中时间格式不一致导致处理结果有差漏等。痛点3同样的一条统计链路部分为了保障每日推送而独立出去部分为了特性统计而独立出去由此产生了众多的细分链路此后的变更也要在不同链路之间同步处理。 以上列出的三个痛点分别对应了原始信息的保留技术实现的最优路径以及计算任务的细分问题等不过也只是数据规划需要思考的其中一部分问题点。在不同的业务场景下里可以有不同的数据规划思路。粗糙地讲可以分为数据基础层和业务细分层独立处理。数据基础层做一个数据规划首先应该要考虑数据本身在数据基础层里应暂时抛开具体的业务细节以数据为重。这个时候应在处理中尽量地保留原始信息同时要对数据源做好质量检验第一道防线往往是很重要的一道防线。原始信息要完整数据质量要合格任务部署要轻便这些是数据基础层的一些目标也是后续工作的一个前提。业务细分层数据基础要独立而完整面向数据本身业务细分层则可以去细分实现面向业务细节。基于不同的业务目标可以从源表中筛选不同的内容用于应对特定的场景。这样的数据业务层级形成了一种“总-分”结构是数据规划的其中一种实现方式。3.如何在破旧与立新之间寻找平衡点很多的工作都是基于当下的场景即使做了详尽的规划和思考也不可能应对未来的所有问题。当业务逐渐地深入发展时很多的内容也需要做一些同步处理小的层面上是一些数据表和视图的表更大的层面上可能涉及计算平台的迁移视图系统的重建等。破旧与立新往往是一个长期存在的问题点。不需要每天都进行自我“革命”但改良和优化则是一个长期过程。在这个长期过程里我们需要在破旧与立新之间寻找到平衡点。以上是笔者在TDW体系下写SQL的一些实践和思考欢迎评论区留言关注~从微信支付看研发如何提高运营效能全民K歌 7.0 [更好看] — 产品设计思考与总结带你了解腾讯最坚实的支撑事业群
