数据开发如何巧妙解决业务问题

|0x00 数据研发的技能栈

“你的价值是什么？”

这可能是做数据的同学，最经常被问到的问题。早期数据从业者是比较开心的，能够应用Hadoop框架做工具，就已经能够解决mysql时代面临的海量数据问题了，价值不言而喻。有道是：“会写MR，月薪过万”。

但是如今，随着工具的不断发展和完善，尤其是商业化方案的高度完善，会使用大数据工具，来处理海量数据，已经是从业新人的标配了，甚至很多非专业的人士都能够轻松驾驭。这个事情，如何更进一步，利用数据技术，来解决业务问题，就是行业对于从业者的新要求了。

|0x01 问题的来源

除去电商等高度数字化的行业，很多行业推广数字化并不是非常顺畅，即便是一些互联网公司，在面对供应链这种数字化程度不高的领域时，也常常一筹莫展，究其原因，是因为遇到了两个方面的困难。

一个困难，叫作个性化；另一个困难，叫作人性化。

什么是“个性化”？作为技术部门，我们非常希望设计一些比较通用的方案，能够在不同的地方加以应用，比如利用维度建模的理论，设计一套比较合理的模型，下游能够广泛使用。但实际情况却是，随着很多创新业务的快速上线，业务要求先出Demo，也就是MVP版本，导致技术不得不紧跟变化，往往在不熟悉业务的情况下，设计一些方案来应用。如果业务发展比较不错，我们尚且有机会对模型进行重构，如果发展的不顺利，那么很多代码就只能放在那里，无法下线，维护成本却又很高。

可以说，通用的业务模型，都是时间沉淀出来的，往往只有核心稳定的部门，才能够做到着这样的结果。从业务的层面上来看，个性化是无法避免的主要问题，从技术的角度上讲，需要有非常多的定制工作，导致工作量不可接受。

什么是“人性化”？即数字化过程的本身，对于业务的侵入，是比较强的，导致方案无法推广或者打折扣落地。比如我们希望供应链完全的数据可视化，但这样会导致业务增加很大的工作量，或者是一些方案不希望被可视化，导致方案被反复争吵。

过去我非常喜欢的一部电视剧，《大明王朝1566》，关于“改稻为桑”，就是一个很典型的例子。现实中，强势的业务方，往往会压过弱势的技术方，导致一些问题不太可能被技术问题解决。数据技术能够赋能业务的前提，是有数据，但如果没有数据、或者数据不准确， 我们又如何解读出正确的结论呢？

因此，很可能不存在一个完美的方案，来解决各方的问题。现实往往是，我们通过小方案，不断迭代和组合，来曲线的实现复杂方案。

|0x02 解决的方法

通过小方案，不断累积，做成大方案，这个其实就比较考研技术的架构功底了。我们可以从两个方面的经验，来寻求解决问题的方案。

一个是架构思维，例如Lambda的实现原理。另一个是数据驱动思维，例如吴军对于这个问题的解读。

架构思维总是美妙而且实用的，我在阅读Nathan Marz所设计的Lambda架构时，首先利用了一个公式，来讲解他设计实时系统的基本原理，如下所示：Query = Function(All Data)。

再进一步细分，就是如下三个不等式的合集：

batch view = function(all data)

realtime view = function(realtime view, new data)

query = function(batch view, realtime view)

利用这个方案，我们可以解决数据源异构的问题，即不论数据是存储在Mysql中，还是OLAP引擎中，还是其他什么文件系统。只要能够满足这个不等式，我们就能够支持在计算的时候，将过程拆分到多台计算机，并行的进行计算。因此，我们巧妙的就可以满足高容错、低延迟和可扩展三个特点。

这对于数据研发的启示是，当我们无法设计一个完美方案的时候，我们可以通过架构思维，来把问题进行拆解，通过解决核心的子问题，来逐步解决关键问题。

另一种思维，就是“数据驱动”思维了，我在读吴军先生的《智能时代》一书中，学习到了这种思路。

我先简要复述下这段文字：

“仅仅依靠统计学，只能解决简单的问题，而无法解决一些相对复杂的问题。引申一下，就是依靠统计学做的报表系统，只能解决基础的业务问题，而无法解决诸如供需匹配的复杂问题。这个时候，数据模型就登场了，大多数的复杂业务应用，是通过数据来建立一个数学模型，来解决复杂问题。但数据模型同样存在两个核心因素：采用什么样的模型，以及模型的参数是多少？真实的情况中，模型的选择是一件很困难的事情，因为简单的模型不一定会与现实情况匹配，而复杂的模型往往需要耗费非常长的时间来寻找。过去不论是在理论上还是工程上，大家都寄希望于找到一个比较完美的模型，然后通过调整参数来让模型的结果与之前统计到的结果相匹配起来，这其实就是‘机器学习’要做的事情。但不是所有的业务都能找到完美的模型，所以有些人就考虑通过把一些简单的模型组合在一起，达到完美模型的同样效果，而如果数据量足够，这种方法是可行的，这就是‘数据驱动’。”

我们在解决个性化或者人性化问题的时候，同样可以尝试将简单的策略进行相应的组合，先解决业务的一个痛点，等发现这种方法的好处后，再逐步解决其他痛点，达到复杂策略的效果。

毕竟，我们是数据团队，虽然小数据量不能够反映什么问题，当数据累计到一定程度的时候，我们同样可以达到非常不错的效果。

|0xFF 数据体现价值

我们常听到一些戏谑的话：- SQL Boy、调参Boy、CRUD Boy …- 面试造火箭，入职拧螺丝。

其实数据工作没那么多有价值的业务场景值得探索，更多的时候，是做好技术支持工作。这其中面对的主要问题，就是需求的“不确定性”，天天做这些“不确定性”问题会搞得自己业务目标非常不集中（俗称“接客”）、做探索性的工作又会面临KPI怎么办的情况。

那么数据研发的价值体现在哪里呢？

我们面对的业务，也就是互联网模式，使用数据是一个“由轻到重、由浅到深”的过程：过去是通过在线化来获取流量，再用流量取得经济规模的红利；现在是使用数据来深耕一些行业，挖掘更深的价值点。

所以，数据要有一定的载体，才能产出价值。

这里我用一个类比的概念来阐述思路：

在金融市场上，我们有：一级市场、二级市场的说法。用专业的术语来形容，便是：一级市场是筹集资金的公司或政府机构将其新发行的股票和债券等证券销售给最初购买者的金融市场；二级市场是有价证券的交易场所、流通市场，是发行的有价证券进行买卖交易的场所。

但是，一级市场并不为公众所熟知，因为将证券销售给最初购买者的过程并不是公开进行的。投资银行是一级市场上协助证券首次售出的重要金融机构。投资银行的做法是承销证券，即它们确保公司证券能够按照某一价格销售出去，之后再向公众推销这些证券。

二级市场是一个资本市场，使已公开发行或私下发行的金融证券买卖交易得以进行。换句话说，二级市场是任何旧金融商品的交易市场，可为金融商品的最初投资者提供资金的流动性。这里金融商品可以是股票、债券、抵押、人寿保险等。

在我的认知中，数据产品或者数据应用，就是数据的二级市场，可以公开进行数据的买卖、交易等工作。我们的目标，是在基础数据上提供二次加工，提供给终端消费者或客户使用。

因此，数据模型作为一级市场，需要体现其价值；数据产品作为二级市场，负责创造营收和降低成本。

这么想来，我们与业务方其实是一种共生的关系。