粒度

随着大数据的到来，经常听到相关的词汇，维度、指标、BI、PV、UV等等，今天整理了这些词汇。 1. DW DW是Data Warehouse的缩写，即数据仓库。 DW要区别于普通数据库，数据仓库用于支持决策，面向分析型数据处理；而普通数据库主要服务于软件/网站，对于一致性/事物要求较高。 数据仓库是一个支持管理决策的数据集合。数据是面向主题的、集成的、不易丢失的并且是时间变量。数据仓库是所有操作环境和外部数据源的快照集合。 数据粒度 数据粒度，是指数据仓库中数据的细化和综合程度。根据数据粒度细化标准：细化程度越高，粒度越小；细化程度越低，粒度越大。 2. 数据集市（DM） 数据仓库是一个支持管理决策的数据集合。数据是面向主题的、集成的、不易丢失的并且是时间变量。数据仓库是所有操作环境和外部数据源的快照集合。 CRM 客户关系管理（Customer Relationship Management），数据仓库是以数据库技术为基础但又与传统的数据库应用有着本质区别的新技术，CRM就是基于数据仓库技术的一种新应用。但是，从商业运作的角度来讲，CRM其实应该算是一个古老的"应用"了。比如，酒店对客人信息的管理，如果某个客人是某酒店的老主顾，那么该酒店很自然地会知道这位客人的某些习惯和喜好，如是否喜欢靠路边，是否吸烟，是否喜欢大床，喜欢什么样的早餐，等等。当客人再次光临时，不用客人自己提出来

共享锁和排它锁 MySQL的锁系统：shared lock和exclusive lock（共享锁和排他锁，也叫读锁和写锁，即read lock和write lock） 读锁是共享的，或者说是相互不阻塞的 写锁是排他的，一个写锁会阻塞其他的写锁和读锁 在实际的数据库系统中，每时每刻都发生锁定，当某个用户在修改某部分数据时，mysql会通过锁定阻止其他用户对同一数据的读取 共享锁【S锁】 又称读锁，若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。 这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。 排他锁【X锁】 又称写锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。 这保证了其他事务在T释放A上的锁之前不能再读取和修改A。 锁的粒度和锁的策略MySQL 有三种锁的级别：页级、表级、行级。 MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁；InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。 MySQL这3种锁的特性可大致归纳如下： 表级锁：开销小

