数据架构重构

2019-07-16 本文已影响12人歌湾汐云

去年，对产品的数据架构进行了一次较大规模的重构。通过这次重构，大幅提升了整体性能和数据质量。在此，把这次数据架构重构的过程和心得总结一下，为以后数据架构设计提供些参考……

一、总体概况

根据“金字塔”原理，结论先行，先抛出重构前后的数据架构：

重构前后数据架构对比图

二、重构前存在的问题

我们的大数据应用，经历了较长时间的野蛮生长。这期间的主要思想是，各应用独立发展，互不影响。在这个思想的指导下，形成了之前的数据架构（如上图左）：从原始表生成面向应用的主题表数据。

然而，随着应用越来越多，应用之间相互关联、互相依赖的情况也越来越多，产生了一系列的问题：

使用难：主题表是由领域应用驱动设计的，定制性比较强，没有很好地考虑扩展和通用性，需求变化就很难重用。基于这些表进行再次汇聚、关联都比较困难。
质量差：相同指标在不同领域中的算法不统一，常存在数据一致性问题，数据质量差。
性能低：所有的主题表都需要从原始表开始处理，不同主题数据之间存在很多相似的重复计算，整体性能低下。
开发慢：应用需求的变化导致主题表结构频繁变化，并且需要从原始表重新处理，改动大，响应需求慢。

三、问题的解决之道

1. 表模型难以使用的解决之道——维度建模

重构之前的表模型难以使用，主要原因有：

主题表由各应用的研发人员根据特定的需求而设计，很少考虑与别的应用的通用性，造成相似的表很难共享；
主题表设计中，没有很好的关注粒度和度量的可加性。存在在同一行数据中，包含不同粒度的数据的情况(比如，在小时粒度的一行数据中，存在记录一天呼叫次数的字段)，以及只包含不可加度量的情况（比如，只包含成功率字段，但是没有成功次数和总次数），这使得从这些表进行再次聚合变得很困难。
主题表的设计中，没有很好的关注维度一致性。比如，同样是表示小区，有的表中用enodeb+cellid，有的表中用cellkey，这使得关联这些表变得很困难。

以上这些问题，可以用维度建模的方法，很好地解决。维度建模不是一个新技术，是早期数据仓库普遍使用的一种建模方法。在维度建模的世界里，世界被分为两部分：

事实：是现实世界各事件的度量。
维度：用于描述事件的环境。谁、什么、何处、何时、为什么、如何等。

维度模型设计过程主要关注四个方面：

① 业务过程
② 粒度
③ 维度
④ 度量

更多关于维度建模的方法这里不再详述，这里主要讲下是如何使用维度建模解决问题的：

面向业务过程设计模型取代面向领域应用设计模型，解决了表模型的通用性问题。由于原始数据来源于某些具体的业务过程（比如呼叫建立、呼叫释放等等），这些业务过程是相对稳定的，面向业务过程设计可以使得模型更稳定。具体的领域应用可以通过把相关的业务过程数据关联起来构建应用所需的数据，因此，这些模型也更通用，适合不同领域应用之间共享。
关注粒度和度量可加性。对于一个表模型的设计，必须明确确定它的粒度，即表中的一行表示的是什么，度量必须与粒度保持一致（如，小时粒度，即一个小时一行记录，这行中的所有度量必须是这个小时的度量，而不应该包含一天的度量）。度量按照其可加性，可分为完全可加、半可加和不可加。具有完全可加性的度量可以更好的支持汇聚。对于不可加的度量（如成功率），在表设计时要保留它的可加分量（如成功次数和总次数）。这样设计出来的表模型，就具备了很好的再次聚合的能力。
一致性维度，构建数据总线：当各个不同的业务过程，具有一致的维度时，这些维度就像构建了一个总线，各个模型可以很方便的挂载到总线上，相互之间可以方便地进行关联。

2. 数据质量差的解决之道——数据标准

重构之前数据质量差主要表现在数据不一致上。比如同样是掉话率指标，有的应用上看是1%，有的是1.1%。究其原因，最主要是因为缺乏标准。同样的指标，在不同领域内的算法不一致。比如有的掉话率算法是：掉话总数/释放总次数；有的掉话率算法是：掉话次数/呼叫总次数。而呼叫总次数并不等于释放总次数。

为解决数据质量问题，我们定义了一套标准体系。由这些标准，指导每个表模型及其算法的设计，如下：

业务域：分为三级。将所有涉及的业务过程划分到不同业务域中。比如：无线-4G-连接建立业务过程。
术语：是原始的度量（有的地方也叫原子指标）。比如：信号强度。
约束条件：是对术语的一个修饰。比如：有效信号强度（a < 信号强度 < b）
基础指标：约束条件、术语再加上一个聚合函数（count、sum）就形成一个基础指标。比如：有效信号强度上报的次数。基础指标一般具有完全可加性。
复合指标：由基础指标计算得到的指标，一般是百分比、比率、平均值等。如有效信号平均强度。复合指标一般不具备可加性。表模型设计时，要注意保留构成复合指标的可加分量，这样的表模型才具备更好的再次聚合能力。
公共维度：定义了维度主键、维度属性的标准。

