从业务，模型和技术等多个方向来说，目前数仓存在的痛点和难点是什么？
回答·24
最热
最新
- 1，从业务角度讲，数据来源广泛不一，各个纬度难以统一，颗粒度细化难以收集。 2，从模型角度讲，数仓建模层级递进，耦合关联问题分析较多， 3，从技术角度讲，从需求分析到数据集成，再到接口开发大屏展示。整个链路难以监控，出现问题排查缓慢
- 所有脱离业务的模型都是耍流氓，所有脱离模型的技术都是耍流氓，所有的业务需求都是耍流氓。维度模型可以让数据看起来很好用，但是需要大量时间调研数据，建模人员要高度理解业务，同时花费大量的试看处理数据。MR 提供来对大量数据下嘴的可能性，但是嚼起来有点慢，经常吃不上热豆腐。实时数仓是众望所归，但是也存在技术不成熟，人才不丰富的现状。可以预见的是，玩数据还是 sql 的天下，CK 和 FLINK SQL 有望成为利器。
- 痛点在有数不会用，想用数不准; 难点在规矩多难以运营，放手干安全又难以保障。
- 造房子的人不关心住房子的人，挺痛的 住房子的人关心能不能住二十年，挺难的 业务发展就像龙卷风，来得突然，应急预案不做足，那是挺焦头烂额的。 说到底，但凡，住房子的人能够多跟造房子聊聊业务的发展，造房子的人能够跟住房子的人讲讲房屋结构，这数仓应该也就既不痛，也不难了。 真要说怎么解决痛点难点，造房子和住房子的一起吃中饭，公司报销 80%吧
- 我感觉目前数仓最难的地方就在于公共层建设，也是最核心的地方，如果业务已经稳定成型倒还好点，但是如果是业务迭代很快的场景，如何让你的模型能够不仅适用于现有业务，而且在有业务变更时能够做到最小化的变动，我觉得这是每一个数仓架构师应该好好考虑的一个问题。像前面几楼说的数据质量，数据口径这些问题，我觉得站在集团层面制定统一的标准都能得到解决。
- 技术是最没有瓶颈的，或者说目前还没有轮到技术问题限制发展。 业务上，没想明白真正的数据需求是什么，也不明白到底要分析点什么。 模型的问题在于没有完整的设计，长期以来由于需求零散且乱七八糟，所以模型基本上就是为了满足个别分析需求而设计，结果就是数据模型乱七八糟，更不要提效率了。 要想突破，首先业务上要能够真正明白要分析什么，模型设计要自上而下做好顶层设计。 技术上的重点是能够支撑建立一套完整的分析协作流程。
- 从业务方向，业务变化,源数据质量，处理逻辑变化快！ 数据标准质量很难得到保证 从需求上，怎样准备的描述需求，能够把数据需求的描述让其他人更容易弄懂，减少知识只在脑袋中的问题 从模型方向，主要是公共层的建设，设计标准！另外感觉数据应用的中，测试是一个巨大的 bug，怎么检验，或者说自动化检验数据是一个很难的话题！ 从技术方向，目前大多数的给中小型数仓系统，计算和存储已经不是很大的问题！更多的是需要在智能化上进行演进，把各种低效的开发运维工作解脱出来！ 从价值上，放大数据应用的价值，获取更多资源，超出更多产品
- 一，离线数仓的在我接触的过程中，主要还是做公共层，把不同的业务梳理到一起是比较考验对业务的理解，其次就是离线本身是 T➕1，响应慢这个没办法。 二，离线数仓模型方面现在最常用的维度建模模型，维度建模的难点分层建模的时候。 三，技术难点，就是你用离线数仓就会面临质量，血缘等问题，你怎么保证怎么做等
- 用户增长滞涨，过于依赖头部主播，发展面临出海受阻，
- 1.源数据或源系统的数据质量、元数据问题。 业务盘点、数据盘点，数据质量尤其是历史数据问题处理是个难点，元数据的管理需要好的工具和严格的制度来进行。 2.快速迭代技术架构、模型架构。看到价值才能获取人力、物力、领导支持等资源，获取资源支持才能更好得调研、设计、开发，这种矛盾需要靠快速迭代快速看到价值的开发方式解决，这种方式又增加了重构难度，需要充分考虑。 3.整个数仓运行期间组织必须完整且责任划分明确这个开发阶段还行，运行阶段容易忽视，尤其涉及到人员变动，容易出现扯皮现象。 4.维持高水平的数仓运维人员，防止越维护越烂却不自知，等发现问题则需要耗费太多成本，不容易获取资源进行大规模重构