数据开发的技术提升之道

Posted 2022-02-01 云 祁

数据开发的技术提升之道

|0x00 数据开发

数据开发在大型互联网公司中，通常是贴近业务的角色，因为数据相关的工具，比如开发工具、监控工具、血缘工具、质量工具，都做的非常完善了，甚至能够对外提供商业化产品。在这种情况下，数据开发的工作，从偏底层的大数据引擎建设，提升到了面向业务的数据仓库 + 数据分析角色，也就是从幕后逐步的走向前台，最终目标是以数据科学家为导向。

在这种情况下，如果论常规的技术提升，那么除了精进SQL技巧之外，恐怕很难有其他突破的方式，本文就探讨一些与数据开发相关的技术，从这些方向可以尝试进行突破，一样能够做的非常出彩。

|0x01 数据建模

“建模”并非是一成不变的方法，而是可以进行精巧设计的“工具”。

数据建模本身是一种组织、分析、存储、应用数据的方法论。既然是方法论，那么就有衡量好坏的标准：性能、成本、效率、质量。因此，数据建模的工作，就是围绕这四个指标做出最优解而进行的努力。

数据建模的日常工作，就是通过宏观模型 + 分层模型，做好标准化的模型建设，并通过报表、接口、OLAP引擎等产品服务，对外输出数据价值。

数据建模通常是以“维度建模”为蓝本进行设计，部分情况下也会用E-R、DataValut等模型，但总体情况比较少。值得注意的是，维度建模并不仅仅指数据分层，也包括了诸如退化维度、桥接、累计快照事实等各种设计方法，但这些方法其实被思考和应用的非常少。

建模提升的角度大体可以从两个角度进行，一个是解决业务问题，一个是解决数据结构问题。

解决业务问题，需要考虑质量与效率的平衡点。在平时业务的建设中，业务会吐槽数据技术的一点，是遇到类似业务场景时，总需要技术自底向上的重新建设一遍，非常的低效。那么通过抽象来实现多场景的复用，就是一种解决业务问题的方式。但还有很多场景，本身就是复杂、易变的，那么这个时候，不论是绕过公共层，直接上ADS先解决问题，或者是设计能够适应变化、但反规范的一些模型结构，都是建模水平的体现，只要能解决业务的痛点问题，并在“性能、成本、效率、质量”之间取得平衡。

解决数据结构问题，诸如面对树结构、图结构等实体关系时，如果通过精巧的模型设计，来使用SQL对数据进行各种维度、层次的统计，提升复杂关系下的开发效率和数据准确性。或者是面对各种数据倾斜、基准变换、跨分区、多时区等场景下，提升数据技巧普适性的方法。这些通过表的方式来解决复杂关系的能力，也是建模水平的一种体现。

|0x02 数据治理

数据治理的精髓，是“数据资源的增长不超过业务的增长”。

尽管我们平时总把“数据治理”挂在嘴边，但在这个理论被提出10多年后，依然是目前数据领域的热门问题。解决的方法也很简单，就是尽量限制存储计算的增长，不论是通过技术手段，比如数据压缩、列式存储，还是通过方法论，比如维度建模、存储健康分，都能够延缓数据增长的困境。

但在市场上，专门研究这方面的理论，其实并不多。广为熟知的DAMA给“数据治理”下的定义是：数据治理是对数据资产管理行使权力和控制的活动集合。DGI则认为：数据治理是一个通过一系列信息相关的过程来实现决策权和职责分工的系统，这些过程按照达成共识的模型来执行，该模型描述了谁（Who）能根据什么信息，在什么时间（When）和情况（Where）下，用什么方法（How），采取什么行动（What）。IBM提出的数据治理概念中，将“数据治理”相关的要素划分为了四个层次，分别是：支持规程、核心规程、支持条件和成果。

但其实数据治理是一项比较大的工程，在实际工作中，我们需要缩小范围，“把好钢用在刀刃上”。因此，个人倾向于如下的概念，即：数据治理 = 数据质量治理 + 数据资产治理。所谓的治理，是站在数据从生产到最终消费的全链路视角上，利用平台技术提升所带来的红利，以从研发视角出发所推动的运营工作为锚点，让数据的治理变得“可持续”，并且提升研发同学的“幸福感”。

从这些角度出发，不论是研究开发的基础技术，如压缩、列存，或者是偏应用视角的规范、质量，都是数据治理能够提升的方向。将质量的治理动作应用在平时，减少“事故驱动”、“报警驱动”、“运动驱动”等不合理方式，也是非常有成就感的。

|0x03 实时开发

在数据仓库的建设过程里，我们一直秉承着“离线先行”的方针，因为离线的技术栈非常成熟，开发起来很快，同时监控工具也做的比较完善，出了问题能及时发现、及时处理。但随着Flink为代表的新一代框架的出现，很多业务已经不再满足于做准实时的开发了，完全实时化的数据流、面向实时做的数仓设计，就成为了数据和业务都关心的高价值项目。

