有关大型数据仓库三大痛点的个人看法
有人说，数据仓库搭建失败的概率非常高，是ERP之后最不靠谱的大型项目之一。往往在项目立项的时候，我们会给老板呈现出一幅非常美的愿景图：响应快、业务驱动、智能化……但当项目上线之后，才会发现这个项目往往华而不实，要什么没什么，慢慢的投入就会逐步减少，直到项目陷入泥潭……
那么数据仓库在搭建过程中，遇到的核心问题是什么，我们又是怎样应对这些核心问题的，今天就挑选三个代表性的问题，来进行一一的解答。
数据仓库有“三多”的特点：参与人员多、业务关联多、需求提出多，数据仓库因为承载了公司数据驱动的任务，往往会将所有业务的数据都接过来，进而导致了业务数据之间存在千丝万缕的关系，变数越来越多，坑也就越来越多。为了解决这个问题，我们会招聘很多的人，每个人独立负责一个方向，但由于每个人的经验背景不同，我们又需要制定一系列的开发规范，久而久之，整个数仓的规模就变的非常的庞大。
这时候，团队已经出具规模，业务方也觉得我们应该通过数据做点事情了，于是就提过来了各种各样的需求，压力就来了。这里描绘一个典型的例子：老板提了一个需求，算一下昨天的业务成交额是多少，把你交了过去，你说：“我查一下哈，半小时后告诉你”。老板一听，心就凉了半截，对你而言，这半小时非常紧迫，开发任务、导出数据、测试准确性，要遵循的流程规范很多，但对于老板，这半小时就度日如年了。半小时后，你告诉老板，昨天成交额是XX亿，老板又问，那么XX方向的金额是多少，你再次回答：“半小时后”，老板吐血……现实情况可能更加魔幻，假设老板提出了一个非常绕的问题，可能一个星期都不一定算得出数据。
那么我们应该如何应对需求响应慢的问题呢？我认为，这需要从需求本身出发，来分析需求的特点。
通常而言，80%的需求都是相对固定的，例如每天的各行业的PV、UV、订单数、成交金额是多少，这些需求指标固定，只是在查询的维度上有所不同， 那么我们就可以将业务方常用的维度进行分析和再组合，开发固定的报表，放到DashBoard平台上，业务方可以自助查询。但这里有个问题，大部分的业务方并不关心所有的数据是什么样子的，通常只会关心固定的十几个指标，而我们的数据表有几十上百张，找到想要的数据会变得十分困难。这个时候，数据的仪表盘和个性化功能就很重要了，如果业务方能够自己定义想看的数据，再配合仪表盘直观的展示出来，放到一个简洁的页面中，大家对你的评价可能就有所改变了。
针对另外20%的临时需求，并没有固定的查询格式，很难放到DashBoard上，这个时候我们就需要针对这一类的需求做case by case的开发了。但这类需求通常也有一些可以分析的特点，例如计算的指标口径比较特别、粒度比较随意，甚至就是临时起意的一些想法，这个时候，我们最好能工提供一种根据粒度做快速自助查询的工具，通过sql的方式，让业务方自己去查询数据，解放数据工程师的人力。当然，不能直接让老板来查询数据，但是可以建议老板招聘几个数据分析人员，同样也是一种婉转的解决问题思路。
为了实现这两种方式，我们数仓工程师要做的，就是搭建清晰的数据仓库模型，讲数据的粒度、维度、周期、过滤等基础功能做好，并且指标统一、逻辑规范。s
当我们基本能够应对数据需求多的问题后，另一个问题就随之而来了，数据质量问题多。通常这又分为两种情况：“数据为什么对不起来”、“数据是不是一定准确”。
先说“数据为什么对不起来”。我们经常接到业务方的质疑：今天的数据为什么涨了这么多、这个数据为什么与后端的统计结果不一样、今天的数据怎么还没有算出来……这一类的问题涉及的面比较多，一般而言有两个问题会导致这个情况，一种是数据指标的计算过程不够健壮，另一种是数据统计的口径公司内没有统一。当数据指标的计算过程不够健壮时，数据就会发生一些波动，例如日志新增了某种类型的数据，但ETL没有做过滤，导致了指标统计结果偏多；再例如集群中出现了慢SQL，导致了数据结果产出时间比平时晚很多。这里涉及到的技术问题比较多，需要我们对数据计算的上下游有比较强的把控能力，一定做好与上下游的沟通机制，以便数据发生变化或出现异常的时候，能够及时告知。另外，不同的数据团队，或者是不同的业务部门，对于同一个指标的理解不同，是很正常的情况，某个过滤条件不同，就可能导致结果有比较大的差异。这个时候，除了数仓自身的标准化工作之外，也需要建立比较多元化的指标体系，例如搜索量，我们可以拆解成：直接搜索量、有广告搜索量、有第三方广告搜索量等多个概念，每个概念在页面上清晰的标注统计条件和过滤方式，供需求使用方取用。
再说“数据是不是一定准确”，老板问我们：“这个数据一定可靠吗？我要拿出去跟投资人讲。”这个时候，你可能就要犹豫许久了。这种问题要么不出现，出现了就对于数据仓库工程师是一种巨大的考验，要做出坚定不移的回答，你需要如下两方面的经验做支撑：一个是对业务有清晰和正确的认识，时常看自己统计的数据，保持对于数据的敏感性，例如某天的成交额比平时多一些，你就要先于业务人员发现这个异常；另一个是具备良好的数据仓库设计理念，对于统计过程有充分的信息，对于质疑数据准确性的情况，有充足的理由和完备的验证过程，来做到“有礼、有节、有据”的回应质疑。
你能够准时应答业务方的需求了，并且做到了数据质量可信，但某一天老板又找到了你，这次是数据仓库的机器成本太高了，需要削减一下，你又陷入了沉思。
不论从机房、服务器、计算资料、存储成本各方面的维度来看，数据仓库必然是一件高投入的事情，但是不是有高回报，却并不取决于你的业务。因此，如何降低成本，是数据仓库长期面临的基本问题。为了解决这个问题，我们需要从如下几个方面入手：接口化、标准化及智能化。
接口化，核心思想便是，通过完善的数据仓库结构，降低重复开发的概率，并且通过合适的接口层，对外提供统一的数据接口，对于节约机器资源非常有帮助。
标准化，即包括了开发行为的标准化，也包括了指标计算的标准化。通常每个人针对需求，都有各自的开发方式，很容易产生慢sql等情况，影响计算资源。因此，针对常见业务指标的统计，应该有一套标准的开发方式，通过集体的力量，降低计算资源的消耗。
智能化，也指对于机器资源使用情况的统计，计算每个人、每个团队的机器资源消耗情况，将消耗存储资源多的表，或者是消耗计算资源多的任务拿出来，做专项优化，也是显著降低成本的一种方式。
至于老板一刀切的问题：“机器减半行不行？”或许可以吧…
标签:
