大数据分析第一次作业_

大数据推动商业变革

科技的不断发展，深深改变了传统的商业模式。基于物品交换的供应链模式已经逐渐被淘汰，随着互联网用户的不断增多，越来越多的人开始“触网”，同时也在网上留下了大量数据，比如浏览记录，购买记录，出行记录等。数据的不断积累，为商业变革打下了基础。而大数据技术的出现，则点燃了商业变革的导火索。越来越多的企业通过大数据分析技术重塑商业模式，进行服务创新。

商业策略这一概念，最早是由BCG的创始人布鲁斯亨德森和哈佛大学商学院的教授迈克尔波特提出。亨德森理论的核心是集中优势力量对付敌人的弱点，他认为，在商业领域，包含许多被经济学家成为报酬递增的现象，比如：产业规模，投入越大，产出越大。波特认可这一理论，但是也提出来一些限制性理论，他指出，亨德森的理论的确成立，但是从商业上来说，需要更多的步骤，一个公司或者经济模式可能在一些活动中占有优势，但可能并不适用于其他活动。他提出来“价值链”这一概念。基于亨德森和波特的理论，整个商业策略大厦逐渐建立起来。但是在大数据时代，这一理论已经不在成立。随着互联网技术的发展，信息的获取变得十分便捷，交易成本在不断降低。交易成本的下降，导致可利用资源减少了，对垂直机构的整合也就会随之减少，价值链也会随之断裂，也可能不会断裂，但是对于同一商业中的竞争者来说，他们就可能利用其在价值链的位置，以此对竞争对手进行渗透、攻击。

英国出版的百科全书曾经是世界上最畅销的书籍之一，随着光盘和网络的流行，知识传播和更新的成本在不断下降，百科书行业随之倒闭。维基百科随之兴起，和百科全书不同的是，维基百科的内容是由用户撰写的，并且非常专业，价格也非常便宜。

再比如2000年，人类基因图谱的绘制，主要由专业的科研机构和科学家完成，耗费了2亿美金和10年的时间，才绘制出一个人的基因图谱。而现在只需要不到1000美元，甚至立等可取，这个行业甚至成为了零售业，以后当你去看医生的时候，可能会被要求先做一个基因绘制，然后医生会根据基因信息，找出致病基因，给你开出基因药物。我们可以利用移动设备和医疗设备收集到的临床数据和基因数据，找出一些我们不曾发现的配对组合。

基因组只是一个例子，实际上，大数据技术正在推动商业活动规模的自然形成，这一变革超越了机构之间的界限，尤其超越了以商业纪律为原则的界限，商业结构由垂直结构、寡头垄断变成了水平结构。

这个逻辑不仅仅指的大数据，比如电信通讯行业、纤维光学，医药行业等，都在发生改变，“大科学”变成一种趋势。

这种水平结构的出现，暗示了商业战略发生了根本变化，意味着我们要将策略认为是这一类水平结构的管理者。因为商业定义甚至行业定义是战略的成果，而不是预先设定。因此，我们需要制定出如何同时满足合作与竞争的战略。这些类型的转变，使得商业战略的传统前提变得过时，他们使我们进入一个全新的世界，他们要求我们不论是在公共部分，还是在私有部分，都以一种完全不同的方式来思考商业结构，并且使战略再一次变得有趣生动。

Uber打车，使得人们可以很方便的到达任何地方，对用户的以往数据进行分析，可以知道哪些地方经常有人需要打车，告知司机去往这些地方。如果你用过Uber，就会知道，它非常的方便，打开APP，一键叫车，随后车就会到了，到达目的地，以后，完成支付即可。在这些便利的背后，是由Hadoop和Spark这样的大数据工具在支撑。商业计划的简单明了，给了Uber利用数据来优化服务的巨大机会。Uber正在利用数据为全世界的载客司机提供智能、自动化、实时的服务并且支撑服务的规模化。

不论是Uber在峰时计价、帮助司机规避事故还是为司机寻找最优盈利位置，这一切

Uber 的计算服务都依赖于的数据。这些数据问题是一道数学和全球目的地预测的真正结晶。Uber数据部门的主管Aaron Schildkrout说：”这使得这里的数据非常振奋人心，也驱动我们斗志昂扬地用Spark解决这些问题”。

