自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+

Sunny的专栏

Stay Hungry Stay Foolish

  • 博客(197)
  • 资源 (5)
  • 收藏
  • 关注

原创 如何做架构设计和评审

优化的常见手段或模式静态化:动态数据和静态数据分离。异步化:使用异步化减少主流程中的非关键业务逻辑。并行化:使用多线程并发处理,缩短响应时间。内存优化:减少对象大小,减少对象创造,数据模型优化去重复运算:业务逻辑优化,或者使用缓存减少数据库操作:数据冗余,数据缓存等缩短数据库事务:短事务,异步化,最终一致性等方式可以考虑精简代码逻辑:去除冗余代码,诸如过度设计检查等代码。精简日志操作:日志大小要关注,注意IO上的瓶颈;日志太多,说明生成的string也会多,也增加了gc负担。

2022-09-07 11:43:46 3523

原创 全面了解常用数据分析方法与模型

根据试验结果确定发布新版本、调整分流比例继续测试或者在试验效果未达成的情况下继续优化迭代方案重新开发上线试验。

2022-09-07 10:09:45 973

原创 数仓数据质量保障方案参考

该文章简单通俗讲述了有赞保障数仓数据质量的实时方案,可以作为数仓数据质量方案设计的一些有用参考,同时文章中很多不同层次的方案设计可以直接借鉴使用。参考资料:1.微信公众号(数据治理体系)-《如何保障数仓数据质量?》

2022-09-06 11:49:33 650

原创 搭建企业级数据治理体系指南

数据治理是一个长期工作,需要相关从业者根据企业的数据现状和管理模式去构建和调整,建议边做实践边总结归纳,小步慢跑是一个很好的方式。

2022-08-08 10:33:16 583

原创 互联网职场人写周报的正确姿势

如果你的领导管理的下属较多,参与的项目也较多,如果不介绍项目背景和项目目标,领导很有可能无法快速想到,你汇报的内容是与哪个项目关联,项目要达成的目标是什么。因此,项目历史的介绍作为汇报的开头部分,一定不要忽视。...

2022-08-03 10:09:35 502

原创 系统与应用监控的思路和方法

在实际的性能分析中,一个很常见的现象是,明明发生了性能瓶颈,但当你登录到服务器中想要排查的时候,却发现瓶颈已经消失了。或者说,性能问题总是时不时地发生,但却很难找出发生规律,也很难重现。而要解决这个问题,就要搭建监控系统,把系统和应用程序的运行状况监控起来,并定义一系列的策略,在发生问题时第一时间告警通知。一个好的监控系统,不仅可以实时暴露系统的各种问题,更可以根据这些监控到的状态,自动分析和定位大致的瓶颈来源,从而更精确地把问题汇报给相关团队处理。要做好监控,最核心的就是全面的、可量化的指标,这包括系统和

2022-07-05 11:16:15 1708

原创 如何应对数仓资源不足导致的核心任务延迟

公司集群机器下线,肯定是出了故障,那第一优先级当然是尽快核查集群机器下线的原因,然后给出针对性解决方案,如果短时间内集群问题没法解决,也要尽快升级领导,把对业务的影响讲清楚,如果上级重视了,可能就会帮你协调到更高端的技术资源,这个工作一定要同步进行,一定要给集群支撑方足够的压力,这叫对症下药,也是治本的方法,其他方法说起来都是曲线救国。这一步做到位了,如果时间的确紧急,那就走到下一步。既然是集群,按道理资源是有冗余的吧,那么临时动态扩容是最基本的方法,这也是云计算存在的意义吧,如果这一步都做不到,至少说明系

2022-06-29 10:06:34 477

原创 【Spark】Spark SQL 字段血缘如何实现

字段血缘是在表处理的过程中将字段的处理过程保留下来。为什么会需要字段血缘呢?有了字段间的血缘关系,便可以知道数据的来源去处,以及字段之间的转换关系,这样对数据的质量,治理有很大的帮助。Spark SQL 相对于 Hive 来说通常情况下效率会比较高,对于运行时间、资源的使用上面等都会有较大的收益。平台计划将 Hive 任务迁移到 Spark SQL 上,同时也需要实现字段血缘的功能。Hive的数据血缘直接Atlas支持,Spark的字段血缘如何实现呢?Spark 是支持扩展的:允许用户对 Spark SQL