腾讯云自动巡检python脚本 最近在帮客户弄腾讯云自动脚本巡检的问题，并且需要部署在docker上，所以把问题记录一下： 由于腾讯云的api最近在更新，但是V3版本的api还没有完全发布，所以要两个版本混用来写。 环境： centos7 docker19 . 03.5 python3 . 7 tencentcloud - sdk - python - master：包含V2和V3两个版本的api , V3api无则用V2 （ [ https : // github . com / TencentCloud / tencentcloud - sdk - python ] 1、api获取数据时粒度 腾讯云api目前支持10s,60s和5min粒度的监控数据查询，但是在实际使用时发现，使用个别项（如cvm）获取数据时，在不同的粒度下存在获取不到数据的问题，咨询腾讯云官方，给出的结论是不同粒度的产品使用的是不同的数据源，故需在测试时选择数据稳定的数据源。 由于获取时数据粒度过小，故需在数据拿到后对数据进行聚合。 由于数据时间跨度过长，建议在获取多类数据时使用多线程，加快数据获取和处理的速度。 2、邮件发送问题 生成巡检报告并写入xls文件后，需要将文件发送给对应的客户，由于客户不想每次都下载文件，故需将汇总结果添加到邮件正文中，由于一开始未考虑部署的问题

转自： http://blog.csdn.net/missmecn/archive/2008/10/06/3019798.aspx 相关文章: my sql 数据库锁 ORACLE里几种锁模式 推荐圈子: Pipboy 更多相关推荐 对 锁机制 的研究要具备两个条件： 1．数据量大 2．多个用户同时并发 如果缺少这两个条件，数据库不容易产生死锁问题。研究起来可能会事倍功半。如果这两个条件都有，但你还是按数据库缺省设置来处理数据，则会带来很多的问题，比如： 1）丢失更新 A,B两个用户读同一数据并进行修改,其中一个用户的修改结果破坏了另一个修改的结果 2）脏读 A用户修改了数据时,B用户也在读该数据,但A用户因为某些原因取消了对数据的修改,数据恢复原值,此时B得到的数据就与数据库内的数据产生了不一致 3）不可重复读 B用户读出该数据并修改,同时，A用户也在读取数据，此时A用户再读取数据时发现前后两次的值不一致 SQL SERVER 作为多用户数据库系统，以事务为单位，使用锁来实现并发控制。 SQL SERVER 使用“锁”确保事务完整性和数据一致性。 一、锁的概念 锁（LOCKING）是最常用的并发控制机构。是防止其他事务访问指定的资源控制、实现并发控制的一种主要手段。锁是事务对某个数据库中的资源（如表和记录）存取前，先向系统提出请求，封锁该资源，事务获得锁后，即取得对数据的控制权

　　 为什么要使用事务？ 　　一个经典的例子就是银行转账问题。当把钱从一个银行转到另一个银行的时候，这操作由两步完成，首先要把钱从一个银行提取出来，然后再将钱存入另一个银行。如果此时，钱已经从一个银行提取出了，但将钱存入另一个银行的过程中或之前发生异常情况，如果没有事务保护就会出现源账号中钱减少，但目标账号中的钱并没有增加的情况。 　　事务简介：从严格意义上讲，事务是形成一个逻辑工作单位的数据库操作的汇集。通俗的讲，事务是能以原子操作形式完成的一系列操作。 　　事务四个基本特性： 　　　　原子性：一个事务中所有数据库操作是一个不可分割的整体，这些操作要么全部执行，要么全部无效。 　　　　一致性： 在事务处理执行之前和之后，数据是一致的。 　　　　隔离性：一个事务对另一个事务没有影响。 　　　　持久性：一个事务一旦完成全部操作后，它对数据库操作将永久反映在数据库中。 　　 为什么要引入锁？ 　　多个用户同时对数据库操作会带来数据不一致的问题。 　　并发的副作用： 　　　　丢失更新：两个用户或多个用户同时修改数据库，其中一个用户修改破坏了另一个用户的修改结果。 　　　　脏读： 一个用户进程读取了另一个用户进程修改过但没有正式提交的数据，这时导致了数据不一样的情形发生了。 　　　　不可重复读：一个用户读取数据，另一用户读取该数据并修改，此时前一个用户在读取发现前后两次数据不一致。 　　　

数据库的并发操作 事务 事务 (Transaction)是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。 事务是恢复和并发控制的基本单位 事务 的 ACID 特性： 原子性 （Atomicity）:事务是数据库的逻辑工作单位 一致性 （Consistency）:事务执行的结果必须是使数据库从一个一致性状态变 到另一个一致性状态 隔离性 （Isolation）:一个事务的执行不能被其他事务干扰 持续性 （Durability ）:一个事务一旦提交，它对数据库中数据的改变就应该 是永久性的。 并发控制 事务是并发控制的基本单位 并发控制 机制的任务 对并发操作进行正确调度 保证事务的隔离性 保证数据库的一致性 并发操作带来的数据不一致性 丢失修改（Lost Update） 不可重复读（Non-repeatable Read） 幻读（Phantom Read） 读“脏”数据（Dirty Read） 丢失修改 ：两个事务T-1和T-2读入同一数据并修改，T-2的提交结果破坏了T-1提交 的结果，导致T-1的修改被丢失。(修改-修改冲突) 不可重复读 ：事务1读取某一数据，事务2对其做了修改；当事务1再次读该数据 时，得到与前一次不同的值(读-更新冲突) 幻读： 事务T-1按一定条件从数据库中读取了某些数据记录，事务T-2删除（插入） 了其中部分记录

数据库有三级模型的概念，在这里，数据仓库也是有着三级模型并且是有着相似的思路。 1.概念模型 “信息世界”中的信息结构，也常常借用关系数据库设计中的E-R方法，不过在数据仓库的设计是以主题替代实体。 根据业务的范围和使用来划分主题 划分的方法是首先要确定系统边界，包括了解决策者需求(关注点)，需求类型。通过对业务系统的详细说明，确定数据覆盖范围，对数据进行梳理，列出数据主题详细的清单，了解源数据状况。 对每个数据主题都作出详细的解释，然后经过归纳、分类，整理成各个数据主题域，确定系统包含的主题。列出每个数据主题域包含哪些部分，并对每个数据主题域作出详细的解释，最后划分成主题域概念模型。 2.逻辑模型 逻辑模型的设计是数据仓库实施中最重要的一步，因为它直接反映了数据分析部门的实际需求和业务规则，同时对物理模型的设计和实现具有指导作用。它的特点就是通过实体和实体之间的关系勾勒出整个企业的数据蓝图和规划。逻辑模型一般遵循第三范式，与概念模型不同，它主要关注细节性的业务规则，同时需要解决每个主题包含哪些概念范畴和跨主题域的继承和共享的问题。 根据需求列出需要分析的主题，需求目标纬度指标，纬度层次分析的指标，分析的方法、数据来源等 对于一些 纬度存在层次问题 ，比如说产品存在产品的类别，产品的子类别以及具体的产品 在逻辑模型设计中需要考虑 粒度层次的划分

做中台找死，不做中台等死？ http://developer.51cto.com/art/201911/605254.htm 今年参加了云栖大会，作为中台的践行者，我也更关注中台架构实施的行业状况，学习了其他公司中台的思想和经验。 图片来自 Pexels 云栖大会上，我和做中台实践的同学，以及在阿里做中台的朋友进行了深入的交流和探讨，对做中台过程中遇到的比较纠结的问题进行了思考和总结。 在探讨中台哪些让人纠结不定烦心事之前，我们依然要谈谈我们为什么要做中台(注：本文中台局限于企业 IT 架构的中台，非广义上的中台)，做中台到底给我带来哪些好处，想不清楚这些就去深入到中台的细节里也无意义。 中台概念这几年特别火，就像 90 年代不做 ERP 是等死一样，现在做不做中台也好像能定企业生死一样，弄得大家都在搞中台。 但是不是所有的企业都适合做中台，只有符合以下条件的企业，才有实施中台的必要，切莫乱搞。 企业适合做中台的条件 所以，如果您是创业团队，或者业务线比较单一，建议不要盲目尝试中台架构，否则将拖累你业务发展的速度 。 另外，我们也要清晰的知道实施中台的目的，以及中台会给企业带来的价值，没有实际利益的推动中台就很难落地，或者有形而无神。 中台的价值 明确了中台的应用场景和价值体现，我们开始实施中台架构的落地。我从今年上半年开始推动中台这件事差不多有几个月的时间

数据仓库概念 数据仓库是一个面向主题的、集成的、非易失的、随时间变化的用来支持管理人员决策的数据集合 面向主题:操作型数据库的数据组织面向事务处理任务，而数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。 集成:数据仓库的数据有来自于分散的操作型数据，将所需数据从原来的数据中抽取出数据仓库的核心工具来，进行加工与集成，统一与综合之后才能进入数据仓库； 非易失的:数据仓库中的数据通常以批量方式载入和访问，在数据仓库环境中一般不进行更新 随时间而变化:数据仓库中的每个数据单元只是在某一时间是准确的。在一些情况下，数据中加有时戳，而在另一些情况下记录则包含一个事务的时间。总之，在任何情况下，记录都包含某种形式的时间标志用以说明数据在那一时间是准确的。 数据仓库发展 数据仓库和决策支持系统的起源可以追溯到计算机与信息系统发展的初期。 1. 20世纪60年代：穿孔卡和纸带作为最常用的存储介质，应用以报表处理为特征。 主文件和磁带的使用量的迅速增长，出现了大量冗余数据，导致： 1）更新数据时需要保持数据一致性 2）程序维护的复杂性 3）开发新程序的复杂性 4）支持所有主文件需要大量硬件 2. 20世纪70年代：出现磁盘存储器，数据库管理系统以及在线事务处理（OLTP） 3. 20世纪80年代

按照内存对齐粒度读取到内存，不足的用0填充。 文件对齐粒度 200 内存对齐粒度 1000 对齐后的大小 //以dwAlignment 对齐dwOperateNum 值,也就是让dwOperateNum为dwAlignment的整数倍 DWORD AlignmentNum(DWORD dwOperateNum, DWORD dwAlignment ) { if (dwAlignment == 0) { return dwOperateNum ; } int iTemp = dwOperateNum % dwAlignment; if (iTemp != 0) { return dwOperateNum + dwAlignment - iTemp; } return dwOperateNum ; } 文章来源: https://blog.csdn.net/dyxcome/article/details/91358028