在2014年的时候，Uber还是利用传统的方式来处理数据，利用Python的ETL工具来清洗数据，然后在数据仓库中进行分析处理。在旧的架构下，Uber依赖于Kafka的数据流将大量的日志数据传输到AWS的S3上，然后使用EMR来处理这些数据。然后再从EMR 导入到可以被内部用户以及各个城市总监使用的关系型数据库中。原来的Celery+Python的ETL架构运转得挺好，但是当Uber想要规模化时就遇到了一些瓶颈。随着Uber扩展的城市越来越多，数据规模也不断增加，在现有的系统上我们遇到了一系列的问题，尤其是在数据上传的批处理过程。Uber 需要确保最重要的数据集之一的行程数据，这里成百上千的真实准确的消费记录将会影响到下游的用户和应用。Uber旧的系统并不是为了多数据中心设计的，需要用一系列的融合方式才能将数据放到一个数据中心里面。

解决方案演化出了一个所谓的基于Spark的流式IO架构，用来取代之前的Celery/Python ETL 架构。新系统从关系型数据仓库表模型将原始数据摄取做了必要的解耦。你可以在HDFS上获取数据然后再依赖于一些像Spark这样的工具来处理大规模的数据处理。因此，取而代之的是在一个关系模型中从多个分布式数据中心聚合行程数据，新的架构使用Kafka 从本地数据中心来提供实时数据日志，并且加载他们到中心化的Hadoop集群中。接着，系统用Spark SQL 将非结构化的JSON转化为更加结构化的可以使用Hive来做SQL分析的Parquet文件。这解决了一系列的额外问题，而且现在利用Spark和Spark Streaming 将系统变得长期稳定运行。Uber计划从访问和获取原始数据也都用Spark任务、Hive、机器学习组件，将Spark的潜能彻底释放出来。

虽然非结构化数据可以轻松搞定，Uber最终还是需要通过数据管道生成结构化数据，因为结构化数据在数据生产者和数据使用者之间生成的”契约”可以有效避免”数据破损”。为了将非结构化数据转换为结构化数据，Uber开发了新的工作流工具Paricon 和Komondor。Parino 这个工具是由4个Spark为基础的任务组成的：转移、推断、转化并且验证。因此不论谁想要改变这个数据结构，他们都将进入这个系统，并且必须使用我们提供的工具来修改数据结构。然后系统将运行多个验证和测试来确保这个改变不会有任何问题。

Paricon 的一大亮点是所谓的”列式剪枝”。Uber有许多宽表，但是通常我们每次都不会用到所有的列,因此剪枝可以有效节约系统的IO。Paricon 也可以处理一些”数据缝合”工作。一些Uber的数据文件很大，但是大多数都是比HDFS区块来得小的，因此将这些小数据缝合在一起对齐HDFS文件大小并且避免IO的运转失常。加之Spark的”数据结构聚合”功能也帮助用Paricon 工作流工具直观简化的方式处理Uber数据。

Komondor、Spark Streaming内建的数据摄取服务提供了架构级别的诸多细节。而数据源是”烹饪”的基础，原始非结构数据从Kafka流入HDFS然后准备被下游应用消费。在Komondor 之前，它是用来为每个独立应用确保数据准确性的工具（包括获取他们正在处理的数据的上游数据）并且在必要的时候做数据备份。现在通过Komondor 可以自动处理或多或少的数据。如果用户需要加载数据，使用Spark Streaming 就相对简单得多。为了处理每天百万级的事件和请求正在重金投入Spark 并且打算撬动更多的Spark技术栈,包括使用MLib和GraphX库做机器学习和图计算。

科技的进步在很多时候总会超出我们的想象。近年来，“大数据”一词逐渐被大众所熟知，人们用它来描述和定义信息爆炸时代产生的海量数据，并命名与之相关的技术发展与创新。大数据时代已然来临，它在迅速发展也决定着企业未来的变革。人们也开始意识到，数据对企业的重要性。而大数据时代的来临，对人类的数据驾驭能力提出了新的挑战，也为人们获得更深刻、全面的洞察能力提供了前所未有的空间与潜力。