如何看待科技、数据和业务?

一、科技 这里所谓的科技,包括了支撑整个业务设计、运营、维护的

研发、开发、项目管理、运维、安全及数据中心等职能部门所做的事。

不同规模、类别的公司,在科技上的投入不一和理解不同,造成了科技部门和责任的多样化,但基本的框架是差不多的。

研发部门,负责捣鼓在未来时间有很大价值的、或者说对公司业务会产生长期收益促进的产品。

开发部门,负责捣鼓在当下时间内,对公司的业务支撑、拓展必不可缺的产品进行设计、实现、维护和升级。

项目管理部门,负责捣鼓项目的权责、规划、进度、交付和资源,确保项目在一定的条件下、通过一定的努力,得到一定的交付。

运维部门,负责捣鼓对硬件和网络等物理资源的部署、上线、实施和维护,及对上线产品的监控、管理、预警、汇报等事项负责。

安全部门,负责通过安全产品的实施、安全机制、监控和预警机制等手段的利用,确保公司的核心资源、数据不被窃取、篡改和攻击。

数据中心,对,数据中心干什么呢?

二、数据 坦率的说,业务、运维、安全等系统,各有各的数据存储方案,从支撑业务正常运行的角度,数据中心的确显得多余。

可是,如果各个系统生产的数据越来越大、结构越来越复杂、对付此类数据所采取的策略越来越分化和分级,至少会出现两种状况:

受限于数据的治理能力,业务系统可能无法发挥应有的价值或无法继续正常运作; 随着业务系统的多样化演变,难以建立一个统一的数据视图。 对于复杂结构、大体量数据的管理,狭义地说,落在了所谓的“大数据”技术领域。

于是,我们有了各种大数据解决方案,比如:

建立持久型数据库、分布式缓存、实例级缓存的分级存储策略,并辅以同步和更新机制. 我们采用单线程、异步和队列的的方式,取代多线程和同步执行的方式,获得更高、更稳定的TPS. 我们采用分布式存储方式、建立分布式文件系统来管理数以PB计的数据. 我们采用MapReduce和RDD来完成单机被cpu和内存限制的计算任务. 我们用Kafka类的系统来埋点,并以准实时的方式收集和清洗数据,然后丢给storm或samza来进行准实时的处理. 我们同样没有忘记SQL,所以通过Hive或者Phoenix,我们用SQL-like脚本,来交互式地做CRUD. 为了查询数据,我们选择索引和存储分离,并用更专业的分布式搜索引擎来处理全文索引和二级索引. 以上,不是最佳方案,但应付80%的大数据场景,足矣。

为了在企业内,建立一个统一的数据视图,我们应该会采用商业智能和数据仓库的方案,那又是什么东西?

三、业务 业务跟商业智能和数据仓库有关系吗? 当然,有很大的关系,所以我们说说业务。

业务是简单的,假设你跟我一样,是一个普通的开发人员,当你在看到这里的时候,联想到你的系统所支撑的业务,你会不会觉得简单的难以置信,甚至一两句即可描述完流程?

业务是复杂的,复杂到需要成百上千、资历各一、专业不同的开发人员,通过复杂的软件工程和管理手段,才能做到目前这样的程度,而且你翻开代码仓库的一段,你还觉得他缺乏OO、领域、模式和设计的理解,注释也许写成这样“以下函数输入两个整形,进行相加,并输出一个整形”。

有一天,你觉得ETL的事情做腻了,而前端的报表在H5和css3之后,越来越漂亮; 你觉得spring MVC太重了,finatra既不需要tomcat的支持,scala的代码也更加简洁易懂; Mapper和Reducer让你恶心,RDD纵然轻快,可你也只是输出了一个报表片段而已。

对了,你想到了数据挖掘和机器学习。

看起来还不错,但是,这是你的业务吗?有人愿意付出预算和支持,来让你检验自己的想法和对于深度学习的热情吗?

请一定不要跳出业务的历史、现状去做思考未来,对于绝大多数人来讲,你我都很难成为乔布斯。

四、关系 明确业务场景,明确业务系统和数据产品的不同,对于产品的设计,尤为重要。

我们假设一个网贷p2p的业务模型,它的基本业务流程可能是这样的:

一个类资产证券化的过程,是从“资产端”到“资金端”的匹配,我们尝试梳理这样一个业务的痛点:

资产端的团队在获取项目后,资产或者说项目的打包情况是怎样的?经办人是谁?这样的团队业绩如何考量?

对一个一亿规模的项目,如何进行拆标和上标,才能获得最佳的资产-资金匹配效果?对于上标环节,能否解放运营团队的人力资源,做到自动上标?

对于资产端的风险,如何结合线下风控监管和线上风控模型,做到反欺诈、还款能力鉴定和还款意愿鉴定?

对于违约、逾期的项目,何时、由何种资源去进行对应的资产保全和催收?是不是在T+0时刻,可以通过回归,预测出T+N时刻的违约概率?

是否有一种手段,既可以总览全国的交易额,又可以便捷地审查各区域、各省市的明细?比如,我知道某地、某天应该有多少还款到账,又知道有多少投资人的利息需要进行兑付?

业务系统的信息流怎么和第三方支付进行对账?

如果出现刚性兑付压力或者满标压力,我如何确知那一天我的支持款是够用的?如果是一个母公司下的子公司,如何了解那一天其对我的支持款余额是真正可用的?

我如何知道我的业务做得好还是不好?

类似的问题,是科技还是数据提出的?

都不是,是业务。科技系统产生了数据,数据忠实地反应着业务的情形。

建立一个统一的数据视图,建立一个真正的数据仓库和商业智能系统,是为了从不同的层次和视角、从管理层和运营层的不同需求出发、对业务本身,做出精确刻画、精准统计和科学预测的基础。

五、再看数据 商业智能及数据仓库系统,很重要的一项能力就是要输出各种报表,而报表的表头字段,直接反应着观察者的基本焦点和需求。

所以,我们要对关键的数据做到精准的监控,并对监控项的逻辑关系和层次做到正确的理解和梳理:

如果能够做到系统化的KPI监控和预警,那么经营分析就接踵而至了。

比如,我们可以对现金流做出刻画,可以按项目为单位,来研究WACC和IRR的关系,从而基本回答“我做这个项目是亏钱还是挣钱”的问题:

如果还想做一点常规统计分析之外的“高大上”的东西,比如“数据挖掘和预测分析”,那么也许可以这样:

这里写图片描述

六、后话 如果忘记业务,就会忘记方向。

不要抗拒业务,学习她,拥抱她,科技和数据才会更加生动和有趣。