但随着Flink为代表的新一代框架的出现，很多业务已经不再满足于做准实时的开发了，完全实时化的数据流、面向实时做的数仓设计，就成为了数据和业务都关心的高价值项目。哪怕是没有实时的诉求，很多公司也会尽量去搞一套体系出来，不仅是为了赶时髦，也是为了给技术团队储备有价值的知识。

在离线方案中，从数据完备性/准确性上讲，天级/小时级是能够做到的最短时效，但从业务的价值上讲，实时才是价值最大的场景，尤其是在大促等提升业绩非常明显的场景下，实时决策的威力不容小觑。

当然，业务实时化只是一个起点，如果从实时开发的角度上看，还需要解决诸多的问题。

如果采用Lambda结构，一套代码，需要维护两遍，实时一种，离线一种，这样会导致数据处理出现一些不可控的问题，处理数据的思路也不同，很容易出错。

如果采用纯实时链路，那么一旦出现数据问题，需要回滚或者重启任务时，造成的影响就非常大，而且纯实时目前无法很好的支持复杂业务。

业界通常的架构设计，基本上可以统一在Kafka + Flink + ClickHouse这样的类似方案上。当然，随着未来技术不断迭代，相信实时数仓架构，会像离线那样完善起来，但这条路还需要走一段时间。实时化的难度，在于当前的实时工具，恰似Hadoop兴起的年代，需要花费较多的时间在维护和调试上。

实时开发，确实是未来技术提升的重中之重。

|0x04 多维分析

多维分析通常和OLAP挂钩在一起，核心特点是“多维”，OLAP技术也可以称之为“多维度数据分析工具”，是提供自助分析的重要工具。

OLAP委员会对联机分析处理的定义为：从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业多维特性的数据称为信息数据，使分析人员、管理人员或执行人员能够从多种角度对信息数据进行快速、一致、交互地存取，从而获得对数据的更深入了解的一类软件技术。

尽管现在市面上有Kylin、TiDB、ES等多种数据库层面的技术方案，但Cube层的搭建，也是数据开发非常重要的一环。然而，如果对业务理解不那么充分、以及数据基础搭建的不那么完善情况下，贸然建Cube，所消耗的人力与机器成本其实是不可接受的。

当然，这种数据技术也要与前端结合在一起，防止前端渲染引擎搞不定如此多的数据。因此除了Tableau、FineBI、QuickBI等商业引擎外，也可以尝试进行自研。

如何在离线计算与数据库能力之间，寻找到一种平衡，就是多维分析的价值所在了。

|0x05 数据分析

最贴近业务的核心环节，也是数据仓库的进阶阶段：数据分析。当开发能够进阶到这个阶段时，跨向数据科学家的大门才算是打开了。

我们可以用简洁的讲法，来总结数据分析的价值：“将大数据转化为业务知识，帮助企业做经营决策”。

大部分的业务都集中在看汇总数据的阶段，但我们引用管理学大师“彼得·格鲁克”的名言：“You cannot impove it if you cannot measure it”，只有我们找到业务发展的关键衡量标准，也就是“北极星指标”之后，我们才能够针对性的优化业务。互联网上有一句广而流传的话，谷歌分析推广人之一Avinash Kaushik的名句：“All data in aggregate is crap. Segment or die. ”，意思是“所有的总和数据都是垃圾，要么分组，要么去死”。汇总数据会掩盖很多问题，对数据的下钻分析才能获得趋势发生的真正原因，才能够了解如何优化“北极星指标”。当今互联网人口红利逐步消失的前提下，对业务数据的深入理解和分析，才能够让业务维持高质量的增长。

那么数据分析的日常工作，主要在做什么呢？简而言之，在做三件事：业务的现状是什么、为什么会发生、未来将要如何（或如何改进）。

现状分析，就是告诉业务决策者，过去发生了什么事情，并且通常以报表的形式呈现出来。所以分析师不光要能够做日报、周报，还需要自己来搭建报表平台，通过分析关键的指标，来掌握业务的运营情况。

原因分析，是在业务现状的基础上，分析为什么会发生这些事情。比如指标上升或者下降了，是因为什么原因造成的；或者是分析不同渠道对于最终转化的贡献情况。分析的过程，通常会通过专题的形式展示出来。

预测分析，则是告诉业务，未来会发生什么。预测其实是一件很重要的工作，不论是企业经营目标的制定，或者是相关策略的落实，都需要预测未来可能的情况，来保证业务的健康可持续发展。例如电商大促的到来，销量会得到很大的提升，那么对应的预算、物流、商家要做怎样的应对，都依赖于数据来提供预测。

数据分析，才是真正考验对于业务的理解能力，也是数据开发组必备的能力。

|0xFF 总结

数据可以支持业务的方法有很多，做报表、搭平台并不是唯一的解决思路，在深入理解业务的基础上，能够将业务的痛点转化为技术语言，并通过技术解决这些痛点、推广这些方案，都称得上“数据赋能”。