2022-06-22 10:23:57 2134 1

原创 去哪儿网BI平台建设演进史

通过 BI 平台取数、看数、分析数成为辅助决策、精细运营等非常重要的手段,然而随着去哪儿网业务不断发展,产品、运营等同学对这方面有更高的要求,例如简单易用的拖拽式报表、取数方便的自由式分析、查询速度的秒级响应、观测指标数据的准确可信等等。面对用户的个性化诉求以及海量数据,在平台体系化建设和技术实现上有一定的挑战性,本文将介绍去哪儿网BI平台的建设历程及实践,通过打造全场景的BI平台为业务增长赋能。从2015年至今BI平台的建设,经历了多年迭代发展,始终结合业务需要遵循以下几个原则:用户尽可能的自助完成,使开

2022-06-20 17:19:04 762

原创 技术Leader的思考技巧

架构设计思考法可以参考:技术人员成长之路-架构设计方法在思考一个命题时可以采取未来视角,先对未来发展做个预判,然后基于你的判断倒推现在应该要做什么,最后制定出关键里程碑和节奏。这个思考模型经常用在技术规划这个场景上,但很遗憾很多团队的技术规划都只是基于当前问题,有多少资源,然后采取量力而行的方法在对事项优先级进行排序。这其实不是真正的规划,最多算是计划(如果做得不好,计划都算不上,只能算是列表整理)。这个思考模型有几个关键的误区:不敢向前思考,担心自己的对未来的判断不对。我相信很多Leader都有这样的恐惧

2022-06-20 11:24:50 198

原创 技术能力的思考和总结

在程序员界有一个悖论持续在困惑着很多技术人:在写代码的人的困惑是一直写代码是不是会丧失竞争力,会不会被后面年轻的更能加班写代码的人汰换。典型代表就是工作5年左右的核心技术骨干,此时正处于编码正嗨但也开始着手规划下一个职业发展阶段的时候;没在写代码的人困惑是我长时间不写代码(或者代码量较少)我的技术功底是不是在退化,我在市场上还会有竞争力吗,我的发展空间是不是被限制住了。典型代表就是带业务项目的架构师或者团队Team Leader,他们更多的精力是在业务需求理解和拆分,团队事务的管理上。这种围城现象非常严重,

2022-06-20 10:08:55 232

原创 实时数仓方案如何选型和构建

