LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog はじめに こんにちは、Data Platform室IU Devチームの島村です。 Data Platform室では、約400ペタバイトのデータ分析基盤を運用しております。このData Platformは、「Information Universe」(以下、IU) と呼ばれており、LINEの様々なアプリケーションから生成されるデータをLINE社員が活用できるように、データの収集、処理、分析、可視化を提供しています。私が所属するIU Devチームでは、「IU Web」を開発しています IU Webは、IUのデータを安全にかつ効率的に活用できるようにするData Catalog機能を提供しており、LINEグループのあらゆるサービスか
DXが声高に叫ばれる昨今、デジタル化された業務の結果、生成されるデータをいかにして活用するかが企業の命運を分けるようになってきた。ここ十数年を振り返ると、突如として量も形式も増えたデータに翻弄されることも少なくなかったが、その間にビッグデータを味方につけようと工夫がこらされた技術の一つがデータレイクである。今回は、Snowflakeのサービスパートナーであり、各種先端技術ブログでも有名なクラスメソッド株式会社でデータアナリティクス事業本部 プリセールスアーキテクトとして活躍しており、個人としてもこのテクノロジーの歴史をつぶさに見つめてきた甲木 洋介氏に、過去から紐解くデータレイクと、未来を担うSnowflakeの役割をご紹介いただこう。 解説者:クラスメソッド株式会社 データアナリティクス事業本部 プリセールスアーキテクト 甲木 洋介氏 Twitter:@yokatsuki はじめに デー
Why Apache Ozone? これまでPFNでは増え続けるデータやユースケースに対応するために、スケールアウト可能なストレージシステムをずっと模索し続けてきました。シミュレーションを基軸とした戦略を採用した[1]ことによりデータ量はさらに増加し、データ保管システムの重要性は高まっています。 Preferred Networks におけるHadoop – Preferred Networks Research で解説した基本的な要件は今でも変わっていませんが[2]、現在メインのシステムとして運用している Hadoop (HDFS) にはいくつかのシステム運用上の課題があります。たとえば、一番大きなHadoopクラスタは現時点で物理的に10PB近くのディスク容量を持っていますが、Ubuntu 16.04で動作しています。OSのバージョンアップを伴うクラスタのIn-placeなアップグレー
広告技術部のUT@mocyutoです。 こちらの記事はGunosy Advent Calendar 2021の4日目の記事です。 昨日は内田さんの その設定、pyproject.tomlに全部書けます - Gunosyデータ分析ブログ でした 今回はApache Hudiを用いたユーザデータ基盤の刷新を紹介します。 背景 仕組み 課題 対応策 データの持ち方を変える Apache Hudiとは 構成 Glue + PySpark Athenaによる抽出 移行し終えて 背景 Gunosyの広告システムではユーザに対して最適な広告を届けるために、接触済みのユーザに対して何度も同じ広告を出さないようにする仕組みを提供しています。 例えば、すでにある広告Aをクリックしたユーザには広告Aは再度配信しないのような設定です。 仕組み この仕組みを実現するためには以下のようなアーキテクチャになっていました
はじめに DRE Team の hyamamoto です. 皆さん,Spark は利用されていますか? Gunosy では Digdag + Athena によるデータ整形が増えてきており,徐々に Spark の利用は減ってきています. 思い返すと,昨年入社後の OJT も Spark から Digdag + Athena への書き換えタスクでした. 一方で,決して多くはないものの,この構成ではカバーし切れない処理もあり,そういったものに関しては Spark を用いています. 話は少し飛びますが,DRE Team では Digdag や派生するバッチ処理を実行するための Kubernetes Cluster を EKS 上に構成しています. また,一部のタスクは Kubernetes の Job として Digdag から投げることで,リソースをスケールさせつつ様々な処理が可能となっていま
2020/06/24 に公開された「Multi-Raft — Boost up write performance for Apache Hadoop-Ozone」の翻訳です。 関連リンク Apache Hadoop Ozone: Apache Hadoop 用のオブジェクトストアの紹介 Apache Hadoop Ozone: オブジェクトストアの概要 Apache Hadoop Ozone — オブジェクトストアのアーキテクチャー Ozoneのベンチマーク: CDP用Clouderaの次世代ストレージ Apache Hadoop Ozone セキュリティ — 認証 この記事は、Li Cheng, Software Engineer, Tencent Inc.による寄稿です 本番環境で Hadoop-Ozone を利用するApache Hadoop Ozone は、ビッグデータプラットフ
Summary With the growth of the Hadoop ecosystem came a proliferation of implementations for the Hive table format. Unfortunately, with no formal specification, each project works slightly different which increases the difficulty of integration across systems. The Hive format is also built with the assumptions of a local filesystem which results in painful edge cases when leveraging cloud object st
Iceberg is built using Gradle with Java 8, 11, or 17. To invoke a build and run tests: ./gradlew build To skip tests: ./gradlew build -x test -x integrationTest To fix code style for default versions: ./gradlew spotlessApply To fix code style for all versions of Spark/Hive/Flink:./gradlew spotlessApply -DallVersions Iceberg table support is organized in library modules: iceberg-common contains uti
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 2 日目の記事です。 TL;DRApache Hadoop のデータを BigQuery で分析できるようにするための移行手順をご紹介します。Google Cloud が提供する、フルマネージドでサーバレスなデータ ウェアハウスである BigQuery を活用することで、インフラやミドルウェアの運用保守作業を行う必要がなく、データ分析作業に専念できるようになります。(個人的な意見ですが)オンプレミスで Apache Hadoop クラスタを運用している場合、サーバの調達や、ミドルウェアのインストール、各種リソースの使用率のモニタリング、パフォーマンス チューニングなどの運用保守作業が定期的に発生し、効率的にデータ分析環境を運用することができない、といった課題が
HiveQLではスピードに難を感じていたため、私もPrestoを使い始めました。 MySQLやHiveで使っていたクエリを置き換える時にハマったTipsをまとめていきます。 AWS AthenaでPrestoを使っている方も増えてると思うので、Presto標準関数での記述例も拡充していきます。 Prestoとは Prestoはオンメモリで動く分散SQLエンジンで、その進化は目を見張る物です。 発表された当時は色々な成約があり使うことを躊躇していましたが、2015年頃からはもう使わない理由はなくなりました。 アドホックに使えるとても高速なSQLエンジンですので、バッチ向けのHiveのように実行結果を待つ時間はほとんどありません。 Hiveですと1つ1つの実行に時間が掛かるので、クエリに慣れていない新参者には辛い物がありました。 しかしPrestoではインタラクティブに実行できますので、トライ
HIVEクエリを書いていてハマったエラーと、その対処法を記載していきます。 WINDOW関数で集計範囲が異なる時のエラー ROWS BETWEENかの指定が異なる物が混じってるときに発生するエラーです。 他と記述を合わせることで、エラーは解消しました。 FAILED: SemanticException Failed to breakup Windowing invocations into Groups. At least 1 group must only depend on input columns. Also check for circular dependencies. Underlying error: Expecting right window frame boundary for function lag((TOK_TABLE_OR_COL weight), 12)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く