ITPub博客

前期的因种了后期的果，企业数字化转型亦是如此!软件公司制造焦虑、无节制的吹嘘造就了一个又一个关于数字化的期望泡沫

建预测模型有两个基本思路：因果关系/时间序列。本质上看，时间序列法就是模拟过去的走势，然后按过去的走势推演。这种做法和我们用肉眼观察数据走势，拍脑袋拍个数值没有思路上的区别，仅仅是用公式替代了肉眼观察，增加了精确度而已。

自研并不等同于每一行代码都是自己写的，我不太认同一些国产数据库厂商所宣称的每一行代码都是自己写的，因为这种做法太浪费有限的资源。只要不违反开源协议，合法使用开源代码，用于自己的产品，那么就没什么可被诟病的。

很多同学总觉数据分析做得不深入，到底该怎么做?今天结合一个具体的例子，分享下如何做一个深入的数据分析项目。

很多朋友把国产数据库的起源设定到1977年的黄山会议，那是中国学术界对数据库这个专业技术的第一次广泛的讨论和交流，确实意义非凡，不过这次会议并不能真正算是国产数据库产业的起源，只能说是国产数据库技术的启蒙。

当前大部分传统企业生存艰难，数字化建设也进入“低迷期”，相比早几年的蓬勃发展当前显得日常冷清，“从缩减预算到维持现状再到团队优化，我们企业的数字化经历了过山​车一般的感觉”

现在越来越多的企业想要应用AI/大模型，但是很多企业对人工智能的了解和相关技术储备存在不足，直接应用向量数据库有较高门槛，更希望有一个简单易用的端到端AI解决方案。

进入国产数据库时代，技术堆栈发生了巨大的变化，不过高可用这个问题在国产数据库时代并不会弱化。我们依然需要为国产数据库构建类似Oracle HA/RAC/ADG/OGG等高可用架构以保障业务系统的安全运行。

​“降本增效”是数字化建设永恒的重要目标之一，在建设初期企业都会有一个想象中的美好，但实际执行下来可能出现的情况是：短时间内会带来新的管理混乱，又可能会增加额外的人力成本，为什么会如此?

Data Fabric 利用其敏捷特性彻底改变了我们管理和利用数据的方式。它为数据集成、情境化和有意义的数据产品提供了全面的框架，确保了真实性并增强了协作。

不管数据库的技术如何先进，最终的目的是更好地解决用户应用中的问题，不为了解决用户痛点而泛泛地谈技术都是耍流氓。

每个用户对数据库的需求不同，每个企业对数据库产品的追求不同，因此对这个问题有不同的看法也很正常。我们作为外行的看客，也只能看个热闹而已，数据库企业都有自己的初衷和苦衷，对于他们的选择，多鼓励，少挖苦吧。

本文来自于”湘江数评“公众号，作者老杨，经作者本人同意授权后发布一谈起企业数字化转型建设，就不得不说一下信息部门，在整个数字化建设过程中不同的企业由于对数字化认知的不同，信息部门要么被重视，要么被边缘化，在数字化价值体现难的情况下信息部门的地位显得异常尴尬，于是在降本增效模式下，信息部门首当其冲，而理由也很简单：数字化项目暂停了，留着信息部门做什么?企业相关领导此时也会质疑：信息部门一天到晚在做什

在分布式数据库大行其道的那些年，在一次沙龙上，一个朋友说，分布式数据库入门门槛不高，做好极难，让用户能用好分布式数据库，需要厂商有极强的服务能力，不是小公司能干的。

企业做数字化转型建设就如同行军打仗，事实证明总想在短时间内四面出击扩大战果的策略是错误的，最后的结果就是损兵折将，要么系统烂尾造成大量资金损失，要么CIO被出局，企业也丧失了对数字化建设的信心

传统的数据处理方式通常倾向于基于服务的方法。这种观点虽然实用，但通常会将数据置于组织内支持但利用率略低的角色。我主张将数据视为产品而不是服务。这种转变代表了对数据感知、管理和使用方式的重大反思，特别是对于各个行业的数据分析和数据科学团队而言。

经常有同学问：“总听说要实现数据分析闭环，看到数据分析结果”，可到底该咋实现?为什么自己平时工作中，经常是发了数据给业务就石沉大海，这样咋胜任大厂的要求?今天系统讲解一下。

DBA在运维工作中遇到最难的问题是如何判断数据库是否存在某个问题，特别是在国产数据库大行其道的今天，这方面的知识都需要重新构建。DBA能力的提升也正是判断能力提升所加持的，今天我们就来聊聊这方面的问题。

对于传统行业的应用场景，传统行业的用户千万别被互联网思维给带歪了，应该更多地从应用场景的特点入手，选择能够更好地适配自己的场景，满足企业成本要求，同时自己的研发团队的能力能够轻松把控的系统架构。IT建设是个长期的系统工程，不是某个先进的理念就能够轻松颠覆的，踏踏实实稳步前行可能才是最好的道路。

数据驱动精细化运营是当前寒冬之下企业的必然选择，在精准营销和精细化运营过程中，常用的分析或算法模型。