在正式讨论实时数仓前,我们先看下行业对实时数仓的主要需求,这有助于我们理解实时数仓各种方案设计的初衷,了解它是基于哪些需求应运而生的。这也将帮助我们从更多维度上思考需求、条件、落地难点等等一些关键要素之间如何评估和权衡,最终实现是基于现有条件下的功能如何将其价值最大化。传统意义上我们通常将数据处理分为离线的和实时的。对于实时处理场景,我们一般又可以分为两类:基于以上查询需求,业界常见的实时数仓方案有这几种: Kapp架构了解,可参考:Kappa架构Kappa架构将多源数据(用户日志,系统日志,BinLog日

2022-06-16 15:33:57 1370

原创 ElasticSearch7.17权限控制和规划实战

由于在版本7开始,x-pack可以免费使用了,但是权限控制免费的不够细,但是控制到索引级别都基本够用了。付费的可以体验更细致的权限控制。本文的基础是已经有了es集群的基础上进行的。官网:Secure the Elastic Stack | Elasticsearch Guide [7.17] | Elastic假设你已经安装了elasticsearch7.17的集群,并且能够正常的运行。接下就是来配置权限;在elasticsearch.yml配置文件中新增(每个节点):然后在一台节点上运行,注意:如下

2022-06-14 12:03:16 2764 1

原创 事务与消息语义

事务是一个程序执行单元,里面的所有操作要么全部执行成功,要么全部执行失败。也就是我们常说的(ACID)。分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。分布式事务通常用于在分布式系统中保证不同节点之间的数据一致性。分布式事务的解决方案一般有以下几种:XA(2PC/3PC)、TCC最具有代表性的是由Oracle Tuxedo系统提出的XA分布式事务协议。XA中大致分为两部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,比如Ora

2022-06-08 16:26:10 349 1

原创 消息队列-消息事务管理对比

事务是一个程序执行单元,里面的所有操作要么全部执行成功,要么全部执行失败。也就是我们常说的(ACID)。分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。分布式事务通常用于在分布式系统中保证不同节点之间的数据一致性。分布式事务的解决方案一般有以下几种:XA(2PC/3PC)、TCC最具有代表性的是由Oracle Tuxedo系统提出的XA分布式事务协议。XA中大致分为两部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,比如Ora

2022-06-08 15:24:34 663

原创 消息队列-功能、性能、运维对比

消息延迟投递,当消息产生送达消息队列时,有些业务场景并不希望消费者立刻收到消息,而是等待特定时间后,消费者才能拿到这个消息进行消费。延迟队列一般分为两种,基于消息的延迟和基于队列的延迟:基于消息的延迟:为每条消息设置不同的延迟时间,当队列有新消息进入的时候根据延迟时间排序,当然这样会对性能造成较大影响。基于队列的延迟:设置不同延迟级别的队列,队列中每个消息的延迟时间都是相同的,这样免去了基于延迟时间排序对性能带来的损耗,通过一定的扫描策略即可投递超时的消息。延迟消息的使用场景比如异常检测重试,订单超时取

2022-06-08 14:11:17 805

原创 消息队列-全方位对比

消息队列是在消息的传输过程中保存消息的容器,用于接收消息并以文件的方式存储,一个消息队列可以被一个也可以被多个消费者消费,包含以下 3 元素:Producer:消息生产者,负责产生和发送消息到 Broker;Broker:消息处理中心,负责消息存储、确认、重试等,一般其中会包含多个 Queue;Consumer:消息消费者,负责从 Broker 中获取消息,并进行相应处理。点对点模式:多个生产者可以向同一个消息队列发送消息,一个具体的消息只能由一个消费者消费。发布/订阅模式:单个消息可以被多个订阅者并发的获

2022-06-08 10:50:32 1624

原创 注册中心对比Zookeeper、Eureka、Nacos、Consul和Etcd

注册中心主要有三种角色:服务提供者(RPC Server):在启动时,向 Registry 注册自身服务,并向 Registry 定期发送心跳汇报存活状态。服务消费者(RPC Client):在启动时,向 Registry 订阅服务,把 Registry 返回的服务节点列表缓存在本地内存中,并与 RPC Sever 建立连接。服务注册中心(Registry):用于保存 RPC Server 的注册信息,当 RPC Server 节点发生变更时,Registry 会同步变更,RPC Client 感知后会刷新

2022-06-07 14:49:22 3278

原创 EFK升级到ClickHouse的日志存储实战

EKF搭建的日志系统升级成基于ClickHouse存储分析

2022-06-02 10:28:47 951

原创 如何设计好的技术方案

一、技术方案意义我们为什么需要写技术方案?总结下来无非是几点,从不同人的视角来看: 产品:验证技术方案是否能够 match 上产品方案 测试:验证技术方案对测试方案是否有足够 & 准确的输入 同事 & leader:参与技术方案评审,验证技术方案的合理性 新人(不单单指新同学也指新接触这一块的同学):拿到技术方案可以很快对某一块的事情熟悉起来 二、好的技术方案形式我们都知道技术方案是指导具体开发工作的,可以分别从开发的事前、事中、事后来讨论这个

2022-05-31 10:11:43 1388

原创 架构设计方法

一、常用思考方法技术思考本质还是结构化思考,所以常见的结构化思考方法也是适用的。这也是大家会看到很多技术架构师都会用一些方法论去分析问题的原因。但这里我不是重新去论述这些常见的技巧,而是分享从技术实战中得到的一些思考方法,为此我分为了技术架构设计的方法和技术Leader的思考方法两类。二、技术架构思考方法2.1 0--->1(还原客观事实,快速迭代)当我们在一堆迷茫和混乱中不知道如何下口时,应该先贴近问题本身,还原客观事实,并快速形成 1 个能够拉起认知并快速讨论迭代优化的版本。大

2022-05-27 11:04:57 677

原创 低代码实时数仓构建系统的设计与实践

0、背景随着数据驱动业务的需求日益增多,数仓的建设越发频繁,开发人员在数仓构建这一个过程(埋点、埋点数据接收、数据补全、数据清洗、数据写入存储介质),从事着大量且重复的工作,同时对于实时数仓构建,需要一定的专业技能,例如需要懂得如何利用Flink等框架做过滤、转换、聚合等,对于后端业务团队来说,学习成本高,很难快速上手,开发成本居高不下。为了解决这些问题,低代码数仓构建系统应运而生,通过工程化的思想去解决,将固有领域问题交给系统,让开发人员关注数据本身,解放人力缩短数仓构建周期。一、整体架构

2022-05-26 10:28:04 418

原创 如何画好一张架构图

一、什么是架构图1.1 理解与解析如何画好一张架构图,要做好这件事情首先要回答的就是什么是架构图。我们日常工作中经常能看到各种各样的架构图,而且经常会发现大家对架构图的理解各有侧重。深入追究到这个问题,可能一下子还很难有一个具象的定义,如果我们把这个问题进行拆分(如下图)理解起来就会容易一点。架构图=架构+图按照这个等式,我们可以把问题转换: 架构是什么? 图是什么? 图是什么?这个比较容易回答,图是一种信息的表达方式,所以架构图,即表达“架构”的图,也就是一...

2022-05-21 11:14:16 1573

原创 Kafka生产级容量评估

一、需求场景分析1.1集群如何每天hold住10亿+请求拿电商平台为例,kafka 集群每天需要承载10亿+请求流量数据,一天24小时,对于平台来说,晚上12点到凌晨8点这8个小时几乎没多少数据涌入的。这里我们使用「二八法则」来进行预估,也就是80%的数据(8亿)会在剩余的16个小时涌入,且8亿中的80%的数据(约6.4亿)会在这16个小时的20%时间 (约3小时)涌入。通过上面的场景分析,可以得出如下:QPS计算公式 = 640000000 ÷ (3 * 60 * 60) = 6万,也就.

2022-05-18 10:37:44 1872

原创 从实现原理谈谈低代码

一、低代码的理解在讨论各个低代码方案前,首先要明确「低代码」究竟是什么?这个问题不好直接回答,因为低代码是非常宽泛的概念,有很多产品都声称自己的低代码,但我们很容易反过来回答另一个问题:「什么是低代码产品唯一不可缺少的功能?」我认为这个功能是可视化编辑,因为非可视化编辑就是代码编辑,而只有代码编辑的产品不会被认为是低代码,因此可视化编辑是低代码的必要条件,低代码其实还有另一个更清晰的叫法是可视化编程。既然可视化编辑是低代码的必要条件,那从实现角度看,实现可视化编辑有什么必要条件?我认为可

2022-05-05 10:56:31 676

原创 DSL 领域特定语言

一、DSL介绍DSL(Domain Specific Language)是针对某一领域,具有受限表达性的一种计算机程序设计语言。 常用于聚焦指定的领域或问题,这就要求 DSL 具备强大的表现力,同时在使用起来要简单。说到DSL,大家也会自然的想到通用语言(如Java、C等)。为什么没有一种语言同时 兼具『简洁』和『业务表达』能力呢?从信息论本质上来讨论这个问题,每个语言的程序都可以抽象为一个字符串,每个字符串由有限数量的合法字符组成,它在运行时会实现某个功能,因而可以看作是一种需求的信源编码。每

2022-05-05 10:23:59 35679 2

原创 实时数仓的实时保障指南

0、前言所有的数据建设都是为了用户更快、更方便、更放心的使用数据。在用户使用实时数据的过程中,最影响用户体感的指标有两个: 数据质量:实时数据产出的准确性。举个例子:实时数据在某些场景下不能保障端到端 exactly-once,因此实时与离线相同口径的数据会有 diff。而 1% 和 0.01% 的 diff 给用户的体验是完全不同的。 数据时效:实时数据产出的及时性。举个例子:延迟 1min 和 延迟 1ms 的用户体验也是完全不同的。 通过以下两个指标就已经能监控和判定 90

2022-04-25 11:55:00 2480

原创 Kafka的监控指标

0、前言Kafka的度量指标主要有以下三类:1.Kafka服务器(Kafka)指标2.生产者指标3.消费者指标另外,由于Kafka的状态靠Zookeeper来维护,对于Zookeeper性能的监控也成为了整个Kafka监控计划中一个必不可少的组成部分。一、Broker度量指标Kafka的服务端度量指标是为了监控broker,也是整个消息系统的核心。因为所有消息都通过kafka broker传递,然后被消费,所以对于broker集群上出现的问题的监控和告警就尤为重要。broker性

2022-04-24 14:51:37 5138

原创 Elasticsearch监控指标整合到Prometheus监控平台

0、ElasticSearch监控的指标参考:Elasticsearch Top10 监控指标一、Elasticsearch_exporter1.1 简介选择grafana作为监控是因为它展示出来很漂亮,而且可下载到前人使用过的配置文件,能够快速的搭建起监控系统;选择elasticsearch_exporter是因为它与ES集群是分开独立的,不需要对原有的ES集群(可能有很多个)做任何修改,不需要重启,只要能访问es集群即可,非常方便。1.2 安装过程1.下载链接:elastic.

2022-04-20 17:55:01 2379

原创 经典常用的数据分析模型

0、背景在工作中是不是经常要做各种分析,但又常常遇到无从下手,抓不住重点,搞不清关键数据的情况。俗话说“工欲善其事,必先利其器。”一个好用的数据分析模型,能给我们提供一种视角和思维框架,从而帮我们理清分析逻辑,提高分析准确性。一、AARRR模型AARRR模型又叫海盗模型,这个模型把实现用户增长拆分成了 5 个指标:获客、激活、留存、收益、传播。分别对应“用户如何找到我们?”、“用户的首次体验如何?”、“用户会回来吗?”、“如何赚到更多的钱?”、“用户会转介绍,告诉其他人吗?”这五个问题。大家

2022-04-18 09:54:33 1334

原创 【Redis】Redis分布式集群倾斜

0、背景对于分布式系统而言,整个集群处理请求的效率和存储容量,往往取决于集群中响应最慢或存储增长最快的节点。所以在系统设计和容量规划时,我们尽量保障集群中各节点的“数据和请求分布均衡“。但在实际生产系统中,出现数据容量和请求倾斜(类似Data Skew)问题是比较常见的。示例:春节抽奖服务,业务评估峰值qps是2w,转化到redis集群为10w qps和5GB内存存储,部署5个分片每个分片1GB+2W qps的redis集群(包含预留容量)。结果活动开始时,才发现服务存在”热点key",请求严重倾斜

2022-04-14 16:05:36 417

原创 大数据权限管理框架:Apache Sentry和Ranger

一、简介Apache Sentry:Sentry是由Cloudera公司内部开发而来的,初衷是为了让用户能够细粒度的控制Hadoop系统中的数据(这里主要指HDFS,Hive的数据)。所以Sentry对HDFS,Hive以及同样由Cloudera开发的Impala有着很好的支持性。Apache Ranger:Ranger则是由于另一家公司Hortonworks所主导。它同样是做细粒度的权限控制。但相比较于Sentry而言,它能支持更丰富的组件,包括于 HDFS, Hive, HBase, Yar

2022-04-11 09:58:54 889

原创 OLTP+OLAP->HTAP

一、OLTPOn-Line Transaction Processing:联机事务处理过程(OLTP)OLTP是事件驱动、面向应用的,也称为面向交易的处理过程。其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理,并在很短的时间内给出处理结果,是对用户操作的快速响应。例如银行类、电子商务类的交易系统就是典型的OLTP系统。其具备以下特点: 直接面向应用,数据在系统中产生。 基于交易的处理系统。 每次交易牵涉的数据量很小;对响应时间要求非常高。 用户数量非常

2022-03-28 14:26:03 493

原创 数据可视化建设指南

一、理解数据含义&明确目标做可视化,最容易进入的误区就是,拿到一堆数据,还没有理解数据有什么含义,直接就开始套用图形进行展示,把大部分时间用在美化图表上,而完全忽略数据本身传达的意义。上面这张图信息量很大,可以帮助大家评估一个可视化作品是否成功。比如,把数据按照一个故事线组织起来,那多半是一个研究文档或者提纲,再加上特定的目标和功能介绍,才可以画出线框图,最后加上视觉形式,才有可能变成一个成功的可视化作品。再比如,只有数据和视觉形式,那可能只是纯粹的数据艺术,看起来很美,其实没有

2022-03-28 11:14:03 2252

原创 【HBase】HBase海量数据高效入仓解决方案

0、背景现阶段部分业务数据存储在HBase中,这部分数据体量较大,达到数十亿。大数据需要增量同步这部分业务数据到数据仓库中,进行离线分析,目前主要的同步方式是通过HBase的hive映射表来实现的。该种方式具有以下痛点: 需要对HBase表进行全表扫描,对HBase库有一定压力,同步数据同步速度慢。 业务方对HBase表字段变更之后,需要重建hive映射表,给权限维护带来一定的困难。 业务方对HBase表字段的变更无法得到有效监控,无法及时感知字段的新增,对数仓的维护带来一定的

2022-03-16 11:18:04 387

原创 数据治理工作的几种推进套路

一、顶层设计法顾名思义,顶层设计法就是先做一个数据治理顶层设计的规划,然后按照规划执行即可。做过咨询的彭友都知道,顶层设计、战略咨询都会根据战略目标拆解KPI,然后设立对应的支撑项目,并且根据优先级别进行排序,最后形成一个执行的路径。今年做什么,明年做什么,先做啥,后做啥,都规划的清清楚楚明明白白。之后就按图索骥就行。大致的逻辑就像下图一样:这样的好处很明显,先有面,再有线,最后是各个点状的项目,一点点的落实,效果自然没的说。但是这样的方案是非常非常奢侈的,因为这种方案见效慢

2022-03-16 10:38:53 2937

原创 Prometheus和Zabbix的对比

一、监控工具的历史简介1.1 PrometheusKubernetes自从2012年开源以来便以不可阻挡之势成为容器领域调度和编排的领头羊,Kubernetes是Google Borg系统的开源实现,于此对应Prometheus则是Google BorgMon的开源实现。Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库。从字面上理解,Prometheus由两个部分组成,一个是监控报警系统,另一个是自带的时序数据库(TSDB)。2016年,由Google发起的Linux

2022-03-14 10:49:23 4718

原创 【架构】软件架构设计分层模型和构图思考

一、架构思维概述对于架构思维本身仍然是类似系统思维,结构化思维,编程思维等诸多思维模式的一个合集。由于架构的核心作用是在业务现实世界和抽象的IT实现之间建立起一道桥梁,因此架构思维最核心的就是要理解到业务驱动技术,技术为最终的业务服务。要真正通过架构设计来完成业务和技术,需求和实现,软件和硬件,静态和动态,成本和收益等多方面的平衡。架构设计中有两个重点,一个是分解,一个是集成。分解最基础的,架构的重点就是要对复杂问题进行分而治之,同时保证分解后的各个部分还能够高内聚,松耦合,最终又集成为

2022-03-10 10:27:02 7793 1

原创 【数据资产】数据资产目录建设方法与案例

一、数据资产目录建设意义1.1 政策支持我们以数据治理较成熟的行业-银行业的相关数据管理政策中可以发现,从国家到银保监会,到中国人民银行,在2020至2021年间就发布相关指导政策,明确数据是生产要素,并给出了数据治理建设指引。1.2 企业需求从企业层面以及数字化转型路线的思考框架上,企业从行业解析、战略愿景、明确措施、规划方案自上而下,更加明晰企业数据资产是整个数字化转型及数字化运营的坚实基础。1.3 发展趋势 数据资产管理正成为数据管理工作的转型方向

2022-03-08 14:00:16 15406

原创 数据迁移经验原则

0、前言在某些时刻,受业务转换以及其它原因,人们会经历多次数据迁移过程,场景就是把当前数据库的数据从一个存储系统或计算机中移动到另一台。数据迁移是一项非常复杂的任务。据统计有70-90%数据迁移最终无法达到目标。一、原则1.1 数据备份在开始做数据从一个系统迁移到另一个系统之前,需要管理员确保当前数据的安全,把当前数据备份以防任何潜在的风险导致数据丢失。删库是小概率事,而磁盘损失溢出,数据并不完全可读等问题,在备份之前应检测完整,当出现问题时可以将数据恢复到原始状态。1.2 验证

2022-03-08 09:43:21 2139

埋点数据指标分析(APP+WEB+业务维度)

埋点数据指标分析(APP+WEB+业务维度)

2022-10-12

mybaits参考资料

包含了mybaits的用户手册和快速入门的文档

2015-01-07

Struct2+Hibernate3+Spring3整合的纯净Demo

Struct2+Hibernate3+Spring3整合的纯净Demo

2014-10-24

Activiti简单的Demo

Activiti简单的Demo,入门看比较容易了解

2014-08-13

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除