公共维度指导维度表模型的设计；维度+术语指导事实详单表的设计；维度+基础指标以及复合指标指导聚集表的设计。

有了这一系列的标准，每个模型以及其算法都是规范的，可审计的。此外，我们还实现了根据指标标准，自动生成聚集表算法的工具，强化了标准的切实落地。

3. 数据处理性能低的解决之道——数据共享

重构之前，性能优化做了很多轮，单个任务的性能问题基本都解决了，但整体性能仍然不高……究其原因，主要是因为数据无法共享，各应用间存在大量相似地重复计算，耗费了大量计算和存储资源。此外，由于原来表设计难以使用，常造成本应很简单算法，实现却异常复杂，性能低下。

解决性能问题是本次数据架构重构的最根本驱动力。毕竟，性能差意味着服务器就要多，服务器就是白花花的银子啊……

解决性能问题，最根本的是构建数据共享层。重构后的数据架构中的DWD和DWS两层，就是数据共享层。上层应用都基于这些共享的数据进一步计算，避免了以前大量的重复计算和存储。性能得到了大幅提升。

此外，在本次重构过程中，个人比较得意的另一项工作是开发一个SQL静态检查工具。对SQL进行语法解析和语义分析，构建表的血缘和字段血缘。这样扫描出大量无用字段、无用表、无用任务等。清扫这些垃圾，使得性能也有了一定改善。同时，SQL静态检查中集成了一些性能编码最佳实践的规则（比如，要使用partition对数据进行过滤），可以对SQL编码的性能问题起到一定的防范作用。关于这个工具，以后有时间再单独介绍。

4. 数据开发慢的解决之道——数据分层

原来数据开发慢，除了很多相似的重复开发导致的慢以外，另一个主要原因是一个需求需要一个研发人员从原始数据开始从头处理生成最终的主题表，这条链路很漫长，并且不便于分工合作。

解决这个问题的主要方法是建立数据分层。对模型进行分层，可以做到关注点分离，这带来一系列好处：

可以简化问题：由于每层关注点不同，可以将一个复杂的任务，按固定模式和套路，分解为的几个部分。每一层只关注自己相关的部分，整个系统会比较简单和容易理解。
便于数据维护：当数据出现问题之后，问题的定位和修复，可以分层来做。而不用“眉毛胡子一把抓”。
有利于数据共享：数据分层后，可以将共享的数据限制在一定层级之内。

此外，对于本次数据架构重构，分层还有一个重要作用——可以使得重构的过程可按层级，逐步进行。这也一定程度上减少了此次重构的压力。

数据分层，简化了开发和维护的工作，使得各研发可以很好的合作，并行开发。

同时，由于数据标准的建立，使得DWD层到DWS层的算法自动生成成为可能。做到了设计即开发，进一步提升了开发的效率。

四、重构后的数据分层架构

综合以上各种问题的解决之道，本次重构最终形成的数据分层架构如下图：

1. 原始数据层ODS（Operation Data Store）：是入库的原始数据表。此层无需太多设计，只需要保留最原始的数据即可。

2. 详单数据层DWD（Data Warehouse Detail）：是以不同的业务过程为划分，建立的语义统一、粒度一致、维度和度量齐全的事实详单宽表。此层是本数据架构中最重要的一层。成功构建此层的关键在于维度建模和数据标准。要严格按照维度建模的四个步骤来设计表模型：①选择业务过程；②声明粒度；③确定维度；④确定事实。要对所有的维度和事实（术语）进行标准化定义。同时，为了提高性能，减少后期的关联操作引入的开销，此层中的表可以把部分常用维度属性退化到此表中，并且尽可能包含此业务过程中的所有度量。

3. 聚集数据层DWS（Data Warehouse Summary）：是按照不同维度对详单进行汇聚，形成包含各种指标的聚集数据表。成功构建此层的关键在于维度标准和指标标准。有了这两个标准为指导，可以构建出自动生成算法的工具，实现设计即开发。

4. 应用数据层ADS（Application Data Store）：是为不同应用定制开发的应用数据表。应用根据需求可灵活组合多个DWS或DWD表来构建ADS表。

5. 公共维度层CDS（Common Dimension Store）：是按照维度标准构建的一致性维度表。维度表是维度建模的灵魂，也是本数据架构的灵魂。正是有了这些一致性维度，才使得不同域的数据可以相互关联。每个维表都应该有一个唯一的主键以及一系列的维度属性。与维度建模要求不同的是，本次重构中，维度主键并没有使用代理键，而是使用业务系统的自然键。这么做的主要原因是在分布式系统中生成代理键太复杂，并且在大数据情况下将自然键替换成代理键的开销太大。

五、总结

本次数据架构重构的核心是维度建模。以维度建模方法论为指导，通过建立完善的数据标准体系，成功地把原来混乱的数据架构重构为最终层级清晰的数据架构。通过此次重构，产品性能提升2到3倍，数据质量有了大幅提升，开发效率也得以提高。

此次数据架构重构能够比较成功地实现，个人总结有以下几个原因：

合适的数据建模方法论——维度建模。
业务专家全程参与数据标准制定。
分层的架构，有利于分离关注点，逐层重构可减小影响。
自动化工具对提升效率的帮助。